So, that time has come, SharePoint 2016 has been around for a while now, stood the test of time over the past few months and now you want to upgrade. Well where do you start?
That depends on what version you are upgrading from, 2003, 2007, 2010, 2013 or something else. Depending on the source will depend on the approach. However, understanding the options and what can and can’t be done is important for any upgrade.
So, let’s look at some of the reasons to upgrade, apart from the obvious which would be because it is new and shiny.
Microsoft have made great investments within the cloud components of SharePoint 2016, as well as better support for files and patching. With the new MinRole components performance has also been increased, based on the servers only actually having the components running that are needed. If these are reasons to upgrade then you have chosen correctly, if you just want to upgrade, though that is okay, you need to think about what features are going to enhance the overall user experience and warrant the effort to upgrade.
To get to SharePoint 2016 there is only two options, the first is not an upgrade but a migration, the second is the upgrade. As with previous versions of SharePoint, the database attach is the process of getting from SharePoint 2013 to SharePoint 2016. There is no direct upgrade or database attach process for anything older than SharePoint 2013. To get from SharePoint 2010 to SharePoint 2016, either a new SharePoint 2013 Farm will be need to perform an interim upgrade or a migration process instead. SharePoint 2016 also does not support site collections running in SharePoint 2010 mode so these will have to be changed before upgrading. You can use the following PowerShell to see what sites are running on the old mode.
Get-SPSite -Limit All | ? { $_.CompatibilityLevel -eq 14 }
To complete an upgrade to SharePoint 2016 the following sequence should be followed:
Audit
Knowing what is stored within your SharePoint environment as well as versions of the components will allow you to determine the correct steps to follow. Take time to review site collections, databases, deployed components, UX Branding and anything else that is part of the SharePoint Farm
Build
A new SharePoint 2016 Farm will need to be created. Based on the core designs recommended by Microsoft, MinRole should be used to create a better performing SharePoint farm, and a more compliant design.
Pre-Upgrade
The Pre-Upgrade step is about knowing what is there, and testing the upgrade process. The following items should exist within your checklist:
- Complete the Inventory Phase
- Clean the current Environment – remove old content and unused components
- Perform Test Upgrade, then delete as needed
Upgrade
Once the upgrade has been tested, then you can perform the full upgrade. All Service Applications need to be provisioned, backed up and deployed as needed before sites are added and upgraded. You will need to ensure that the Farm Passphrase is known and ready to use within the new SharePoint environment if you are moving Service Applications from 2013 to the new 2016 environment. All content databases or at least those you wish to upgrade need to be backed up and moved to the new SQL Server, along with Service Applications for Business Data Connectivity Services (if using), PerformancePoint (if using), Search Administration, User profile and Secure Store Databases.
The databases can then be restored and attached ready to be used within SharePoint 2016. The following PowerShell can be used to restore the Service Applications.
Secure Store
$sss = New-SPSecureStoreServiceApplication -Name 'Secure Store' -ApplicationPool $applicationPool -DatabaseName ‘Restore_Database_Name' -AuditingEnabled
User profile Service
$upa = New-SPProfileServiceApplication -Name 'User Profile Service Application' -ApplicationPool $applicationPool -ProfileDBName ' Restored_Profile_Database_Name' -SocialDBName ' Restored_Social_Database_Name'
-ProfileSyncDBName ‘Restored_Sync_Database_Name'
Search Service
Restore-SPEnterpriseSearchServiceApplication -Name 'SearchServiceApplicationName' -applicationpool $applicationPool -databasename ‘Restored_Search_Service_Administration_Database_Name' -databaseserver ServerName -AdminSearchServiceInstance $searchInstance
Once the core Services have been restored, you can then test the content database process by using: Test-SPContentDatabase, if that completes as expected then you can use the Mount-SPContentDatabase to attach this to the Web Applications as needed.
Test
Now that the upgrade has been completed, now you can simply test the site, service applications and all components of the new SharePoint 2016 environment.
Deploy
If you have not deployed any custom Solutions or Add-ins, this is where these can now be done. If you have moved the content databases from one farm to another farm, then you will have noticed that in testing some of them components will not load as they were not yet potentially deployed. Once these have solutions have been deployed the web.config entries and content databases entries will be matched back together and all should load.
Commit
Now that everything has been attached, upgrade, updated and modified then you can commit to the upgrade and start to swap everything over top the new farm. The goal is to ultimately end up running the decommission process and moving all users to the newly upgraded farm.
The last two steps are for you to test further and then either decommission components are all of the infrastructure. This is the final step and often can take some time as you get end user testing and signoff.
While running through this process the following are core considerations:
- Use Test-SPContentDatabase cmdlet to test a content database against a Web application to verify all customizations referenced within the content database are also installed in the web application
- The Mount-SPContentDatabase cmdlet attaches an existing content database to the farm. If the database being mounted requires an upgrade, this cmdlet will cause the database to be upgraded
- The Upgrade-SPContentDatabase cmdlet initiates an upgrade of an existing content database that is attached to the current farm. This cmdlet begins a new upgrade session, which can be used either to resume a failed version-to-version or build-to-build upgrade of a content database or to begin a build-to-build upgrade of a content database
- The Upgrade-SPSite cmdlet activates the upgrade process for the specified SPSite object. You can also use this cmdlet to resume failed upgrades. When you use this cmdlet to initiate upgrade on an SPSite object, the object can be either a build-to-build or version-to-version upgrade
While working through the database upgrade process, remember to following these core steps:
To create a perfect upgrade takes time and effort. Following the right order of steps is important and will ensure that you get the solution completed with minimal downtime and issues.
