There are multiple factors which can affect the performance of your migration.
Sharegate works right between your migration source and your migration destination. What this means is that performance issues could be coming for either of these environments, as well as your workstation itself. It is essential to troubleshoot all possible performance issues properly.
Looking at the SharePoint environments themselves is always the first step to assessing performance issues.
- Is your SharePoint Health Analyzer flagging critical issues? If so, these must be addressed before proceeding with your migration.
- Are there any bottlenecks on your servers? This can be assessed by looking at CPU, the number of cores, memory, and queue lengths on the Disk.
- Should you be using the Server Extension? Installing the Server Extension on your WFE server can add speed and additional functionality when performing your migration. This component not needed when migrating to Office 365, which uses Azure Import.
Sharegate relies on SharePoint's Active Directory when running a migration from an on-premises environment.
- Is your Active Directory server slow? Sharegate needs to perform many calls to the directory in order to properly allocate users at the destination and assign the correct roles and permissions, so this could affect speed considerably.
The workstation you are running Sharegate on plays a large part in how your in-app options should be set to optimize Migration performance.
- Are you set to High performance? Though this may always seem best, if your server cannot handle the high volume of requests, this setting will actually slow things down. Try a few levels out to find the one that works for you.
- Are there any bottleneck on your servers? This can be assessed by looking at CPU, the number of cores, memory, and queue lengths on the Disk.
- Do you have the right number of CPU cores? Sharegate works optimally with 4 cores (64 concurrent threads).
- Are you trying to run multiple migrations at once? Even if using PowerShell, this is not a good idea. You will always achieve better performance running one migration at a time. If this is not possible, running your migrations on multiple workstations is recommended.
Network congestion can be be a source of performance woes as well.
- Do you have the upstream bandwidth to perform a migration in the time you are aiming for? This is less of an issue on-premises when using a LAN, but can be an issue when migrating to Office 365 (since the migration runs via the internet). For instance, migrating a 1 GB file on a 5/1 MBPS ADSL will take more time than running the same migration on a 1 GBPS line.
- Do you think other network issues might be at play? You can check for elevated CPU/RAM usage (if you are using a Proxy, check the Proxy network), perform a network ping test between your workstation and WFE, verify your VPN for latency, use a debugging tool such as Fiddler, or finally run Diagnostic Mode during the migration to have our Support personnel analyse (this is only recommended once other issues have been ruled out).
When running an migration using Insane Mode to Office 365, Sharegate uses Microsoft's Office 365 Import API to migrate in the fastest speed possible. However the API can have issues and bottlenecks on its end.
- Are you importing a large amount of data (over a terabyte)? You need to contact Office 365 Support ahead of time to provision your Content Database.
- Are you using a custom Azure Storage Account instead of the default? Since your Global Admin Center is located in a specific Azure data center, it is possible that your custom storage is located in a separate geographic location - prompting delays. Unless you need long-term access to you Manifest Package, it is always better to use the default Azure Storage Account.
- Did you consider encryption? Migrations to Office 365 use AES encryption to keep your data secure. This slows down the migration performance, but it is of course a highly necessary part of the process.
- Are you having bandwidth issues? You can consider creating an Azure Express Route for faster connection.
You can see Microsoft's article on migration speed as well for more information.