Planning your migration carefully is key to a successful migration project. Here are subjects that can affect your migration, and should be considered in your planning phase.

The migration checklists are PDF documents that can help you to consider every aspect of your environment for your migration.

To download The ultimate SharePoint migration checklist, click here.

To download The essential Microsoft Teams migration checklist, click here.

Though ShareGate Migrate has a simple interface, it is a complex client-side application that performs a lot of interactions with your environments through Microsoft APIs.

Because of restrictions with these APIs and the potentially different versions of SharePoint, it is important to consider the following limitations.

Look and feel relies on elements such as page layouts, master pages, and custom solutions, so we can't support it. The issue comes both from the different versions of SharePoint, but also from the fact that we cannot determine how a custom solution will affect your destination.

For more information on these and other limitations, see Look and feel or Master pages and page layouts.

Custom and third-party solutions are not fully supported by ShareGate Migrate.

Custom solutions can affect pages, list columns, content types, and many elements in an on-premises SharePoint environment.

If you are migrating to an on-premises environment, you can try installing your custom or third-party solution in your destination environment before the migration if it is available. In some cases having the custom solution available in the destination can allow the app to migrate your otherwise unsupported content.

Performing a Source analysis should reveal any custom solution in your environment (more on source analysis below).

Site collections with an active read-only lock will not migrate properly. The feature interferes with the SharePoint APIs and will cause a number of unpredictable errors. You have to disable this feature in order to migrate.

For more information on these limitations, see Read-only lock.

Performing a source analysis allows you to establish an inventory of your source environment.

This will provide you with an overview of everything you have in the source and access to a detailed list that you can export as an Excel or CSV file.

The list can reveal unsupported content and general errors and warnings that you can review before even starting your migration.

For more information, see Walkthrough - File share source analysis and Walkthrough - SharePoint and Microsoft 365 source analysis.

There are too many factors with a migration to be able to provide a proper time estimate.

Consider the following factors that can affect your migration time:

Because a SharePoint migration is not a simple file transfer, it is impossible to determine how long it will take for your migration job to finish.

The best way to get an estimate for your specific content is to run some tests. The next section of this article demonstrates how you can get an idea of how long your migration could take.

Running a test migration within your environment is the best way to establish an approximate migration time and determine what kind of challenges you might face. Doing so will help you establish a more realistic migration plan.

We suggest that you verify your migration report at the end of your test migration. The report could reveal some warnings and errors you might face during your actual migration. You should also consider increasing your migration time estimate in case you need to troubleshoot an issue during the actual migration.

To get a general idea of the time it will take to migrate multiple site collections, identify a site that is a good representation of your average site collection and migrate it.

Using the time it takes to migrate an average site collection in your environment will give you a good basis to estimate how long your multiple site collection migration will take.

To get a general idea of the migration time for your content, find a folder or library with at least one gigabyte of documents that closely represents your overall project, and migrate it. This will give you a metric to estimate how long your total amount of data can take to migrate.

For example, if one gigabyte of data took you one hour to migrate, you can roughly estimate that your content will migrate at a rate of one gigabyte per hour.

You can remove anything that is not in use in your source environment to reduce your overall migration scope and make your migration faster.

You can run the unused site report to scan your source environment (SharePoint 2010 and up), and create custom reports if you want to search for content within your sites.

Using these reports, you can archive the unused content in the source before your migration, or omit these elements in your migration plan.

It can be difficult to migrate a large site collection with many subsites. Such a migration will generate a very large migration report and make it hard to troubleshoot errors.

If you get a server failure that stops your migration, the application will not be able to resume that migration, and it will be very difficult to determine what is left to migrate in order to avoid re-migrating the whole site collection again.

To make your large site collection migration easier to manage, we recommend that you migrate your site collection without its subsites, and then migrate your subsites in small batches.

Migrate only a few subsites at a time and consider how large or complex they are when you split the migration.

To migrate the parent site collection without its subsites, you can go to copy options, and uncheck Subsites.

You can then connect to your site collection at the source and destination. In the migration window, double-click on the name of the site collection in the source and destination panels to reveal the subsites. Select a few subsites, and migrate them.

Depending on the level of customization of your environment and what is supported at the destination, you might end up with some metadata that is not supported or difficult to preserve.

When facing a metadata limitation or issue, you could save time by determining what data is important to your organization. Good communication is key to a fast and successful migration.

Here are a few key elements worth noting about metadata migration:

Users that are not available in your destination's active directory are what we call unresolved users.

ShareGate Migrate is unable to add an unresolved user to a Person or Group column when migrating to a SharePoint on-premises destination. This includes Created by and Modified by fields.

The app is able to preserve unresolved users and group values when migrating to Microsoft 365 in Insane mode only.

Insane mode has a few limitations that can cause a whole list or library to automatically get migrated with Normal mode in Microsoft 365. When the list migration gets reverted to Normal mode, the app loses the ability to preserve unresolved users.

You can create a user mapping if you wish to change the unresolved users and groups to other accounts or groups when this occurs.

For more information on how users are matched during a migration, click Users and groups association (automatic mapping).

List item IDs are only supported when you migrate to a Microsoft 365 destination with Insane Mode.

Just like with your unresolved users, the Insane mode limitations can cause a list or library to be migrated with Normal mode, and List item IDs to get replaced with new ones.

List item IDs are not supported in normal mode and in any on-premises versions of SharePoint.

For more information, see List item IDs.

Pages are partly made of references to your SharePoint environment. They are partially rebuilt by ShareGate Migrate to work in the destination.

You might lose some elements in your pages if they reference something that does not exist in the destination.

A common problem is migrating your home page depending on how your home page is set in your source. Older versions of SharePoint would establish the page in the root folder of your site.
This makes it difficult to migrate the home page alone if there is any issue.

For more information, see Home page migration (Home.aspx and default.aspx).

Not all your web parts are supported when you migrate to a modern site in Microsoft 365.

For more information, see Supported web parts for Microsoft's modern experience.

The main concern about migrations to the Modern experience in Microsoft 365 is losing the Modern experience as soon as you migrate pages that use the classic experience in a modern site.

When you migrate a classic page, SharePoint will apply the classic experience for the navigation and appearance of that page in the destination.

Infopath forms are not compatible with the Modern experience. They will get copied in the destination, but Infopath cannot be opened in a list with the Modern experience.

Your users will need to switch their lists to the Classic experience if they wish to use their Infopath forms.

Custom script is required for most migrations and the feature is only activated automatically during the migration to a modern site if you have global admin or SharePoint admin permissions.

To find how a global admin or SharePoint admin can activate the feature manually for you if you do not have these permissions, see Copying to a Microsoft 365 Site Collection requires Custom Scripts to be enabled at the destination.

If you migrate a site collection as it is in your destination, the permissions will be replicated as long as your users and security (AD) groups are available in the destination.

Your migration project is a great opportunity to assess your current permission structure and validate how you can simplify that structure.

You can validate your permissions with the Permissions matrix report.

Your migration will be simpler and your destination easier to govern if you can remove unnecessary custom permissions.

When you demote a site collection to a subsite or promote a subsite to become a site collection at the destination, your custom permissions are generally preserved, but you will find some changes to the default groups (members, owners, and visitors).

For more information on how your permissions are handled, click on the appropriate scenario below:

If your documents have a lot of versions, it can take some extra time to migrate them. Try to determine how many of the most recent versions you really need. If your organization does not perform audits on the content, your migration could go faster if you limit the number of versions per file in your copy options.

Errors could occur on previous versions of an item during the migration. If you are not required to keep your versions, the easiest solution is to limit the number of versions you keep during the migration.

Test and evaluate your PowerShell scripts carefully before you run your migrations to avoid any problems, like copying files to the wrong destination because of a script mistake or typo.

Take the appropriate time to familiarize yourself with our commands before launching a PowerShell migration.

Now that you know how to use ShareGate Migrate and what to look out for, you can start building your migration schedule.

Start with what you learned during your testing. Set an average migration time for your site collections, consider large libraries, permissions, and everything else, then determine how you wish to perform your migration.

While you are performing your migration, your users will likely use the source environment.

As you cannot lock your sites during the migration, it is essential to establish a good communication plan with your users. This is especially important if you are handling a larger migration.

Consider communicating the following with your users:

Next