What does it take to migrate on-premises SharePoint 2010 to Microsoft 365? There’s a few things you need to understand and plan for before you upgrade SharePoint 2010 to SharePoint Online in Microsoft 365.
While sitting on a panel at a SharePoint conference, I heard a very good question: “We’re on SharePoint 2010 and are planning to go to SharePoint Online in Microsoft 365. Is there anything we should do to get ready?”
I imagine the person who asked the question isn’t the only one in this situation. As Microsoft 365 becomes more and more appealing, those with SharePoint 2010 will eventually find themselves facing a similar dilemma.
Want to level up your Microsoft Teams end-user training? Watch our on-demand webinar with Microsoft MVP and training specialist Andy Huneycutt, and hear how he built a scalable training platform that leverages the full power of Microsoft 365, including helpful tips for training your colleagues and clients to be stronger Teams users.
Get expert advice on how to train your users to use Teams better.
What to know before you migrate SharePoint 2010 to Microsoft 365
Coming from SharePoint 2010 is a good scenario when moving to Microsoft 365. There aren’t that many potential issues to watch out for, although there are some important things you should know.
First things first. We have to look at what we’re going to use for our identity store. SharePoint 2010 on-premises uses your Active Directory to see users and groups, as well as for authentication. Of course, you may have set up SharePoint differently. But in most situations that’s what’s going on.
So before even starting a SharePoint upgrade, we have to figure out what we’re going to do with this. There was another very interesting question at this same panel: What is the difference between ADFS, Azure AD, DirSync, and Office 365 users?
ADFS: Active Directory Federation Services (ADFS) is a secure tunnel between your on-premises servers and your Microsoft 365 environment. The purpose of this tunnel is to keep all your users, and the management of identities, in your own Active Directory.
In short, Microsoft 365 trusts this tunnel—and can therefore offload identity management and authentication with your servers. Technically that’s not exactly what’s happening, but you can think about it that way in order to better understand it. The downside of ADFS is that it requires a server to install and set up.
Azure AD: If you don’t know this already, Microsoft 365 is really just a brand that packages Azure services together under one roof, one licensing and one administration console. When you create new Microsoft 365 users, they are actually created in an Active Directory service associated to your tenant in Azure. You don’t see this unless you also purchased Azure for your organization, only then will you see the service created for your Microsoft 365 users. And this is the scenario for all organizations that do not use ADFS and simply create users in their Microsoft 365. The downside to this is that if you have an On-Premises environment as well, you now have two places to manage users and passwords.
That’s why there is something called DirSync. DirSync essentially copies your users from your On-Premises Active Directory, along with some properties and if you want password (though it’s not the actual password being copied) and into Azure AD. Yes DirSync is a tool that copies your users. It’s easier to set up than ADFS, but means you now have your users in two locations, it’s not single sign on but “same sign on”.
Before you upgrade from SharePoint 2010 you should understand what you’re going to do with your identities, because you are not simply upgrading SharePoint but also going to the cloud. You can look at how to configure Microsoft 365 to use your Active Directory before upgrading to see how it’s done in the console and on your servers.
Know what you have and inventory SharePoint
Even if I told you everything that does not migrate well from SharePoint 2010 to Microsoft 365, if you don’t know what you have or where they are in your environment then it is useless information.
Your SharePoint inventory is crucial for this upgrade, but in my opinion goes way beyond just this project on your hands. You should always keep a detailed inventory of SharePoint to help you better manage it in the future.
Where are all the sites that have workflows, the lists with custom content types, and pages with Content Editor Web Parts? We need to know who the site owners are so we can go talk to them and ask relevant questions.
There are a few ways to inventory SharePoint:
Third Party Tools: If there is a need for something in SharePoint, you can bet somehow has built something to help with it. The ecosystem is large and we can easily find something to help us.
Obviously I work for ShareGate, so the one I will recommend is our own management tool since it does not require any server install and doesn’t cost an arm and a leg. You can try it out for free here.
However, I do recommend you check out all the different tools out there that can inventory your SharePoint so you can find the one that’s right for you.
PowerShell: PowerShell is extremely powerful and can do your inventory for free. The downside is you need to know how to properly use PowerShell. But it’s important to know that it can be done.
Since I’ve allowed myself to shamelessly plug our product I have also written a step by step to use PowerShell and Visio to build an inventory of SharePoint. You can use that to start building your inventory and of course work your magic to make the PowerShell give you exactly the information that you need.
Upgrading is the time to rethink everything and not just migrate
With things like Search and now Yammer and Delve working closely with SharePoint, you can’t simply copy paste what you had in Office 365. Some things will work differently and others will need to work differently to provide value to you. That’s why this is the perfect time for you to change while upgrading.
You’ll see the value of the inventory you built immediately during this process. Let me give you our secret here at Sharegate when migrating any environment to Microsoft 365.
We’ve implemented a model we have found to work very well: “RMR” aka Remove, Migrate, or Rebuild.
We essentially tag items in our inventory with one of these three items, helping us understand what we will need to Remove, Migrate or Rebuild during the upgrade.
Of course you can change these words to include other actions that make sense for your scenario. But we don’t stop there—highly influenced by SCRUM in our way of working, we also assign a “point” from 1 to 10 that represents the effort required to complete each action.
For example: If I have a site in my inventory that we’ve tagged as “Rebuild”—and I know it has a lot of customizations and there will be some unknowns in Microsoft 365—well, I also tag it with the number 8 or even 9 with my upgrade team. This way I can always set milestones and expectations by saying “In the next three months we will be able to do a total of 50 points, which ones from the inventory would you like me to do?”
Of course, this is from the perspective of a consultant, but it works just as well internally. Once again, building the inventory is extremely important.
Making the switch and upgrading to Microsoft 365
It doesn’t have to be an overnight thing. SharePoint has the advantage of being a web platform; it’s all hyperlinks and you can create your own.
What I mean by that is that even if one is SharePoint 2010 On-Premises and the other is Microsoft 365, the user won’t know and won’t care. Look at what needs to be done; maybe you can do the migration over the weekend, or maybe it’ll take a few months—just remember they don’t have to live separately.
Luckily enough, the upgrade from SharePoint 2010 isn’t a hard one in terms of technical features. What you need to watch out for, other than in the list mentioned in the url earlier, are thing like Customizations through code, Workflows, and Content Editor Web Parts that have content they weren’t meant to.