Resource Based Throttling and Prioritization in Exchange Online Migrations

We often get questions about throttling in Mailbox Replication Service (MRS) based migrations in Exchange online. When migrating, you may see messages such as StalledDueTo_TargetDiskLatency for some periods of time. These messages come from our resource-based throttling infrastructure in Exchange Online. This is how this would look like in the output of Get-MoveRequestStatistics:

PS C:\> Get-MoveRequestStatistics <user> | fl Status,StatusDetail
Status : InProgress
StatusDetail : StalledDueTo_TargetDiskLatency

Or in a move report, you may see:

The job has been paused temporarily due to unfavorable server health, with request throttling state: 'StalledDueToTarget_DiskLatency'.

We throttle and prioritize work in the Exchange Online service based on priority and resource load. The highest priority is the end-user experience, so some workloads like OWA access, Outlook access, and email delivery are the highest priority. Other things, like select mailbox assistants and customer migrations, are in the second tier but with lower priority than client access and mail flow. There are also some even lower-priority workloads such as load-balancing mailbox moves, maintenance, and other discretionary tasks. We throttle lower priority workloads at the point where they could degrade the end-user experience or the performance of higher priority workloads. For instance, we throttle migrations when they might negatively impact OWA access or email delivery. Take this example: As a customer, you migrate your data to Exchange online. Imagine one day you receive a notification stating: “Your email delivery will be delayed by 1-2 hours today to allow another customer to migrate to Exchange Online more quickly.” You would not accept this scenario and we don’t either. We absolutely understand migration is important, but it is not the highest priority workload in Exchange Online. In summary, there are some things you should understand to make your migration experience go smoothly.

1. The throttling you see is not per-user or per-tenant. We throttle only based on resource load in MRS-based migrations. So, when you see a message indicating a stall, it is simply happening to preserve the overall health of the Exchange Online service. We do not have any ability to lift MRS migration throttling for a particular tenant or user. Additionally, you may get better migration throughput during off-peak hours since the resources consumed during these times will probably be lower.
2. Seeing a “StalledDueTo” or throttling message does not mean that Office 365 has a problem. You should expect some amount of throttling in any migration you perform. This throttling may occur at unpredictable or inconvenient times; you should plan your migrations accordingly. There is no action you need to take; the migration will resume automatically when resources become available.
3. Do not set very short timelines for migrations of individual user mailboxes, because you are unable to predict migration resource availability in Office 365. Instead make sure you complete the initial sync well ahead of time and complete the migrations at a later time.

Note: Some migration stalls can originate from the on-premises environment. It’s important to take note of the directionality of the stall. If the message says “Source” and you are moving mailboxes to Exchange Online, it means the stall is from the on-premises environment. Likewise, if the message says “Target” and you are moving mailboxes from Exchange Online (back to on-premises), the stall is also originating from the on-premises environment.

Brad Hughes