Exchange Online Service Limits for Migration

If you've ever watched a migration job slow to a crawl for no obvious reason, there's a good chance Exchange Online's service limits were the reason — not a bug in your migration tool. Microsoft puts a fairly tight set of boundaries around how much data can move in and out of a tenant at once, how large a mailbox or message can be, and how many items can sit in a single folder. These aren't bugs to work around; they're guardrails that keep Exchange Online stable for every tenant sharing the same infrastructure. EdbMails Office 365 Migration is built with these limits in mind from the start, pacing data transfer, retrying intelligently when Microsoft applies temporary throttling, and giving administrators visibility into exactly where a job stands instead of leaving them to guess. This page walks through the service limits that matter most during a migration, what happens when you hit them, and how different migration approaches deal with them.

Why Exchange Online Limits Matter During Migration

ADay-to-day email use rarely bumps into these limits. Sending a few dozen messages an hour, storing a few gigabytes of mail — none of that comes close to the ceiling. Migration is different. You're potentially pushing years of accumulated mail, calendar items, contacts, and attachments into a tenant in a matter of hours or days, and that's exactly the kind of sustained, high-volume activity Microsoft's throttling mechanisms are designed to catch and slow down.

Ignore these limits while planning a migration and you'll likely see one of the following: jobs that stall partway through, connections that drop and have to reconnect, or a migration that technically completes but takes far longer than it should have.

The Exchange Online Limits That Actually Affect Migrations

Mailbox Storage Limits

How much a single mailbox can hold depends on the license attached to it. Exchange Online Plan 1 caps primary and archive mailboxes at 50 GB each. Plan 2 bumps the primary mailbox up to 100 GB, with a 1.5 TB auto-expanding archive on top of that. If a source mailbox is larger than what the assigned target license allows, the migration will hit a wall regardless of which tool is doing the work — this is a licensing decision, not a tool limitation, and it needs to be sorted out before migration day.

Archive Mailbox Auto-Expansion Speed

This one catches people out more than almost anything else. When an archive mailbox's Recoverable Items folder fills up, Microsoft does add more space automatically — but only at roughly 1 GB per day. If your plan involves migrating, say, 50 GB of old mail straight into someone's archive, that data simply can't land that fast. The migration may appear to fail or just quietly stop progressing, when really it's waiting on storage that hasn't been provisioned yet.

Message Size Limits

The default message size ceiling in Exchange Online — body plus attachments — is 35 MB, though admins can raise it up to 150 MB with manual configuration. Keep in mind that attachments get Base64-encoded in transit, which inflates their size by roughly a third. So even with the limit raised to 150 MB, the largest attachment you can realistically push through is closer to 112 MB. Classic attachments cap out at 112 MB; attachments stored via OneDrive can go up to 2 GB.

Items Per Folder

Exchange Online allows up to a million items in a single folder, but Microsoft is upfront that anything beyond 100,000 items in one folder starts to cause performance problems — for the user, and potentially for whatever's trying to read or write to that folder, including a migration job. Mailboxes with enormous, unfiled inboxes (a common sight in older Exchange environments) are worth flagging before migration, not after.

EWS Throttling

A large share of mailbox migrations — whether native, hybrid, or third-party — rely on Exchange Web Services (EWS) to read and write mailbox data. EWS has its own throttling policy, and once a connection or account exceeds it, Microsoft starts delaying or rejecting further requests. In a migration log, this usually shows up as a "request is throttled" message with a suggested backoff time, or repeated "trying command when not connected" errors after the connection has already been cut.

Microsoft does offer a temporary EWS throttling relief option through the Microsoft 365 Admin Center's diagnostic tools, which can relax the policy for a set number of days — but changes take up to half an hour to apply, and it's a manual step that's easy to forget until a migration has already stalled.

Mailbox Move Concurrency

Trying to move too many mailboxes at the same time is one of the most common — and most avoidable — causes of throttling during a migration. Microsoft's own guidance points to roughly 24 concurrent batch migrations as a reasonable ceiling; push well past that, particularly with 500 or more mailboxes queued at once, and you're likely to see slowdowns or outright failures rather than a faster overall migration.

Recipient and Message Rate Limits

These matter less for the migration itself and more for what happens right after cutover. Exchange Online currently allows up to 10,000 recipients per user per day and around 30 messages per minute, with a default cap of 500 recipients per message. Microsoft also walked back a planned "external recipient rate limit" change in early 2026 after pushback from customers — worth knowing if you'd read about it and assumed it was already in effect. None of this blocks a migration directly, but it's relevant if your post-migration plan includes any kind of bulk internal communication to newly migrated users.

How Different Migration Approaches Handle These Limits

Approach	How It Handles Throttling	Typical Trade-off
Native cutover/staged migration (Exchange Admin Center)	Relies on Microsoft's default EWS throttling policy; admin can request temporary relief manually.	Works fine for smaller batches; large environments often need manual throttling-policy intervention mid-project.
Hybrid Configuration Wizard-based moves	Subject to the same EWS and mailbox-move concurrency limits, managed through Exchange Management Shell move requests.	Gives granular control over move batches, but requires PowerShell familiarity to tune concurrency properly.
General-purpose third-party migration tools	Many apply their own internal throttling or retry logic on top of Microsoft's limits, with varying degrees of transparency.	Some tools surface throttling clearly in logs; others fail silently and leave admins guessing why a job stalled.
Tools with adaptive pacing and incremental sync	Automatically adjusts transfer speed based on throttling responses, and resumes from where it left off rather than restarting.	Lower manual effort, though very large environments still benefit from batch planning around the ~24 concurrent move guidance.

The common thread across all of these: nobody gets to bypass Microsoft's limits outright. What changes is how much of the throttling-related troubleshooting falls on the administrator versus how much the migration tool absorbs automatically.

How EdbMails Works Within These Limits

EdbMails Office 365 Migration doesn't try to push past Exchange Online's service limits — that's not really possible from outside Microsoft's infrastructure — but it's engineered to work smoothly within them:

• Adaptive throttling handling — when Microsoft signals a backoff, EdbMails retries automatically rather than dropping the connection and forcing a manual restart.
• Batch-wise migration so you control how many mailboxes run concurrently, instead of unintentionally overloading the tenant and triggering avoidable throttling.
• Incremental/delta migration, meaning a mailbox that gets interrupted partway through — whether by throttling, a network blip, or anything else — picks up from where it left off on the next pass rather than starting over.
• Pre-migration discovery and reporting, which flags oversized mailboxes, unusually large folders, or other items likely to run into a size or item-count limit, so you can plan around them before the job starts rather than during it.
• Detailed migration logs, so when something does get throttled, it's easy to see exactly which mailbox, which limit, and roughly how long the delay will last — rather than digging through generic error codes.

Planning Around Exchange Online Limits: Practical Tips

• Check source mailbox sizes against target license limits before migration day, not after a batch fails
• If you're moving large archives, plan for the 1 GB/day archive expansion rate and stagger accordingly — don't assume archive storage will just appear on demand
• Keep concurrent mailbox moves around the ~24-batch range Microsoft recommends, especially for environments with 500+ mailboxes
• Identify any mailboxes with bloated, unfiled folders ahead of time; cleaning these up before migration is often faster than working around the limit during it
• If you anticipate needing temporary EWS throttling relief, request it from the Microsoft 365 Admin Center diagnostics tool early — it can take up to 30 minutes to apply
• Build buffer time into your migration schedule for throttling-related delays; treating Microsoft's limits as a planning input, rather than an exception, saves a lot of last-minute scrambling

Frequently Asked Questions

1. What happens if I exceed Exchange Online's throttling limits during migration?

   Microsoft slows or temporarily rejects further requests from the account or connection involved. In migration logs, this typically shows up as a throttling message with a suggested backoff time, or repeated connection failures until the load drops.

2. Can I increase Exchange Online's mailbox size limit for migration?

   Mailbox storage limits are tied to license type (Plan 1 vs Plan 2, for example) and aren't something a migration tool can override. If a source mailbox exceeds the target license's storage allowance, the license needs to be addressed before migration, not worked around during it.

3. Does EdbMails bypass Microsoft's throttling limits?

   No tool can bypass Microsoft's service-side throttling — it's enforced by Microsoft's infrastructure, not the migration client. EdbMails is designed to work efficiently within those limits, automatically retrying and resuming rather than failing outright when throttling occurs.

4. How many mailboxes can I migrate at once without triggering throttling?

   Microsoft's general guidance points to roughly 24 concurrent batch migrations as a safe ceiling. Going well beyond that, especially with very large mailbox counts, increases the chance of hitting throttling and slowing the overall project down rather than speeding it up.

---

Additional resources:

• EdbMails Office 365 Migration Tool
• Coexistence During Office 365 Migration
• Resolve Office 365 Mailbox Mapping Errors