We’ve all heard how the modern SharePoint experience is quickly replacing its classic predecessor as the new standard for cloud-based collaboration, but what does “going modern” really mean? We asked Microsoft MVP and modern SharePoint enthusiast Marc Anderson 7 questions to better understand this new way of working.
Stay up-to-date on the latest migration, modernization, and security trends!
Video transcript: 7 questions for Marc Anderson about the SharePoint modern experience
- What is the SharePoint modern experience?
- Why modernize your SharePoint experience?
- The biggest mistake made when modernizing SharePoint experience?
- When to use subsites in SharePoint’s modern infrastructure?
- When should SharePoint remain in classic mode?
- Reasons why you might not be ready to adopt SharePoint’s modern experience?
- If we could improve one thing about SharePoint’s modern experience, what would it be?
Q: What is the SharePoint modern experience?
A: The modern experience in SharePoint is really, to me, taking a step from the past into the future.
SharePoint has been stuck with a UI that hasn’t changed much over the last 10 or 15 years—it’s really been that long. That’s why a lot of my clients’ sites just kept working with forms and things, because nothing really changed for such a long time.
The modern experience is an entire reinvention of that UI. It’s a different set of technologies underneath. It’s a different look and feel. It’s a different user experience. And it ought to feel like a big improvement to people who’ve been using SharePoint for a long time.
Q: Why modernize your SharePoint experience?
A: The first thing people ought to be doing when they think about modernizing is decide why they’re doing it. Believe it or not, people think that they should just jump to the next technology because it’s new. If you just do it for that sake, you probably won’t have very successful results.
What you really want to think about is:
- What business levers are you trying to pull in order to make your organization better at what it does?
- How are you going to improve collaboration?
- How are you going to improve information broadcasting on your intranet?
- How are you going to use things like SharePoint news, or shared events, or Planner, for example, in a modern team site, to change the way people do their work?
Believe it or not, I’d have said the same thing about going from SharePoint 2007 to SharePoint 2010, because as these technologies change, we always ought to be rethinking them. We should be applying a lot of the same rigor we’ve applied to any other migration when it comes time to move from classic to modern.
Q: The biggest mistake made when modernizing SharePoint experience?
A: What I see here—it’s interesting. The biggest mistake I’ve seen people make is that they try to just lift up what they had in the past and drop it into the future.
When you go from classic to modern experience, there are a lot of rules that change; a lot of things you could achieve in classic that just aren’t possible in modern. If you don’t think about each one of those things, you’re going to have some problems.
The classic example, so to speak, is the content editor web part. Lots of people have put content editor web parts into pages, and then they want the script, or the HTML, and/or the CSS that’s in that content editor web part to just work in modern. That just isn’t there. There is no such thing. That’s an example of something that will be a gotcha if you don’t do your research and really think about what it means to go from classic to modern.
There are also a lot of organizations that have just gone nuts with, you know, sort of pixel-perfect branding in classic, often using a content editor web part or a custom master page. Again, no content editor web part, no master page! Microsoft started discouraging us from using master pages, but what they didn’t say—which I think was sort of a mistake—is that there simply isn’t an equivalent in modern! You can’t just think about trying not to use it; you cannot use it.
So, those are the kinds of mistakes that I think come most often. I think the biggest one is when people just lift up their content from classic and drop it into modern while leaving it structured as-is.
If you haven’t learned anything while you’ve been using classic, if you haven’t come up with ways to reorganize that content and those sites in this transition, then you’re probably not doing the transition correctly. Not only would you probably not be taking advantage of the tools as well as you could be, but you probably won’t be driving your organization forward. You won’t be improving the things that you’re trying to get out of the platform itself.
Q: When to use subsites in SharePoint’s modern infrastructure?
A: Until a few months ago, we were very clear on saying that if you have a big pyramid, you’re going to have to go to very flat—you know, single-layer flat.
As of a few months ago, we’re allowed to create subsites in those flat team sites. So, the advice there is changing a little bit. You know, “Oh, okay, we’ll let you have some subsites.” But the idea of having subsites in the first place is still discouraged.
The idea is, by having flat sites, a flat topology, we have more options to sort of move things around as our organization changes. The classic example there is when a business reorganizes—when business units combine, when we merge with another company, when we decide that the IT department works under finance instead of under its own auspices.
There are all kinds of things that happen over the course of an organization’s lifespan. By making sure that we think about the purpose of those subsites and whether they should be a real site themselves, or whether they might still make sense as the subsite of a new modern site—that’s a big shift. That’s a way to rethink things.
The default answer should be no subsites, but there will be exceptions, and you’ll just need to sort of mindfully make those decisions.
Q: When should SharePoint remain in classic mode?
A: An organization should think about staying in classic mode as long as they have heavy customizations that can’t quickly be moved to modern.
So, if you have specific functionality that’s built that way, you’re going to want to stay in classic while you work out how you’re going to move that functionality into the SharePoint Framework. You’re going to have to re-engineer a little bit. The way you deploy SharePoint Framework solutions is different, so you’re likely going to need to involve some IT folks to make that happen.
Traditionally, we’ve been able to build things in content editor web parts without getting IT involved, which is often a good thing, because we can accomplish things fast. We have citizen developers who can really accomplish a lot, and that’s been great. So, that’s one thing that I think will keep people in classic.
A reason for staying in classic shouldn’t be “But we’re used to it.” That’s not legit.
The fact that we don’t like things to change is a sort of natural human condition, but I think we need to understand that the progress that Microsoft is making with the modern UI makes it worth going there. So, don’t use “We don’t want to put our organization through a lot of change.” Don’t let that be your excuse to remain in classic.
Q: Reasons why you might not be ready to adopt SharePoint’s modern experience?
A: You’re not ready to go modern, probably, if you don’t have people in your development organization who are willing to make the shift to these new tools.
If you’ve moved from on-prem to SharePoint Online, you’ve probably already gone through a shift in the way your developers are able to build things. There is no more full trust code deployed to the server, so, you know, that was a “pry it from my cold, dead hands” moment we’ve had to go through. Now, if you’ve got developers who are working on things in script—you know, putting script into pages and things like that—or deploying things as add-ins, you’re going to want them to be able to move into the SharePoint Framework development model, and there is a learning curve there.
You’ll want to time your migration to modern so that it’s not in the middle of some big development effort, because you won’t be able to finish it the same way. You certainly ought to look at your development calendar and figure out when a migration makes sense.
Another reason why you might not want to go to modern at this very moment is if you have an active application that people are currently using that you’re going to have to re-think and then re-deploy with a different engineering underneath it.
I think that training is often a thing that comes up as a reason not to go from classic to modern. “But we’re going to have to teach everybody all of this new UI!” I don’t think there’s as much to learn as a lot of people think. We’ve been using the modern UIs for lists and libraries for quite a long time now. You may not realize you’ve been using them, but that’s what you’ve been interacting with—unless, of course, your admins have turned off those modern UIs.
Training users on the differences between the modern UI and the classic one ought to be minimal, so I don’t think that that should be a big blocker. Large organizations are always looking for ways to teach people that change is coming—there needs to be something of an internal PR push. There’s got to be marketing inside the organization to make sure that people are ready for it.
So certainly don’t do it cold turkey, because that won’t work. I think it’s less of an issue of organizations being unable go to modern for a specific reason; it’s just a matter of making it a mindful shift. Again, just like any other migration project or software update, we need to think about what impact it’s going have on people—how will they feel about the change?
We don’t have to do everything all at once. We can move a department from classic to modern. We can move an office from classic to modern. We can move projects from classic to modern. I always encourage people to do a lot of piloting. I say a lot, but I don’t mean that you do it for six months or a year; you just need to test with some control teams. Pick a project or a department that tends to be very interested in going with the flow, and try these things out with them. You try out a modern UI with them and see how it goes. See what the hiccups were. And that becomes part of the feedback loop that you use to work better with the next wave of testers. But try to time things correctly based on what’s going on in your organization. Once you’ve done some piloting, it’s time to bite the bullet and try to move forward.
Q: If we could improve one thing about SharePoint’s modern experience, what would it be?
A: One thing I think it would be nice to change about the modern experience in SharePoint is, when we create a new Office 365 group-backed team site, it comes with a bunch of other goodies. Susan Hanley always calls it the Oprah principle: “You get a Planner, you get a Planner, you get a site!”
We get all of those things, but when you go to the SharePoint site–which, for a lot of the clients I work with, is still the de facto entry point to the platform—you can’t easily figure out how to get to those other gifts you’ve been given. How do I get to Planner? I don’t see it anywhere. How do I get to my team? There’s no link for that. Yes, there are things behind the waffle, but they link to Planner, the application–not the plan that I have for this particular team.
I think it would be great for Microsoft to come up with a better way to help people navigate the different tools included in an Office 365 membership, rather than subject users to this weird pattern of going out to go in—you know, out to Planner and in or out to Teams, and then back into the particular team. I think we’ll see some improvements here sooner than later.
But that’s the one thing that I struggle with in the modern UI: how do I get from place to place in the fewest clicks possible? I tend to write stuff in the browser bar, which means that something’s not quite right.