SharePoint Online Migration Process

SharePoint Online Migration Process

In this blog SharePoint Online Migration Process you will learn an overview of how to plan and execute content migration to SharePoint Online.

Contents:

  • Introduction
  • Inventory Preparation
  • Assessment and Due Diligence
  • Site Categorization and Planning
  • Communication Process
  • Pilot migration & Wave migration
  • Go Live and Hyper care

1. Introduction

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

  1. Inventory Preparation
  2. Assessment and Due Diligence
  3. Site Categorization and Planning
  4. Communication Process
  5. Pilot migration and Wave migration
  6. Go Live and Hyper care

2. Inventory Preparation

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.

  1. Listing of all SharePoint sites from all Web applications
  2. Marking the sites as “Required” or “Not Required”
  3. Preparing a final list of all SharePoint sites post removing the “Not Required” ones

3. Assessment and Due Diligence

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

  1. Site size
  2. Number of lists and libraries
  3. Last modified date
  4. Number of Pages (Site Pages and Publishing pages)
  5. Site owner details
  6. Number of large lists and libraries (items > 5000)
  7. Any/how many/what type of custom solutions such as
    a. Sandbox Solutions
    b. Custom web parts
    c. Provider hosted apps
    d. Event Receivers
    e. Custom workflows or forms
    f. Site definitions
  8. Managed Metadata
  9. InfoPath forms
  10. SharePoint designer workflows
  11. Nintex Workflows or any third party workflows
  12. Any/how many/what type of third party applications
  13. Integrations with external data sources
  14. Checked-out files
  15. Potential broken links

How to Assess?

There are couple of tools in the market as described below

  1. SharePoint Migration Assessment Tool (SMAT):
    The SharePoint Migration assessment tool (SMAT) is a simple command line executable that scans the contents of your SharePoint farm to help identify the impact of migrating your server to SharePoint Online with Office 365. It scans against the SharePoint farm and associated content looking for issues that have been known to cause issues for customers migrating into SharePoint Online. More information can be found at this link
  2. Metalogix Migration Expert: This tool from Metalogix (Quest) analyzes user’s current SharePoint environment and provides immediate actionable steps for migrating content onto SharePoint online. It delivers findings against different metrics but the reports delivered are in PDF format which makes it difficult for post analysis.
  3. ShareGate SharePoint Inventory and Reports: ShareGate also provides tool which can assess the SharePoint On-Premise environment and provide a report on the parameters which could be pain point during migration. Apart from this tool, ShareGate also has some report templates available and a feature to create custom report for any of SharePoint objects in On-Premise farm such as List, User, Site Collection, Document etc.

4. Site Categorization and Planning

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.

5. Communication Process

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:

  1. Mail Communication
  2. Banner Communication
  3. Q&A Webinars

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

  1. First mail communication: MD – 3 weeks
  2. Second mail communication: MD – 1 week
  3. Third mail communication: MD – 1 day
  4. Fourth mail communication: MD + 1 day

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

  1. First banner (maybe yellow color): MD – 3 weeks
  2. Second banner (maybe orange color): MD – 1 week
  3. Third banner (must be red color for maximum attention): MD
  4. Fourth banner (may be grey color): MD + 1 day

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

6. Pilot migration & Wave migration

Pilot migration

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:

  1. Network bandwidth
  2. Latency
  3. Throughput
  4. Migration Plan and timelines

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

Wave migration

After the pilot migration and final migration plan are done, comes the wave migration. It consists of below steps in sequence

Sr. NoNo Incremental migrationWith Incremental Migration
1.Selection of sitesSelection of sites
2.1st communication to site owners (selected sites)1st communication to site owners  
3.1st banner insertion1st 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 portalInput all sites to migration portal
7.2nd communication to site owners2nd communication to site owners
8.2nd banner insertion2nd banner insertion
9.Update migration portalUpdate migration portal
10.Pre migration WebinarPre migration Webinar
11.3rd communication to site owners3rd communication to site owners
12.3rd banner insertion3rd banner insertion
13.Create destination sites 
14.Change source site permissions to read onlyNo change to source site permissions  
15.Automated Site MigrationAutomated Site Migration
16.Automated Remediation and VerificationAutomated Remediation and Verification
Fig. Steps to implement No incremental & with incremental migration


Apart from the communication steps (which are mentioned in Communication process) all other steps are explained below

  1. Selection of Sites: This is largely based on business requirement. Hence it should be done by the business team or in collaboration with business stakeholders. Even though we try to minimize it but SharePoint Online migration will involve some downtime and hence it is best to choose site keeping in mind the downtime. Sites not used frequently or not used can be selected before. Heavily used sites must be kept at the end or should involve different strategy.
  • Restricted Site Permissions: In case of migration without delta/incremental migration, it has to be made sure that no new lists o libraries are created by users at the source site hence the site permissions for site users are changed to contribute only so that they can only add new items to existing lists/libraries and not create new ones. If the permissions are not changed, then any new list or library created (within the time site is getting migrated) will not come over to the destination site.
  • Migration Portal: It is a good practice or a necessary step to have a central migration portal which will show the status of each site that has been migrated or is about to be migrated. This portal can be used by all the stakeholders of migration project viz. project team, customer team, business users and site owners. This portal has a dashboard which can contain various Power BI reports showing migration data in different pivots as required by the business
  • Create destination sites: Destination sites in SPO are created with the same site template as in source environment.
  • Automated site migration: Irrespective of which migration tool is chosen for migration project, the migration process can be automated to facilitate bulk migration of sites. PowerShell is used for automation here by all the migration tools. All migration tools have their own PS modules for this purpose and list of commands can be found the migration tool’s portal.

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

7. Go Live and Hyper Care

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.

  1. Site permissions are changed to read only
  2. Banner change to red (under migration)
  3. Delta content migration
  4. Business validation
  5. Mail communication to site owners
  6. Banner change to grey (final banner with destination URL)

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

  1. Business validation
  2. Mail communication to site owners
  3. Banner change to grey (final banner with destination URL)

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

Summary

Feel free to get in touch with us here or email at learning@flexmind.co for any query related to SharePoint online migration.

Sharing is Caring

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top