In our latest Fpwebinar, The Great Migration: Moving Your SharePoint, we bring in webinar pros Joe Beyer and Jesse Roche to help you navigate the SharePoint migration process. Joe and Jesse share their experiences and best practices that will make updating your version or moving your environment easy.
At the simplest level, a migration involves moving data, users, web parts and farm solutions from one version to another. It can involve moving your entire environment to a different data center or just upgrading from a previous version.
The change that users need the most preparation for is the differences in look and feel after the migration. For example, the changes from SharePoint 2007 to SharePoint 2010 were more drastic for users than the changes from SharePoint 2010 to SharePoint 2013. If you do receive pushback from users regarding the changed look and feel, there are ways that you can keep the look the same while still migrating the environment over to the new version.
There are three main types of migration methods to be aware of; in-place migration, database detach/attach migration, and third party migration.
While there are several possible issues to prepare for when migrating, a common factor are the Fab 40 Site templates created by Microsoft. These templates are not supported in later versions. While there are not many issues with them if you are doing an in-place upgrade, there hasn’t been much success in using upgraded versions created by Microsoft. These templates cause so many issues that third-party migration tools will not even attempt to migrate them.
Other common issues that occur during a migration are related to legacy web parts and customizations. Not all web parts are compatible with later versions of SharePoint. Before proceeding with the migration, contact the vendor of the web part and determine if it is compatible with the version you are moving to. But, the most common causes of issues during migrations are customizations and there is no simple solution. Instead, each migration with custom code, templates, lists, etc. will need to be addressed as one-offs.