Migrating 200GB+ mailboxes without hitting Google and Microsoft throttling

What you described is the classic failure mode, and it is worth being precise about what went wrong: the tool treated a *throttling response* as a *permanent failure*. Those are completely different things and conflating them silently loses mail.

When Google or Microsoft returns a 429, they are saying 'slow down and try again' — not 'this message cannot be transferred.' A migration that marks the item FAILED and moves on has just dropped mail, and it will report the run as complete with a handful of errors. On a 200GB mailbox under sustained load, you hit that state constantly, which is why you saw thousands of failures.

Correct handling looks like this:

• Honor Retry-After first. When the provider tells you exactly how long to wait, that number beats any heuristic. Ignoring it gets you throttled harder.
• Exponential backoff with jitter after that. Retry at increasing intervals rather than hammering immediately. Jitter matters when several mailboxes are running in parallel — without it, every worker retries in lockstep and you recreate the same spike that caused the throttle.
• Distinguish transient from permanent. A 429 or a socket hang-up is transient and must be retried. A permission error is permanent and should fail fast rather than burn your retry budget for twenty minutes.
• Reconcile at the end. After the main pass, sweep for any item not in a terminal success state and reprocess it directly by its stored ID. This is the safety net that catches anything the folder walk missed.

Be careful about promising a number, because throughput on very large mailboxes is governed by the provider's throttling, not by your bandwidth or ours. Two 200GB mailboxes can differ by a factor of three.

The dominant variable is message count, not raw size. A 200GB mailbox made of 40,000 large attachments moves considerably faster than a 200GB mailbox made of 900,000 small messages, because most of the cost is per-item API overhead rather than bytes on the wire.

The planning advice I would give leadership: schedule large mailboxes to start first, several days ahead of everyone else, and run them concurrently with the general population rather than in sequence. Then the executives' mailboxes are not on the critical path, and the timeline you commit to is the one for the other 95% of users — which is far more predictable. Quote the cutover date, not the transfer duration.