10 Key Steps for an Enterprise Migration Project to SharePoint Online

When transitioning SharePoint from a sizable legacy system, there can be additional complexities, especially when dealing with extensive customizations or intricate site structures. This article aims to provide a detailed exploration of these SharePoint migration challenges.

Key Steps for a Large Scale Migration to SharePoint Online

Any existing enterprise on-prem SharePoint installation will invariably have an intricate footprint in terms of its workloads, data, usage pattern and customization. While undertaking a migration project of such a dimension to SPO, there are SharePoint Migration issues that must be addressed with a responsive remediation plan. The following steps may be considered in detail for a comprehensive migration project plan. 

1. Assessment

Generate the inventory report of the source environment and analyze the data. Go through the report and assess the complexity of the environment. Create a list of sites without customization and mark them to migrate first. Create another list of sites that have customization. Understand the complexity of the customization and find appropriate solutions for the destination. Use the Power platform for the destination custom environment (for on-prem only). Try to use the Power Apps & Power Automate to convert your custom solution on the SPO. Use PowerBI Dashboard to demonstrate the source environment analysis with the complexity level and solution that you are providing to business owners. Here is a typical Power BI report.

2. Permission Migration

This is the complex part of the SharePoint migration. You might have been able to migrate the content of SharePoint sites successfully, but you might face SharePoint migration issues while migrating the user permission of the sites. As an example, some of the sites present in SharePoint On-Prem may not inherit permission from the parent site, but the groups are present from its parent site. While you migrate to the site permission you will notice the group from parent sites are not copied to the destination as those are kind of orphaned on the source. So, you need to take care of this kind of permission migration issue. During the migration map the SharePoint groups with SPO SharePoint groups explicitly and migrate the root site permissions if those permissions are inherited. Must verify the site permission after migration.

3. Page Migration & Modernization

You need to migrate the classic pages and modernize them while migrating an on-prem SharePoint Sites to SharePoint Online. You might anticipate significant SharePoint Migration issues for the heavily customized pages from the source to the destination. There is only one solution I found to make it successful. Map the site template to a blank template on the destination while migrating the classic pages using the Sharegate Tool. On successful migration, you will see the custom web parts and page layouts are missing on the destination created under the “Pages” library. This is normal as you don’t have any option to deploy any solution on SPO. Now run the modernization script from Microsoft to modernize the Classic pages to Modern pages. This script will modernize the classic pages and create new modern pages under “Site Pages” library with content from migrated Classic pages from “Pages” library in SPO. This script will not be able to create everything the same as the source as a lot of classic web parts are deprecated in Modern pages but still, it will reduce a lot of manual work and save your migration time.

4. Custom Navigation & Quick Links Migration

Most of our customers are using custom navigation built on their on-prem environment which we are not able to migrate to the destination. You need to propose a new solution here – like Mega Menu and/or Hub site association to show the menu by inhering the top-link bar.

If the left navigation is also customized showing the links from a SharePoint list using the custom solution, then there is no “out of the box” solution to migrate the left navigation. Follow the steps to migrate it – export the SharePoint list to Excel. Create a console application or PowerShell scripts to generate the Left Navigation from the Excel file.

In most cases you might have found the links on the pages are not migrated properly on SPO when you are migrating sites to site collection. It may happen if the links are hardcoded on the source as well. You need to write a PowerShell script to update the links on the destination if you find a pattern of the URL manual editing is the only option. Here is an example script.

5. Power Platform Migration

When you are doing Tenant to Tenant migration, you need to migrate the Power Apps and Power Automate from one Tenant to another Tenant. To do this, run an assessment of your Power Platform Environment from source Tenant first. This assessment will include only PowerApps and Power Automate which are using SharePoint Sites under scope of migration. You do not need to worry about the PowerApps and Power Automate which are using CRM etc. which are not in the SharePoint migration. Run PowerShell scripts to get all the PowerApps and Power Automate from the environment. Choose the appropriate Power Apps & Power Automate to migrate and create a list.

With all probability, one would use ShareGate to assist in migration. ShareGate does not have the feature to migrate the Power Apps & Power Automate. You can use the export-import method to migrate the PowerApps & Power Automate but it’s difficult if you have thousands of them. We use our home-grown application to migrate the Power Apps & Power Automate to Tenant to Tenant and that may be a topic of discussion by itself in our subsequent blogs.

6. Custom Solution Migration

If the source environment is heavily customized and the customer wants to use the custom features after migration, then we need to analyze the custom application functionality thoroughly. There is no custom solution concept in SharePoint Online. So, we need to finalize the target application architecture on SharePoint Online after understanding the requirements. We normally introduce the Power Apps as our first choice for custom application migration. However, some of the custom application development requirements cannot be served by Power Apps. In such cases we introduce SPFx or React as front-end and we use Power Automate/Logic Apps, Azure functions etc. for backend development. The aim is to really understand the requirements of such custom solutions and redevelop it in SharePoint Online picking up the right tools judiciously.

7. Workflow Migration

This is again a complex part of migration. Again, workflows are typically prone to give rise to SharePoint Migration issues due to their variety and functionality. There could be a couple of workflow types involved– Workflow 2010, Workflow 2013- or third-party workflows e.g., Nintex Workflows. So first you need to get the workflow reports of all types and analyze them. Remove the workflows that have ‘0’ running instances from the migration list. Then remove all the workflows from the migration list which has the word ‘test’ in the name.  This is a simple practical tip but will save a lot of migration efforts since you will always find dummy or inactive instances of workflows floating around.

Now you need to decide on the migration path. In SharePoint Online Migration, we are migrating all the workflows to Power Automate. So, migrate all types of workflows to Power Automate if you are migrating to ang on-prem environment to SPO. If you are migrating SharePoint from Tenant to Tenant, then also migrate the SharePoint 2013 workflows to Power Automate if those are not done yet. If you are migrating on-prem to on-prem, then it is recommended to migrate SharePoint 2010 Workflow to SharePoint 2013 Workflow.

8. Communication

Communication plays a major role in SharePoint online Migration. This is very important to notify Site Owners before making the migration. We normally send email communication to Site Owners only for migration. Communication happens in several phases of migration. We identified four major phases of migration – Pre-Migration, Full Migration, Delta Migration & Go-Live. We include the Full migration date, delta migration date, Cutover & Go-live date on email communication. We also provide the action required by site owners with Source and Target Site address on the email. We do normally use standard HTML email templates with formatting which is a good migration practice. We also use a home-grown App to send emails to large number audiences (Site Owners) when we do large migrations.

9. User Acceptance Test

User acceptance test is very important after full migration. We run it after Full Migration and before delta migration. It helps to check their data on the target environment and whether the data is correctly migrated. They better understand their data than us as they are the ones who use it most often. They might find differences in item count compared to source and destination as source is continuously updating since we do not make the source site read only after Full Migration. Users can validate the custom apps functionality after migration and be familiar with the new interfaces after migration to continue with the new site. If there are issues found during UAT they have the ability to log the issue on UAT Tracker App which is our home-grown App. At Netwoven, our UAT management is finetuned over the years to optimize on reporting, remediation, communication and timeline using home grown tools and processes.

10. SharePoint Site for Migration & Tracking

We use a Standard SharePoint Site Template with embedded Apps like Migration Mapping, Email Tracker, Migration Tracker, UAT Tracker, etc. with multiple SharePoint lists as a migration control and collaboration point. We restore the site at the customer’s end when we start the migration. We collect the reports from different sources – SMAT, ShareGate, and Power Shell and consolidate them. We Upload these excel reports to SharePoint List and finalize the list of sites for Migration. All these Apps use the same SharePoint list as a data source, and we manage the whole migration from a Single point. So, this SharePoint Site is very important to monitor and track migration as we are using/updating a single data source which reduces the creation of multiple excel files with many versions and avoids conflict of information. We do encourage using this SharePoint Site for Business users as they also can track the migration progress and status of their site with future migration schedules as well.

Conclusion:

Every migration is different, big or small. The aim of this article was to highlight various aspects of an enterprise-level migration project. All such activities will have to be tailored depending on the complexity and idiosyncrasies of a given project. Please feel free to comment or ask if you have any questions.