Skip to main content
All CollectionsMigrateGeneral
Migration performance
Migration performance
Updated over a month ago

Many factors can affect the performance of your migration.

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

For more information, see the Microsoft article, General migration performance guidance.

Assess your Environments

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

  • 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 migrating from an on-premises environment.

  • Is your Active Directory server slow? ShareGate Migrate needs to perform several calls to the directory 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 setting your options 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 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 correct number of CPU cores? ShareGate Migrate works optimally with 4 cores (64 concurrent threads).

  • Are you trying to run multiple migrations at once? You should run concurrent migrations from different machines with different user accounts for better results. For more information, see Concurrent migrations using ShareGate Migrate.

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.

Did this answer your question?