![\"\"](\"https:\/\/dtasiagroup.com\/wp-content\/uploads\/2023\/11\/DCT-1371-Event-graphics-booth-VNISA-Hanoi-2023-1584x396-1.jpg\")
<\/p>\n<\/p>\n
Microsoft 365 migrations can be complex. With so many vital business applications in use\u2014like Teams, OneDrive, SharePoint and Outlook along with the sheer volume of data stored on each of these\u2014there is a lot that can go wrong.<\/p>\n
I\u2019ve 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.<\/p>\n
Both of these scenarios could have been avoided.<\/p>\n
<\/p>\n
How can you configure your Microsoft 365 migration to run as fast as possible?<\/strong><\/p>\n Everyone asks how fast Microsoft 365 content can be migrated. However, what you do or don\u2019t do before and during the migration can have the greatest impact on migration speed.<\/p>\n This post will dive into nine best practices and considerations to be aware of that will help you speed up your\u00a0Microsoft 365 migration<\/a>\u00a0and avoid unnecessary complications.<\/p>\n 1.\u00a0\u00a0\u00a0 Prevent major changes in the source tenant<\/strong><\/p>\n 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.<\/p>\n We recommend that you inform your users to avoid major content restructuring changes prior to or during the migration.<\/p>\n 2.\u00a0\u00a0\u00a0 Provision 24 hours in advance<\/strong><\/p>\n 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.<\/p>\n 3.\u00a0\u00a0\u00a0 Migrate the last file version only<\/strong><\/p>\n This may not be popular for users \u2013 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.<\/p>\n Unfortunately, you don\u2019t 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\u00a0here<\/a>\u00a0for an example of a PowerShell that creates a Version History Report for SharePoint Online.<\/p>\n 4.\u00a0\u00a0\u00a0 Do not migrate permissions for OneDrive<\/strong><\/p>\n 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.<\/p>\n That\u2019s 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.<\/p>\n The best and fastest option is to leave permissions behind on the source tenant. That way your migration runs faster, and you don\u2019t have to deal with updating permissions during an incremental migration.<\/p>\n 5.\u00a0\u00a0\u00a0 No incremental migrations<\/strong><\/p>\n For even faster performance, don\u2019t run any incremental migrations after the first migration.<\/p>\n 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.<\/p>\n 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.<\/p>\n 6.\u00a0\u00a0\u00a0 Do not migrate list and library comments<\/strong><\/p>\n 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.<\/p>\n 7.\u00a0\u00a0\u00a0 Archive Teams channel messages<\/strong><\/p>\n 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\u00a0Teams migrations<\/a>\u00a0to a very slow pace.<\/p>\n 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.<\/p>\n Second, configure the migration to archive older channel messages \u2013 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.<\/p>\n