In this blog SharePoint Online Migration Process you will learn an overview of how to plan and execute content migration to SharePoint Online.
SharePoint, to organizations, has been everything from document repository to advanced workflow and management system to integrations with different lines of business. It started as a
SharePoint Portal Server 2001 -> SharePoint Portal Server 2003 -> Microsoft Office SharePoint Server -> SharePoint Server 2010 -> SharePoint 2013 -> SharePoint Server 2016 -> SharePoint Server 2019 and SharePoint Online. Organizations today are increasingly moving towards SharePoint online and rightfully so. Microsoft has adopted a Cloud first model. Hence cloud is where Microsoft is continuing to drive innovations. Moving towards SharePoint Online involves a complex migration process which is different than migrating to newer SharePoint On-Premise version. It involves four stages which needs to carefully planned and executed. Every stage has set of tasks and an outcome documents
As and when we think of migration (of any kind of data) we need to answer below question.
What has to be migrated?
We have to first list all the data sources that needs to be migrated. Inventory preparation is the listing of data that needs to be migrated from current environment to the new environment. Data in current environment could at different places viz. SharePoint sites, file shares, google drive etc. All such data sources have to be marked for migration.
Once the data sources are marked, we have to mark which data from those data sources is required to be migrated. Not all data is required. Hence this is also the phase where a cleanup exercise can be initiated. It could be possible that some sites were created for a certain project. The project was completed long back and there is no need of that particular SharePoint site. There could be SharePoint sites which were created to support an application but now that application is no longer in use and so those SharePoint sites are no longer required. All that data is of little or no use. A decision can be taken for their cleanup.
So the inventory preparation (within SharePoint context) would involve below three sub stages.
Once the inventory is prepared, the next step is know the pain points in the migration. Migration to SharePoint online falls on the complex side. However, with some care and due diligence, complexity can be reduced. Inventory will give us all the sites we need to migrate and assessment will give us the type of data that these sites contain. We analyze the data to know the below details
How to Assess?
There are couple of tools in the market as described below
After the assessment reports are extracted by any assessment tool listed, next step is to analyze those reports and categorize the sites based on their complexity.
a. Very Complex: Any site which is very large and contains custom solutions, InfoPath forms, third party workflows, integration with external data sources can be considered very complex site to migrate and could take up to 2-3 days to migrate and remediate.
b. Complex: Any site which is very large and contains InfoPath forms, third party workflows, integration with external data sources can be considered complex site to migrate and could take up to 1-2 days to migrate and remediate.
c. Medium: Any site which is large and contains high number of pages to remediate, Potential broken links, large number of lists/libraries but no other complexities can be considered site of medium complexity. These kinds of site should not take more than 2-3 hours to migrate and remediate.
d. Simple: Any site which is small in size and does not contain any complex components listed above can be considered simple site to migrate and remediate. These sites should not take more than 45 minutes to migrate and remediate. Maximum number of sites in any migration project are simple.
Based on the site categorization, project plan and efforts in terms of person hours can be calculated. These efforts will be used to calculate overall project cost and timeline. Preparation of project plan, costs and timeline is out of scope for this document.
Migration to a newer version of SharePoint and specially SharePoint Online is considered a big change and any change requires proper change management process to be followed. If not done properly, this will adversely affect user adoption which is the bedrock for any new technology adoption to succeed.
If users are not ready to accept the change of technology and adopt in their daily routine, then the investment goes in vain. Hence change management is a very crucial part of any migration to SharePoint online and well defined communication process is a crucial part of change management.
Communication Process in SharePoint Online migration consists of 3 pillars:
Mail Communication: Mail Communication is intended for Site Owners. An automated mailer is sent to all the site owners of the site which is scheduled for migration in next wave (explained later). The mails should be sent 4 times as per below schedule. If the migration date is MD then
Here, migration day could be more than 1 depending upon the size and complexity of the site. Hence the fourth mail communication is dependent on the migration data. Also in case of incremental/delta migration (explained later), the fourth mail communication will differ.
Banner Communication: Although mail communication does the work of informing the site owners but that may not be enough as site owners might miss out communicating the same to the actual users of the site. Hence banner communication is intended to inform all the users of the site about the upcoming migration of their site. There could be the cases when the listed site owners have moved out of the department, organization and no longer responsible for the site. So the banner communication is very important. Site users can prepare for the migration. To catch the attention of users, banner color would differ for every communication. If the migration date is MD then
Again, fourth banner’s date depends upon the site size and the condition if the migration contains delta migration or not. It should be noted that banner communication goes hand-in-hand with the mail communication.
Q&A Webinars: Migration to a newer version is a big change for any organization. Hence, the site owners and their site users might have lot of doubts and queries which needs to be resolved to allay their concerns and increase their adoption of the new technology. This in turn necessitates Q&A webinars.
Webinars can be scheduled before and after the site migration. Any webinar would be a meeting between migration project team, project stakeholders and the site owners of the sites (undergoing migration in that particular wave). Q&A Webinars although are optional but very helpful. If not webinars, an organization can also create a migration help site which lists FAQ containing most asked questions. A recommended way would be to have both Q&A Webinars and a migration help site
Once the assessment and initial plan is prepared, it is time to test the environment and the planned process for a pilot migration. The main goal of pilot migration is to test the overall process and plan and hence it should be mirror of wave migration. Pilot migration tests below factors:
Pilot migration size should be chosen carefully. It should not be too high so that it takes weeks to finish and it should not be too low so that it does not give us the fair idea of above factors. Generally it is kept at 100 GB of sites but it can vary based on overall migration size. Also, the selection of sites should be wise too. We should choose all the category of sites i.e. small, medium, complex etc. However, it should not be made too complex as well. Pilot should not take more than 3-4 weeks to finish.
It should be as close to wave migration as possible in terms of overall process i.e. it should involve all the steps that any wave would involve. We should try to iron out as many issues as possible in the pilot migration. The more the number of issues we can resolve in pilot migration, the smooth the wave migration becomes. If we keep pilot migration smooth and easy, wave migration becomes tough and that is not the recommended way.
After pilot migration is done, we should go back to the migration plan, refine it based on the results of pilot and come up with a final migration plan and timelines for the wave migration
After the pilot migration and final migration plan are done, comes the wave migration. It consists of below steps in sequence
|Sr. No||No Incremental migration||With Incremental Migration|
|1.||Selection of sites||Selection of sites|
|2.||1st communication to site owners (selected sites)||1st communication to site owners|
|3.||1st banner insertion||1st banner insertion|
|4.||Site Permissions restricted (No new list creations)||No change to site permissions|
|5.||Create destination sites|
|6.||Input all sites to migration portal||Input all sites to migration portal|
|7.||2nd communication to site owners||2nd communication to site owners|
|8.||2nd banner insertion||2nd banner insertion|
|9.||Update migration portal||Update migration portal|
|10.||Pre migration Webinar||Pre migration Webinar|
|11.||3rd communication to site owners||3rd communication to site owners|
|12.||3rd banner insertion||3rd banner insertion|
|13.||Create destination sites|
|14.||Change source site permissions to read only||No change to source site permissions|
|15.||Automated Site Migration||Automated Site Migration|
|16.||Automated Remediation and Verification||Automated Remediation and Verification|
Apart from the communication steps (which are mentioned in Communication process) all other steps are explained below
Automated remediation and verification: Just like migration, verification of sites post migration can also be automated with PowerShell or .NET console apps. However, not all types of verification/remediation can be automated. For ex. InfoPath forms, workflows, any custom solutions etc. have to be manually verified, tested and then confirmed to be passed in validation
Go live of the site happens when it has been migrated, remediated, verified and tested by business users successfully. Post that the old site will have final banner which will contain the URL of the destination SPO site. Now there could be difference in the amount of time depending upon if the migration had delta/incremental migration or not.
With Delta Migration: If the migration contains delta migration, then the source site is not made read only during the bulk migration. The users still can work on their site as usual and any delta content that was added during the migration time is migrated again during the delta migration. The delta migration is generally carried out during weekends and site is then made read only for general site users. Post the delta content has been migrated, the sites are handed over to business team for UAT. Once the business users are satisfied, the new site in SPO is made available to users. So below activities are carried out.
Without Delta Migration: In case of no delta migration, then the source site is made read only during the bulk migration itself. The business validation starts soon after bulk migration, remediation and validation. Once the bulk migration is done, business team tests the sites and after confirmation, the new sites are released for general use. So below activities are listed only for Go Live. Rest all are same as explained in Wave migration
Hyper care: Post Go live, there is a two weeks period of hyper care which is available to general users to report any migration issues they face in the new site. The issues can be raised in organization’s ticket support system or a separate mailbox can be created. This period is available after every wave