SharePoint Migrations: The Ideal vs. the Realistic
Whether you are upgrading your SharePoint environment from SharePoint 2010 to SharePoint 2016 or 2019, or from an on-premise version to SharePoint Online, most of us plan our migration with an ideal scenario in mind. There will be a dedicated migration team, a dedicated testing team, a group of highly skilled developers and administrators, and one meticulous, Type-A project manager with scheduling and resource management expertise to boot. Oh, and all your users will collaborate and cooperate at every stage, deleting old content and checking in documents to ensure their content migrates successfully.
The alarm on your smartphone rings. You get dressed to go to the office where your migration, testing, developers, and administrator teams are all one small over-tasked group, about 5 resources short of what you really need. One of your senior administrators is out sick or on leave, your project manager just started two weeks ago and her badge still doesn’t work, and none of your customers have responded to the email sent out a month ago requesting they do the cleanup of their SharePoint sites to prepare for the migration.
So, in the real world, here are some of the things we have learned during large, enterprise SharePoint migrations.
Go hard or go home first. This means tackle your most difficult areas first. For example, if you have some legacy websites or applications that will be migrating to SharePoint from a non-Microsoft platform; or if you have a particularly complex SharePoint web application (contains PII, custom-coded applications, heavily customized HTML, etc.…), migrate that content first. Why? Because everything that can go wrong with migrating that type of content will. The biggest lesson we learned here is how long it takes to migrate massive amounts of data. All of the errors, forms and workflows that need to be re-developed or re-mapped will happen during most difficult evolution. The rest of your migration will seem relatively easy and you will have plenty of wisdom to apply when similar issues arise on the less complex content.
Custom apps built with Visual Studio 2012 or earlier can have major functional issues; opening them up to correct them after migration may only be possible if you have VS 2012 (which is typically not installed in an SP 2016 environment).
Customized master pages in SP 2010 will lose most (if not all) of its customizations migrating to SP 2016 on-premise and SharePoint Online.
SharePoint List Forms customized with InfoPath will lose their customizations. Be prepared to rebuild them.
If there are a lot of itemized permissioned content throughout your SharePoint environment, this will greatly increase the time it takes for the migration of data to complete. Grab a Snickers.
Plan and finalize architecture change decisions upfront. We have never had a customer that did not want to implement a major redesign of their SharePoint intranet during a migration. To be honest, we have never had a customer who did not need an architecture redesign of information, page layouts, or consistent URL and managed path structure. If this is the case for your customer, do it first or you will never have time to do it at all.
Have the discussion with your customer about customized HTML pages. Most of the custom designs will be lost during the migration so have a design plan before you get started.
Design a uniformed page layout that is compatible with SharePoint 2016/2019. The simpler the better.
Plan to replace those old “default.aspx” pages and what they will look like.
Content yard sale and bulk trash pickup. We advise our clients that migration to a new platform is like moving from your old house to the new one. You would never take that old futon from the condo to your new single-family home so why take old documents and team sites that have not been touched since 2009 to your new SharePoint environment? The same goes for the Access Web Database you built to track inventory on your SharePoint site. Not only is it not compatible, but you also have not touched it since you built it. There are 25 checked out pages in the Pages library and 15 of them are named “Test.aspx and Test1.aspx”.
Checked out pages do not migrate
Non-HTML5 compatible web pages will not migrate successfully (the page may be there, but the design will not.
Decide how to move content from a deprecated asset to a new source before the migration (i.e. content from Document Workspaces, Access Databases, etc.)
What tool should we use for migration? We do not advocate for one migration tool over the other. What has been our experience is it depends largely on the size of the migration, the complexity of the content, and the timeline and resources you must work with. Some tools are better for migration from one Office 365/SharePoint Online tenant to another while others are better suited for the enterprise on-premise scenarios. This is where detailed planning will be extremely helpful to your success.
What are some of the things you learned during your last migration? How did a migration from SharePoint On-Premise to Online differ? We would love to hear your experiences!