SharePoint Online throttling: the 429 error during a migration
Every SharePoint migration runs into throttling eventually. It is not an outage: SharePoint is protecting the tenant. The goal is to lose as little time as possible.
Short answer
SharePoint Online answers 429 (too many requests) or 503 (server busy) with a Retry-After header when a user, an application or a tenant exceeds its quota. Wait exactly that long, reduce concurrency, then climb back slowly: retrying too early extends the block.
What SharePoint returns
- 429 Too Many Requests: the request quota is exceeded.
- 503 Server Too Busy: the service is loaded; same handling.
- Retry-After: the number of seconds to wait before the next request.
Quotas apply to the user, the application and the tenant. Often overlooked: contoso.sharepoint.com, contoso-my.sharepoint.com (OneDrive) and contoso-admin.sharepoint.com share the same quota. Migrating sites and OneDrive in parallel does not double throughput.
What we measured
During a same-tenant migration on 7 October 2026, we logged 13 throttling episodes in 35 minutes, with pauses of 35 to 150 seconds requested by SharePoint. The tenant’s sites and OneDrive were throttled 0.4 seconds apart: proof of a shared quota.
The cost did not come from the pauses themselves, but from the cycle: climbing back to full speed within a minute, being throttled again a few minutes later, then another long pause.
The right response
- Honour Retry-After to the secondRetrying earlier returns another 429, counts against the quota and extends the block. Every request to the tenant stops during the pause, not just the one that was refused.
- Halve concurrency, onceRequests in flight often get their 429 together: they count as one episode.
- Do not return to the refused rateSet a temporary ceiling one step below the level that triggered throttling.
- Climb back slowlyOne more concurrent request every 30 seconds without refusal, and the ceiling relaxed one step every 10 minutes.
- Replay the same requestWithout rebuilding it, so the operation resumes exactly where it stopped.
That is what Tauri Migration does, with a single “gate” per tenant for sites, OneDrive and admin. The log shows one line per episode, for example: Throttling on contoso.sharepoint.com: 30 s pause requested by the server, concurrency 4 → 2 (back up to 3 at most).
Going faster without being throttled
| Lever | Effect |
|---|---|
| Migrate outside the tenant’s business hours | Users no longer consume the shared quota |
| Sign in with a certificate (app-only) | An application’s quota replaces a user’s |
| Lower concurrent requests to 2 or 3 | Fewer episodes, often faster overall |
| Cap migrated versions | Fewer writes in the target |
| Import new files in packages | The SharePoint Migration API writes on Microsoft’s side |
| Identify your traffic | Microsoft recommends a User-Agent like NONISV|Company|App/Version |
Frequently asked questions
Can throttling make a migration fail?
Do two migration workstations go twice as fast?
Test it on your own tenant
The 14-day trial migrates 10% of every library, with versions, metadata and permissions. After you subscribe, an incremental run migrates the rest.