Microsoft 365 migrations can be complex. With so many vital business applications in use—like Teams, OneDrive, SharePoint and Outlook along with the sheer volume of data stored on each of these—there is a lot that can go wrong.

I’ve had several discussions recently with customers whose entire migrations came to a screeching halt because they were migrating 500 versions of the same file or a Teams channel with over 100,000 messages.

Both of these scenarios could have been avoided.


How can you configure your Microsoft 365 migration to run as fast as possible?

Everyone asks how fast Microsoft 365 content can be migrated. However, what you do or don’t do before and during the migration can have the greatest impact on migration speed.

This post will dive into nine best practices and considerations to be aware of that will help you speed up your Microsoft 365 migration and avoid unnecessary complications.

1.    Prevent major changes in the source tenant

Once you start your migration, consider preventing (or discouraging) users from making any changes in the source tenant. Changes or additions in SharePoint sites, OneDrive sites and Teams channels often require provisioning to be run again, which can add significant time for shared and private channels.

We recommend that you inform your users to avoid major content restructuring changes prior to or during the migration.

2.    Provision 24 hours in advance

Provisioning can be a long-running process for each workload. We recommend starting provisioning at least 24 hours in advance of any migration. Ideally, you only want to provision once and never again.

3.    Migrate the last file version only

This may not be popular for users – especially when there are legal or regulatory requirements to migrate everything as is. But how critical is it to have all 500+ versions of the same file? If you want the fastest speed, consider migrating only the last version and leaving the remainder behind.

Unfortunately, you don’t know how many versions there are for each file. The version information is not stored or visible in the SharePoint or OneDrive user interface. You can run a script; but it could take days, weeks, or months to run in your tenant. Click here for an example of a PowerShell that creates a Version History Report for SharePoint Online.

4.    Do not migrate permissions for OneDrive

Like versions, permissions take additional processing time. Even the migration API documentation warns that migrating permissions will take longer. The file permissions are not stored with the file itself. Instead, they must be added after the file is processed by the migration API.

That’s bad enough; but it gets worse. If you run an incremental migration, you may want to check for changes in file permissions since the initial migration was run. However, changes in file permissions do not change the modified date property of the file. Thus, the migration process may have to compare every file that was previously migrated to ensure that any changes in permissions are updated on the target. This comparison must use CSOM calls on both the source and target tenants. The number of CSOM calls that can be sent to tenants is limited (and can be heavily throttled). The throttling will slow down all other migration processing.

The best and fastest option is to leave permissions behind on the source tenant. That way your migration runs faster, and you don’t have to deal with updating permissions during an incremental migration.

5.    No incremental migrations

For even faster performance, don’t run any incremental migrations after the first migration.

Of course, this would mean that content that was created after the first migration is not migrated, which could lead to unhappy users contacting the migration team. But you would save valuable time.

Alternatively, you can limit which sites, lists and libraries will have an incremental migration run. You may have to set priorities to determine these. For example, an incremental migration may also include remigrating failed items from an earlier migration. If you see a lot of failures in a migration, you should run an incremental migration.

6.    Do not migrate list and library comments

These comments take considerably more time to process and migrate from source to target. Leaving them behind may disappoint users, but it will save migration time.

7.    Archive Teams channel messages

Channel conversation messages are a major component of collaboration in Microsoft Teams. Unfortunately, some Teams channels contain tens of thousands of messages that may take several hours to migrate. This can reduce Teams migrations to a very slow pace.

One option is to migrate the SharePoint content ahead of the Teams channel conversations. You can choose to migrate only SharePoint content that is directly a part of channel messages. Alternatively, you can migrate all SharePoint content that includes subsites, lists and libraries underneath the Teams site.

Second, configure the migration to archive older channel messages – perhaps older than 30 days. The reading process will still take time to complete. However, the writing process will go slightly faster, as older messages are written to an archive (HTML) file. This may be critical if you already have users actively creating messages in the target tenant.

8.    Limit the migration of private chat messages

I have written blog posts previously on different ways to count how many private chat messages exist. It is very difficult to calculate how long the private chat migration will run. Thus, you should first prioritize who should have their private chat messages migrated.

Second, limit the private chat message migration to Live Chat in the target tenant to 15 or 30 days. That should be enough for users to quickly look back at the messages exchanged in a private chat thread.

Third, for key users, you can archive the remaining chat messages to an archive (HTML) file. You can also limit how many days of private chat messages are archived beyond the days that are migrated.

For everyone else, consider not migrating their chat messages or set a limit to the last 15 or 30 days.

You may be able to use the Export API for reading the structure of private chat messages much faster. Unfortunately, the Export API is expensive to use. You still need to use the Graph API for reading and writing messages. The total process is faster with the Export API if you merge messages on the target or if you archive messages to HTML files.

In the case of legal or regulatory requirements, you may need to archive all private chat messages for some key users.

9.    Exclude some OneDrive files

Ask users to aggressively clean up the files in their OneDrive. Delete any files that are very old, no longer have business value or are not required for legal or regulatory reasons. The goal is to reduce how much is migrated. Other than reducing the total quantity and size of files migrated, the biggest performance gains are achieved when migrating the latest version only (and excluding file-level permissions).

Consider excluding files that have not been modified in the past five years (for example). And consider excluding files that are over 1000 MB (1GB) in size. Large files will migrate faster than many small files. However, large files still take a considerable amount of time to migrate, and it gets worse if there is any migration error.



There are several recommendations that you can implement to achieve the fastest Microsoft 365 migration possible. You may not be able to implement all of them, but you should consider each one and if they could be an option for your organization.

  1. Prevent major changes in the source tenant after the migration starts
  2. Provision 24 hours in advance
  3. Migrate only the last version of files
  4. Do not migrate permissions for OneDrive
  5. No incremental migration
  6. Do not migrate list and library comments
  7. Archive Teams channel conversation messages
  8. Limit the migration of private chat messages
  9. OneDrive: Exclude files bigger than 1,000 MB

We recommend that you work with your users to set their expectations and get their cooperation. The result will be a much faster and smoother migration.



About DT Asia

DT Asia began in 2007 with a clear mission to build the market entry for various pioneering IT security solutions from the US, Europe and Israel.

Today, DT Asia is a regional, value-added distributor of cybersecurity solutions providing cutting-edge technologies to key government organisations and top private sector clients including global banks and Fortune 500 companies. We have offices and partners around the Asia Pacific to better understand the markets and deliver localised solutions.