Migration performance

There are many factors that can affect the performance of your migration.

ShareGate Migrate works between your migration source and your migration destination. What this means is that performance issues can come from either of these environments or even your workstation itself. It is essential to troubleshoot all possible performance issues properly.

See the Microsoft article, General migration performance guidance for more information.

Index

• Assess your Environments
• Check the Active Directory
• Your workstation
• Possible Network Issues
• Running Insane Mode to Microsoft 365

Assess your Environments

The first step to assessing performance issues is to look at the SharePoint environments themselves.

• Is your SharePoint Health Analyzer flagging critical issues? If so, these must be addressed before proceeding with your migration.
• Do you have a lot of documents in the destination recycle bins? Having a lot of documents in your Microsoft 365 recycle bins can affect performance.
• Are there any bottlenecks on your servers? This can be assessed by looking at the 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 web front-end servers can add speed and functionality when you run your migration. 

Check the Active Directory

ShareGate Migrate relies on SharePoint's Active Directory when running a migration from an on-premises environment.

• Is your Active Directory server slow? ShareGate Migrate needs to perform several calls to the directory in order to properly allocate users at the destination and assign the correct roles and permissions, which can affect speed considerably.

Your workstation

The workstation you are running ShareGate Migrate on plays a large part in how your settings should be set to optimize Migration performance.

• Are you set to High performance? Though it might seem like the better option, 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 bottlenecks on your servers? This can be assessed by looking at the CPU, the number of cores, memory, and queue lengths on the Disk.
• Do you have the right number of CPU cores? ShareGate Migrate works optimally with 4 cores (64 concurrent threads).
• Are you trying to run multiple migrations at once? Even if using PowerShell, this is not always a good idea. You will achieve better performance running one migration at a time in a lot of cases. If this is not possible, running your migrations on multiple workstations is recommended.

Possible network issues

Network congestion can be a source of performance problems.

• 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 Microsoft 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 analyze (this is only recommended once other issues have been ruled out).

Running Insane mode to Microsoft 365

When running a migration to Microsoft 365 using Insane mode, ShareGate Migrate uses the Microsoft 365 Import API to migrate at the fastest speed possible. However, the API can have issues and bottlenecks on its end.

• Are you importing a large amount of data (over 100 terabytes)? You need to contact Microsoft 365 Support ahead of time to provision your Content Database. For more information, see Microsoft's article on large migrations.
• 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 your Manifest Package, it is always better to use the default Azure Storage Account.
• Did you consider encryption? Migrations to Microsoft 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 a faster connection.