This requires strategy, planning, communication, technical knowledge, troubleshooting skills, great execution and sometimes a bit of luck. They say in life, moving is one of the most stressful experiences anyone can go through. SharePoint Migrations definitely fall into that category if not managed and handled well. The SharePoint A Team have been hard at work creating the most comprehensive SharePoint Migration Checklist for anyone’s migration project.
Automated Tools Guide for the SharePoint Migration Checklist.
Including influential users in the planning and implementation stages of the migration can prove very beneficial. Users can provide both “on-the-ground” feedback during the migration and communicate their SharePoint requirements and expectations. Along with Metalogix and Sharegate tools check out SharePoint vitals to see how you can identify the most influential users in SharePoint.
An often overlooked area of the cleanup process is removing orphan users. Orphans are users who no longer have a linking AD account. Orphan users may also have active SharePoint alerts or My Sites. While orphan users can no longer access the content, any legacy alerts and notifications can impact SharePoint’s hardware resources. Cleaning out orphans before the migration will help teams gain back resources and better predict SharePoint user growth.
Users who have failed to adopt SharePoint before can give useful insight as to why. This is an opportunity to address those concerns and rectify them in the new platform.
Checked Out Documents don’t migrate so well, its important to reach out to users and get them to check in their documents. Else takeover those checked out documents, check them in and migrate them intact.
Custom permissions can cause frustration and confusion at first but later serious security risk. Its important to find all custom permissions and move them to group permissions wherever possible.
Site Collections (or sites) often outgrow their original size. This may point to a potential resource issue. Very large site collections can impact performance which in turn will likely hinder your migration plans. There is an opportunity to review the content and split the site collection on usage and site structure if a database has grown too large.
Any content database over 100GB in SharePoint 2010 and SharePoint 2013 is going to cause issues for backing up and restoring as its not supported. These limits have been removed for SharePoint 2016 however its still not a good idea to keep all your eggs in one basket.
As part of a migration plan, you might decide to reorganize your sites and promote some of them to site collections based on their size. All sites above 100 GB might be candidates for promotion to Site Collection.
Microsoft has documented best practices for the size of Site Collections that should be followed.
Identify small site collections and demote them to sub sites. Often user requests for sites are satisfied by creating site collections. Over time, it might become apparent that those site collections could or should have been created as sub sites of a different site collection.
It’s not uncommon for SharePoint to be the repository for the same document in multiple places. Migrating multiple versions of the same content will cost time and money, best locate those duplicates and remove them where possible.
Audit logs can be potentially huge excel files and may be better off in blob storage or in alternative locations.
Content types are a powerful tool in SharePoint that enable organizations to organize, manage, and handle content in a consistent way across site collections. Gaining insight into the custom content types and where they are being used will help determine how the data will be managed once you migrate.
Investigating the use of Content types will also help to highlight opportunities for creating enterprise content types that will provide broader scope. Remember you will also need to setup the Content Hub on your source location before migrating any content.
Web parts are used everywhere – your SharePoint environment probably includes Microsoft web parts, custom web parts, and third party web parts.
Create an inventory of your customizations. Take a look at what needs to be migrated. A migration is the perfect time to identify what you don’t need anymore, and leave it there. Also, make sure you have a good overview of what you have in your sites (WSP, Sandbox, etc), and if one depends on another. Map it out to be sure to deploy everything in the right order at the destination.
Are you running any Farm Solutions? Most likely they will still work on the destination farm and if they are 3rd party most likely have an update. Microsoft have leaned towards developing on the SharePoint Framework from here on out, so we would suggest looking at updating any WSP’s and webparts with that mind.
Do you have any Sandbox Solutions? Its time to upgrade them leveraging the SharePoint Framework.
A migration is the best time to wipe the slate clean and start over. Make sure you take the time to plan and structure your new home according to your needs. You might not get the chance again for a long time.
- Build source SharePoint Farm
- Map your destination’s architecture
- Optimize your new SharePoint Servers’ performance [At the install]
- Configure all Web Applications
- Check desired authentication and authorization rules
Backup the new SharePoint environment (Fall back if all goes wrong)
- Configure your new Search Topology.
- Deploy all 3rd party and custom solutions
- Update Content Hub
- Import Termset and Metadata
- Set SharePoint up to import user profiles from any specific sources. (Only for SP2010 and 2013)
- Look at your customizations
- If required, convert them to work in the new model/destination (see appendix)
- Backup the migrating environment
- Restore the migrating environment to th
e new environment
- Check the databases for corrupt data
- If any corrupt data: delete it.
- Run a Test Migration
A big part of the SharePoint Migration Checklist is to ensure the migration schedule is made available to all users. The expected downtime or freeze period needs to be communicated clearly to each site owner well in advance of the migration process.
This will ensure you can manage your users expectations and be flexible to requests. It is strongly advised to notify all key stakeholders and users after each migration phase of the project.
Migrations that are not tested thoroughly often result in data being lost. A a formal UAT document that has been signed off by selected users will give peace of mind before the final cut-over. UAT users should be identified during the analysis phase and made responsible for testing their sites and identifying issues that can be rectified prior to the final incremental migration cut-over.
- Inform users before the migration
- Downtime planned during the migration
- The reason for the change and the value for them (New Features and Scenarios)
- Possible changes in the environments
- URL changes
- Document References (Excel macros, etc)
- New look and feel
- Estimated timeline for the migration
- Create sandbox sites for hands-on previews for users to test out new features and experience the new look and feel
Run the migration and deal with issues as they arise, making notes is essential. Its even easier if you have the right tools.
- Complete or Stop running Workflows about to be migrated Migration scenarios
- If migrating from SharePoint 2013 On-Premises
- Switch source farm to read only during this communicated freeze period to avoid having to run too many incremental
- Perform database attach-upgrade to bring everything “as-is”
- Use a third-party tool such as Sharegate or Content Matrix to granularly migrate and restructure as you move
- If migrating from an earlier SharePoint version
- Use a third-party tool such as Sharegate or Content Matrix
- Or you could be the one person who does a double hop migration from 2010 to 2013 to 2016 with content database attach method. Please don’t be that person.
An important step to check the newly migrated content for any required fixes, before notifying the user base.
- Test your Destination Environment
- Ensure all migrated successfully
- Test/Run all workflows
- Check user permissions
- Setup DNS changes to point to new location and update GPO to load new Intranet
- Create a backup of your new environment
- Keep old SharePoint in Read Only for a month while users get to grips with the new environment. Remove DNS to the old SharePoint.
- Create Post Migration Issue list for users to update and track fixes.