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.
- Migration Checklist
- Some limitations
- Source analysis
- Why we cannot provide a migration time estimate
- Testing your migration on a representative sample of your source environment
- Unused elements of your environment
- Large site collections
- Modern experience in Microsoft 365
- Your migration Schedule
The migration checklist is a PDF document that can help you make sure you considered every aspect of your environment for your migration.
You can download the migration checklist here.
Though ShareGate Desktop has a simple interface, it is a complex client-side application that performs a lot of interactions with your environments through Microsoft APIs.
This recreates a new database at the destination and builds your destination based on the source. Since the version of SharePoint at the destination can be different, there are some limitations to consider.
Look and feel
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 the fact that we cannot determine how a custom solution will affect your destination.
For more information on look and feel limitations click here.
For more information on master pages and page layouts click here.
Custom and third party solutions are not fully supported by ShareGate Desktop.
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 performing your 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.
Note: Custom solutions are deprecated in Microsoft 365.
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 the Read-only lock limitation click here.
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.
To find more about running a source analysis on a file share, click here.
To get more information about running a source analysis on a SharePoint environment, click here.
Why we cannot provide a migration time estimate
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:
- Hardware performance.
- Microsoft 365 Throttling.
- Network security.
- Location of your workstations and servers.
- Structure complexity.
- Custom permissions.
- Metadata complexity.
- Number of versions.
- Large lists and libraries.
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.
That being said, you can run some tests as shown in the next section of this article to get an idea of how long your migration could take.
Testing your migration on a representative sample of your source environment
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.
Note: While these tests can give you a decent idea of the time it can take for your migration to complete, some elements in your environment could take considerably more or less time to migrate due to the different factors we list in the previous section of this article.
Migration of a site collection
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.
Migration of content
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.
Unused elements of your environment
You can remove anything that is not in use in your source environment to reduce your overall migration scope and make your migration faster.
Using these reports, you can archive the unused content in the source before your migration, or omit these elements in your migration plan.
Tip: You can use Download content in Explorer to download SharePoint elements to a drive or file share. The feature downloads all your files to folders representative of your SharePoint hierarchy and extracts the metadata to Excel spreadsheets. This is a great option if audits are performed in your organisation. Note that downloaded sites, lists and libraries cannot be restored to their original state in SharePoint.
Large site collections
It can be a 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 with your organization. Good communication is key to a fast and successful migration.
Here are a few key elements worth noting about metadata migration:
Users (People and groups, Created by, Modified by)
Users that are not available in your destination's active directory are what we call unresolved users.
ShareGate Desktop 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.
Note: In a migration with Insane mode to a Microsoft 365 destination all your users are considered resolved since they can be preserved. This means that your unresolved users mappings will not affect these users. You can map your users individually.
For more information on how users are matched during a migration, click here.
List item IDs
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 on List item IDs click here.
Pages are partly made of references to your SharePoint environment. They are partially rebuilt by the application 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 on your home page, click here.
Not all your web parts are supported when you migrate to a modern site in Microsoft 365.
For more information on the web parts supported for the Microsoft modern experience, click here.
Modern experience in Microsoft 365
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.
You also have to activate the custom script feature to migrate to a modern site.
ShareGate Desktop is unable to activate the feature automatically in Microsoft 365. You have to activate the feature manually with these steps.
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.
Your migration Schedule
Now that you know how to use the app 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:
- The time frame for the initial migration.
- Plans to perform an incremental migration of their content.
- Any delay that can occur during the migration.
- Your migration challenges with complex objects or hard to migrate metadata (consider asking your users if hard to migrate metadata and objects is important to them).
Note: As we mentioned, it is important that you set time in your schedule for troubleshooting. If you have an issue migrating crucial data, it can take time to find a solution. An issue can require a high level analysis and it can take more than 48 hours to get answers from our support team. Think about the complexity of your environment to set realistic migration objectives.