Fix Office 365 Migration Throttling Errors Fast

You started a migration into Office 365, the first hour ran fast, and now every batch is stalling. The log is full of HTTP 429 Too Many Requests and ErrorServerBusy responses from outlook.office365.com. Throughput has dropped from 3GB per hour per mailbox to under 200MB. This is Office 365 migration throttling — Microsoft's deliberate brake on EWS, MRS, and Graph traffic — and the fix is not "run it again". It's identifying which of three policies is firing and adjusting the migration shape accordingly.

Why Office 365 throttles your migration#

Microsoft applies three layers of throttling to every tenant. They stack — a request can be slowed by all three at once — and the migration log usually doesn't tell you which layer hit first. Knowing the difference saves hours.

Per-user EWS throttling policy#

Every mailbox has an attached throttling policy that caps EWS and EWS-impersonation traffic. The defaults allow roughly 2GB per hour of message data per mailbox, with stricter limits on findfolder and findfolderhierarchy calls. When a single account exceeds them, the EWS endpoint returns ErrorServerBusy with a back-off in milliseconds and that mailbox stalls. Other mailboxes in the same batch keep moving, which is why the symptom looks like "one account is slow."

Tenant-level connection caps#

Underneath the per-user policy, the tenant has a connection cap that's usually invisible until you push past it. For most commercial tenants it sits in the range of 20–40 concurrent migration sessions, after which new sessions are queued and pre-existing ones are slowed. If every mailbox in your batch slows down at the same moment, this is the layer that fired. Operator-side, the fix is to cut concurrency in your migration tool — not to throw more workers at the problem. Our IMAP throttling errors page covers the same logic for IMAP sources.

The hot mailbox flag#

Microsoft maintains an automated "hot mailbox" flag that gets set when a single account does sustained EWS work for more than about 30 minutes. Once set, the throttling policy on that mailbox tightens for 24 hours and you cannot turn it off. Restarting the migration does nothing. The only fix is to pause that mailbox, let the flag clear overnight, and re-add it to the batch the next day. This is the most common reason a migration that ran fine for ten mailboxes suddenly stalls on the eleventh.

If you're working a tenant-to-tenant move, the same three layers apply on both ends. The Exchange to Office 365 pair guide covers the source-side throttling that often gets overlooked, and the Office 365 migration guide walks through the full project shape.

Fixing throttling — step by step#

1. Identify which throttle is firing

   Open the migration log and search for 429 and ErrorServerBusy. If the back-off is on one mailbox only, it's per-user throttling or the hot mailbox flag. If every mailbox slows at once, it's tenant-level. The migration tool's per-mailbox throughput chart usually makes this obvious within five minutes.

2. Drop mailbox concurrency to 10 or fewer

   In your migration tool, find the simultaneous-mailbox setting and lower it to 10. Many tools default to 20 or higher, which guarantees you'll hit the tenant cap. Counterintuitively, fewer concurrent connections moves more data per hour because none of them get throttled.

3. Move large mailboxes to their own batch

   Any mailbox over 20GB should run in a batch by itself, queued after the small accounts complete. Large mailboxes are the most likely to trip the hot-mailbox flag, and isolating them means a flag on one doesn't slow the others.

4. Honour the Retry-After header

   Confirm your migration tool reads the Retry-After value on 429 responses and sleeps for at least that long. Tools that retry immediately make throttling worse by extending the back-off window. Mailbox Taxi defaults to honouring the header plus a 10 percent buffer.

5. Pause hot mailboxes for 24 hours

   If a specific mailbox has been throttled for over an hour with no improvement, remove it from the current batch. The hot-mailbox flag will clear automatically within 24 hours. Re-add the mailbox to a later batch and it should move at full speed.

6. Open a throttle-uplift ticket if you're moving more than 500 mailboxes

   For migrations above roughly 500 mailboxes, Microsoft will often grant a temporary throttling policy uplift if you ask 5–7 business days before the migration window. Open a Microsoft 365 support ticket, state the mailbox count, source platform, and target window, and ask for an EWS throttling policy uplift for the duration.

Preventing throttling on the next batch#

Throttling is a budget, not a wall. You spend it on every API call, and the budget refills slowly. Plan the migration the way you'd plan a download over a metered connection: small steady streams, not bursts. Schedule large mailboxes after small ones, not before. Migrate during off-hours where you can — not because Microsoft loosens the policy, but because background tenant load is lower and your share of the connection cap is larger.

Sanity-check your tool's defaults before the cutover. Many migration tools ship with concurrency settings tuned for a five-mailbox demo, not a 500-mailbox project. If the defaults look ambitious, halve them.

FAQ#

For the wider picture on what else can stall an in-flight job, the email migration troubleshooting hub is the index.