Now, I could start this article by asking you, "Why aren't you using SharePoint Online?" But I won't. Instead, I'm guessing that you're running a previous on-premises SharePoint Server version:
- SharePoint Server 2013
- SharePoint Server 2010
- Microsoft Office SharePoint Server (MOSS) 2007
and you want to upgrade to SharePoint Server 2016. What are the rules of the road? What are the core "gotchas" you should try to avoid? Let's round up the "biggies," one by one.
Supported upgrade from SharePoint Server 2013 only ^
The only supported SharePoint Server 2016 upgrade path is from SharePoint Server 2013. Yes, you heard me correctly: if your farm runs SharePoint Server 2010 or MOSS 2007, you'll first need to upgrade to SharePoint Server 2013, and then perform the direct upgrade.
Moreover, the "direct upgrade" to SharePoint Server 2016 works the same as a 2010-to-2013 direct upgrade does, which is to say, via the database attach method. I'll cover how to perform a database attach upgrade in the next section; for now, I want to explain how to upgrade from SharePoint 2007 to SharePoint 2016 incrementally:
- MOSS 2007 to SharePoint 2010: In-place upgrade in which you can overwrite your previous SharePoint version directly
- SharePoint 2010 to SharePoint 2013: Database attach ¸upgrade
- SharePoint 2013 to SharePoint 2016: Database attach upgrade
The good news here is that you do not need to purchase a license for intermediate SharePoint versions. In fact, you can download evaluation versions that will work fully throughout your upgrade process.
How a database attach upgrade works ^
In a database attach upgrade, you deploy a new farm for your SharePoint Server 2016 infrastructure. For this reason, I think we can call this more accurately a migration instead of a traditional upgrade.
You'll need to connect the new SharePoint 2016 farm to a fresh SQL Server database instance; after all, you need to isolate the 2016 farm from the downlevel farm completely.
According to the excellent TechNet SharePoint technical diagrams, your first step is to document your existing environment. A number of community PowerShell scripts and independent software vendor (ISV) tools can accomplish this goal. Your purpose is to isolate orphaned resources, custom code, and site customizations that may cause the migration process to fail.
Your second step is to back up supported content and service application databases, and restore them to your SharePoint 2016-associated SQL Server instance. Check the documentation because SharePoint Server 2016 does not support all service applications.
Your third step is to use Windows PowerShell or the SharePoint Server 2016 Central Administration web application to (a) run a health check, (b) mount, and (c) upgrade the downlevel content and service application databases in the context of the SharePoint 2016 farm.
As you can see in the screenshot below, Central Administration has a site section devoted to the upgrade and migration process.
Just like we can in SharePoint 2013, we can upgrade sites on a site collection-by-site collection basis, and run health checks prior to doing so.
SharePoint edition gotchas ^
Up until SharePoint 2013, Microsoft released free SharePoint versions intended for proof-of-concept or upgrade enticement purposes. SharePoint 2016 includes no Foundation edition, so you'll need to upgrade to at least the Standard edition prior to beginning your SharePoint 2016 upgrade process.
If you're currently running a SharePoint Standard edition farm, then you can upgrade to SharePoint Server 2016 Standard edition, add an Enterprise key, and upgrade the farm's functionality.
That said, Microsoft strongly advises against upgrading from a prior-version Enterprise edition farm to SharePoint Server 2016 Standard edition. The reason is that the upgrade may fail if SharePoint expects to see (or rather, not see) Enterprise edition dependencies in the current farm.
What can go wrong? ^
By far, the two most common SharePoint upgrade problems are (a) custom code, and (b) site customizations.
I hope it makes sense to you that the SharePoint Server development team has no earthly idea what your farm (or even sandboxed) solutions are, and how they influence the SharePoint farm environment. The team can validate the in-box code, but cannot do so for your stuff.
This means that the onus is on you to verify that your code will run the same way under SharePoint Server 2016 as it will under your current version. You can do this fairly simply by deploying a test farm using evaluation software and virtual machines (VMs).
The same rule applies to site customizations.
Consider hiring a specialist ^
Have you ever heard of the Dunning-Kruger Effect? This psychological model describes when a person doesn't know that he or she doesn't know something. More to the point, the person in question overestimates the extent of what they do know. This is a recipe for disaster in something as complex as a SharePoint migration.
So… to my mind, there is no shame at all in sourcing and hiring a SharePoint migration specialist. One the most interesting things about the SharePoint ecosystem in my opinion is how many revenue streams SharePoint opens for ISVs, managed service providers, and Microsoft partners.
For your research, here are some reference links:
If you're not willing to hire a consultant but want help in the form of tooling, there's plenty available in that space as well. Consider the following products to get you started:
Next steps ^
Well, there you have it! Overall, I'd say that if you've performed a SharePoint database attach migration in the past, then you'll find the process works exactly the same in SharePoint Server 2016. Of course, you have the new features (particularly MinRole) to contend with, but we'll leave that subject for another 4sysops blog post.
I'll leave you with some supplemental learning resources.
- Overview of the SharePoint Upgrade Process
- 10 Tips to Get Ahead on Your SharePoint 2016 Migration
- Choosing Your Upgrade Path to SharePoint 2016
- Upgrading to SharePoint 2016 - Step by Step