Merging and splitting Office 365 data from tenant to tenant is becoming more and more common recently as the platform grows and more organizations are stepping down on-premise systems in favor of leveraging cloud services for mail and collaboration.

A cornerstone of Microsoft’s cloud offering is Exchange Online, which has been active now for more than a decade, since the BPOS days. It stands to reason that in that time organizational structures change, divestitures and acquisitions happen, and data needs to move to support these changes.

Microsoft’s Exchange Hybrid Configuration does a fantastic job of facilitating the move from on-premise Exchange systems to Exchange Online but when we look at large complex organizations, a simple Exchange on-premise to Exchange Online migration is becoming rare.

When you consider non-Exchange source systems such as Lotus Domino or G-Suite, and existing Exchange Online tenancies. The migration path becomes more complex.

There are Native Microsoft migration paths for G-Suite and IMAP migrations (I’m even a big fan of the PST and File Ingestion Service which leverages Azure storage) but depending on the scope and cadence of the migration, they often aren’t as robust as some of the third party offerings such as MigrationWiz or CloudM Migrate.

These tools add a variety of extra possibilities for synchronization of mail/contacts/calendars as well as Microsoft Teams, SharePoint Online, OneDrive with some great quality of life features such as permissions mapping, scheduling and filtering capabilities.

When it comes to Exchange Online Migrations, the preferred method by most of the tools is using Exchange Web Services (EWS) and user impersonation to migrate mailbox items. The EWS API (which is currently being edged out by the Graph API), has been a mainstay of Exchange Server since Microsoft Exchange 2007 is highly flexible and extremely powerful tool to accomplish those “non-standard” tasks in Microsoft Exchange (I once had to de-duplicate about 1TB of mail in a Shared Mailbox after a bad migration attempt).

While EWS is extremely powerful, it’s important to consider the load large scale actions take on the back-end infrastructure. To protect Exchange servers from overload, EWS is controlled via throttling policies. For Exchange on-premise if a large scale migration or other action is planned, these policies can be altered for specific service accounts to bypass what would be considered acceptable per-user usage.

In Exchange Online however, we don’t own the servers and Microsoft needs to protect it’s cloud services so we do not have access to the throttling policies directly. Previously, if a migration was planned, a call to Microsoft Support was required to bypass throttling for a period of time to ensure the throughput needed for migration.

This process has become a lot smoother these days using the built in support tools. To temporarily increase the limits on a throttling policy, we just need to open the support tab in the Office 365 Portal, search for EWS Throttling and run the diagnostic tool. If throttling is affecting the migration, we will get a prompt to bypass for 30, 60 or 90 days.

Once done, the change should take affect withing 15 minutes and we can migrate without these errors!