Home > SharePoint Online to SharePoint Online Migration Process
Download this articleThe sections below contain the general migration process for SharePoint Online Migration with different domains in the source and destination. The details outlined in this document can also serve as general guidelines for any projects to perform SharePoint Online migrations using Fly.
More steps may be needed and some steps included in the process may be optional according to your migration requirements.
Before the migration, you need to identify what object types you want to migrate. Refer to the Supported and Unsupported List.
To connect Fly to your SharePoint Online, create a service account or an app profile with required permissions in AvePoint Online Services. Refer to the latest Required Permissions to check the required permissions for SharePoint Online Migration.
Users with Multi-Factor Authentication (MFA) enabled cannot be used as the service account to perform migrations. You can use a delegated app profile instead.
If there are many site collections in your tenant and you only want to migrate some of them, you need to prepare a custom app profile with different set of permissions and apply the app to the desired site collections. Refer to Permissions for Source SharePoint Online for details.
Before you migrate from SharePoint Online, you can run a tenant discovery for SharePoint Online to scan and report the object count, object type, object size, and other details. According to the discovery reports, you can better understand your source environment and plan for your migrations. Refer to the user guide for Tenant Discovery for details.
To migrate managed metadata columns with terms, the source and destination service accounts/consent users of delegated profiles must be added to Term Store Administrators before the migration.
Go to the Term store page in SharePoint admin center and add the migration service account to the Admins.

URL of the Term Store management: https://{TenantName}-admin.sharepoint.com/_layouts/15/online/AdminHome.aspx#/termStoreAdminCenter.
Fly does not automatically create new users in Microsoft 365. There are different ways to add new Microsoft 365 users:
Adding users individually. See instructions here.
Adding users in bulk. See instructions here.
Adding users via PowerShell. See instructions here.
Synchronizing users from local Active Directory to Microsoft 365 via Microsoft Entra Sync or Microsoft Entra connect. See instructions here.
You can export the external users and import them into the destination tenant before the migration by downloading and running the PowerShell scripts.
If retention policies are configured for the source data, check to make sure the destination retention policies are the same as the source retention policies. Otherwise, the destination data may be deleted due to different retention policies.
If the source tenant does not have sensitivity labels, you can ignore this step.
If the source tenant has sensitivity labels, and you want to replace the source labels with destination ones, make sure the destination labels already exist before the migration.
Refer to Create and publish sensitivity labels to create and publish Labels.
For SharePoint Online migrations, generally, a reasonable migration speed is 2 GB/hour/mapping. For the number of mappings that can be run, it is automatically allocated based on the subscription you purchased. The more user seats you purchase, the more mappings you can run in a project.
However, SharePoint Online consists of files and various items/metadata/settings. The data rate may not be the only factor to reflect the migration performance. For example, the site features/content types/other metadata/settings and list items usually take up a small size, but the larger overhead and processing time caused by migration, even the regions of migration, will impact the data rate. Pilot Migration is recommended as the best practice for you to test the actual migration performance. The actual migration performance may vary based on the data complexity.
Refer to Create a Connection to connect to your source and destination SharePoint Online. The connection including both the app profile and service account is recommended.
A SharePoint migration policy allows you to configure the conflict resolution, filter policy, user mapping, column mapping, content type mapping, template mapping, URL mapping and other options for SharePoint Online Migration. Refer to Configure a Migration Policy for details.
To ensure the maximum preservation of source data, we recommend you use Merge as the container level conflict resolution and use Overwrite by last modified time as the content level conflict resolution.
If the file/item has more than 100 versions, it will take more time to migrate the data. Therefore, we recommend that you use the version filter policy to migrate no more than 100 versions. Refer to Filter Policies for details.
To migrate a hub site in the source, you can configure a project mapping to map the hub site to a modern site collection. After the site collection has been migrated, you can register the destination site collection as a hub site in SharePoint admin center. Then, manually associate desired site collections with the hub site.

To migrate a content type hub site in the source, you can configure a project mapping to map the source content type hub site to an existing destination content type hub site. Then, only select the Site and list content types and Site and list columns checkboxes in the migration policy and use the policy to migrate the content type hub site. After the migration, you can manually publish the desired content types in the destination content type hub site.
We recommend that you do a pilot run for the following purposes:
Get familiar with Fly interface and understand the whole migration process.
Discover any potential issues early and resolve them before production migration.
Understand the throttling situation in case content size is large, and then try to resolve it with the destination.
A pilot migration should be as close to the wave migration as possible and involve all steps that any wave will involve.
Refer to Run Migrations to Migrate Objects for details.
Based on your source tenant discovery report, you need to prepare a final mapping file to list the mappings of source data and destination location. As you may have a heavy load of content to migrate, we recommend you separate your mappings into multiple waves according to your departments for easy management. Keep communicating with users about the migration status.
To configure projects and mappings, refer to Create a Project and Create Migration Mappings for details.
If there are too many subsites and lists in your site collection, the migration job may fail. When the number of subsites and lists in your site collection exceeds 1000, we recommend that you split sites in the site collection. Fly provides a script for you to automatically split the sites. Refer to the following steps for details:
Click here and find the SplitMappings.ps1 script.
Download the SplitMappings.ps1 script to the machine where you want to execute the script.
Open the SplitMappings.ps1 file, and configure the source and destination site collection URLs, and the directory where you want to store the Mapping.csv file generated after running the script. In the Mapping.csv file, URLs of source site collection and sites will be listed in the Source URL column, and their corresponding destination URLs will be listed in the Destination URL column based on the configured destination URL. The source site collection and sites will be migrated based on the file.
$SrcSiteUrl = " "
$DestSiteUrl = " "
$OutputFilePath = "C:***\Mapping.csv"

Save the SplitMappings.ps1 file.
Run the script with PnP PowerShell as administrator. After running the script, the Mapping.csv file will be generated and stored in the configured directory.
Import mappings in bulk to your project by importing the Mapping.csv file.
Deselect the Subsites checkbox in the migration policy. Then, you can refer to Run Migrations to Migrate Objects to run the migration job.

If there are too many subfolders in a folder, the migration job may fail. When the number of subfolders in the folder exceeds 500, we recommend you split subfolders in the folder. Fly provides a script for you to automatically split the subfolders. Refer to the following steps for details:
Click here and find the SplitMappingForFolder.ps1 script.
Download the SplitMappingForFolder.ps1 script to the machine where you want to execute the script.
Open the SplitMappingForFolder.ps1 file, and configure the source and destination tenant domain and site collection URLs, the directory where you want to store the Mapping.csv file generated after running the script, and the relative URL of the folder/list you want to split. In the Mapping.csv file, URLs of source subfolders will be listed in the Source URL column, and their corresponding destination URLs will be listed in the Destination URL column. The source subfolders will be migrated based on the file.
$SourceTenantDomain = " "
$DestinationTenantDomain = " "
$SrcSiteUrl = " "
$DestSiteUrl = " "
$OutputFilePath = "C:***\Mapping.csv"
$FolderServerRelativeUrl=" "

Save the SplitMappingForFolder.ps1 file.
Run the script with PnP PowerShell as administrator. After running the script, the Mapping.csv file will be generated and stored in the configured directory.
Import mappings in bulk to your project by importing the Mapping.csv file.
Configure a new project for the parent folder of the split subfolders. Then, configure a folder level filter policy to filter out the subfolders in the folder. Make sure the folder name you configured does not exist in the parent folder. Then, you can refer to Run Migrations to Migrate Objects to run the migration job.

Before running the job, we recommend that you verify the mappings to ensure that the mappings are available for migration. Refer to Pre-analyze Mappings for details.
Then you can run a full migration job to migrate the objects based on your configured migration policy. Refer to Run Migrations to Migrate Objects for details.
Handle new, updated, and failed data. Refer to Run Migrations to Migrate Objects about how to perform regular incremental migrations.
After the migration, you can compare the number and size of files in the source and destination by accessing the following URL:
sitecollectionurl/_layouts/15/storman.aspx
If the number of files is different after the migration, check if the files that are not in the destination are failed in the migration. If the files fail to be migrated, check the comments of failed files. After you fix the errors, rerun the migration job. If there are no records for these files, contact Support and provide the screenshots of these files and job ID to analyze the error.
If the size of files is different after the migration, for example, the source file size is 10 MB, but the migrated file size is 100 MB, check the actual size of the source and migrated files in the source and destination libraries. Then, refer to the following instructions to resolve this issue:
If the actual size of the source file is 10 MB, the actual size of the migrated file is 10 MB, but the migrated file size displayed in the destination Storage Metrics page is 100 MB, it may be an issue of Microsoft.
If the actual size of the source file is 100 MB, the actual size of the migrated file is 100 MB, but the source file size displayed in the Storage Metrics page is 10 MB, it may be an issue of Microsoft.
If the actual size of the source file is 10 MB but the actual size of the migrated file is 100 MB, it is an issue of Fly. Contact Support and provide the screenshots of version histories of the source and migrated files, and screenshots of the Storage Metrics pages of the source and destination by accessing the following URL to analyze the error:
sitecollectionurl/_layouts/15/storman.aspx
Check the mapping report. If the mapping fails or finishes with exceptions, you can check the error code and comment for the mapping in the Migration error section. You can click the error code to view the details and recommendations of the code in the Troubleshooting Guide, which can assist you in resolving or avoiding the error.
Check the item count and permissions in the destination. If permissions are failed to be migrated, you can run a Migrate permissions only migration job.
Check site/list settings in the destination.
Check pages and webparts in the destination.
Check workflows in the destination.
Check navigations in the destination.
New data can be created in destination.
Before executing the final delta/incremental migration, make sure that no data will be changed or created in the source during the migration to enforce the data consistency.
To set a site collection as read only, run the following script using PowerShell:
To unlock a site collection, run the following script using PowerShell:
At the end of the migration project, we recommend you run a final incremental job to ensure all source data are migrated to the destination.
This step is only needed if you have separated the migration plans into multiple waves.
After the domain name of your source tenant is changed to your destination tenant for go-live, if you want to perform a final incremental migration to migrate the new or modified data to the destination, you must change the host names of the source and destination site collection URLs in Fly first. Refer to User Guide for details.