Exchange Online Migration: The Throttling Problem Nobody Talks About

What Throttling Is (and Why Nobody Warns You About It)

Every Exchange Online migration involves throttling. Microsoft throttles migration traffic at multiple levels — per mailbox, per batch, per tenant — and the limits are not fixed. They vary based on your tenant's health score, the overall load on the migration service, and factors that are not publicly documented.

The symptom is predictable: a migration that your tool estimates will take 3 weeks takes 3 months. Batches stall with TooManyBadItemsPermanentException errors. The MigrationJobState alternates between Running and Syncing without making progress.

Nobody warns you about this because it only becomes visible at scale. If you have migrated 200 mailboxes, you have not seen throttling. If you have migrated 200,000, you have spent significant time fighting it.

After 800,000+ mailboxes across multiple enterprises, here is what actually matters.

MRS Proxy Limits

The Mailbox Replication Service (MRS) is the engine behind Exchange Online migrations. MRS Proxy is the on-premises component. The default configuration limits concurrent migration connections, and those defaults are rarely appropriate for enterprise-scale migrations.

On-premises MRS Proxy defaults:

• MaxMRSConnections: 100 (this is the ceiling, not the operating limit)
• MRSProxyEnabled: False on most environments — this must be enabled explicitly

# Enable MRS Proxy on all CAS servers
Get-ExchangeServer | Where-Object { $_.IsClientAccessServer } | ForEach-Object {
    Set-WebServicesVirtualDirectory -Identity "$($_.Name)\EWS (Default Web Site)" `
        -MRSProxyEnabled $true
}

# Verify
Get-WebServicesVirtualDirectory | Select-Object Server, MRSProxyEnabled

The Exchange Online migration service has its own internal throttling on top of MRS Proxy. This is where the unpredictable limits live. The migration service evaluates tenant health and adjusts concurrency accordingly. You cannot directly control these limits, but you can work with them.

How to Calculate Migration Batches

Batch sizing is the most important variable you control. The goal is not to maximise throughput — it is to maximise predictability.

Batch sizing principles:

1. Never exceed 50 mailboxes per batch for production cutover. Larger batches are harder to monitor, harder to rollback, and more likely to hit per-batch throttling.

2. Separate large mailboxes (> 5GB) into dedicated batches. Large mailboxes consume disproportionate migration bandwidth. Mixed batches result in small mailboxes waiting for large ones to complete.

3. Pre-stage for a minimum of 5 days before cutover. On cutover day, only the delta (mail received since pre-staging started) needs to sync. This reduces the cutover window from hours to minutes.

4. Migrate by department, not alphabetically. Alphabetical batching guarantees you will split teams across different cutover weekends. Department-based batching means entire teams move at once, reducing the hybrid co-existence period.

Batch size calculator:

# Get mailbox size distribution to inform batch planning
Get-Mailbox -ResultSize Unlimited | Get-MailboxStatistics |
    Select-Object DisplayName,
        @{N="TotalGB"; E={ [math]::Round($_.TotalItemSize.Value.ToGB(), 2) }},
        ItemCount |
    Sort-Object TotalGB -Descending |
    Export-Csv -Path ".\mailbox-inventory.csv" -NoTypeInformation

# Classify by size tier
Import-Csv ".\mailbox-inventory.csv" | Group-Object {
    $gb = [decimal]$_.TotalGB
    if ($gb -lt 1)   { "< 1GB" }
    elseif ($gb -lt 5)  { "1–5GB" }
    elseif ($gb -lt 20) { "5–20GB" }
    else              { "> 20GB" }
} | Select-Object Name, Count

The output of this categorisation directly informs your batch schedule. > 20GB mailboxes go into the first pre-staging wave, migrated outside business hours, over multiple weeks before their department's cutover weekend.

Throttling Policy Tuning

Microsoft supports a Set-ThrottlingPolicy cmdlet that can adjust per-user migration limits on the Exchange Online side. This requires a support case with Microsoft for most tenants, but it is worth requesting for large migrations.

On the on-premises side, you have more control:

# Create a migration-specific throttling policy
New-ThrottlingPolicy -Name "MigrationHighPriority" `
    -EwsMaxConcurrency 100 `
    -EwsMaxSubscriptions Unlimited `
    -EwsCutoffBalance 3000000 `
    -EwsMaxBurst 300000 `
    -EwsRechargeRate 900000

# Apply to the migration service account
Set-Mailbox -Identity "migration-svc@contoso.com" -ThrottlingPolicy "MigrationHighPriority"

Important: This policy applies to the migration service account on-premises. It does not affect the Exchange Online-side throttling. It does remove a common bottleneck where the migration service account itself is throttled during high-volume migrations.

DNS Cutover Timing

The DNS cutover window is the highest-risk moment in any Exchange migration. The objective is to make it boring.

Pre-work (T-minus 48 hours):

# Check current MX TTL
Resolve-DnsName -Name contoso.com -Type MX -Server 8.8.8.8 | Select-Object NameExchange, TTL

If TTL is > 300 seconds, reduce it now. Low TTL ensures that when you change the MX record, the change propagates globally within 5 minutes rather than 4 hours.

Pre-stage validation (T-minus 24 hours):

# Verify all cutover-batch mailboxes have completed pre-staging
Get-MigrationUser -BatchId "Cutover-Batch-01" |
    Where-Object { $_.Status -ne "Synced" } |
    Select-Object Identity, Status, SyncedItemCount, SkippedItemCount

Any Status -ne "Synced" entries need attention before the cutover window opens.

Cutover sequence:

1. Update MX record to EOP (Exchange Online Protection) endpoint
2. Update Autodiscover CNAME if not already pointing to cloud
3. Wait 5 minutes for DNS propagation (verify with Resolve-DnsName from external resolver)
4. Complete migration batches (delta sync only at this point)
5. Verify mail flow: send test from external account, confirm delivery in Exchange Online

Post-Migration Validation Checklist

Cutover is not complete when mailboxes are moved. Mail flow validation takes 48 hours to be confident.

Immediate (T+0h):

• [ ] External mail arriving in Exchange Online (test from Gmail, Office365.com, external domain)
• [ ] Internal mail routing correctly (on-premises to cloud, cloud to on-premises if hybrid remains)
• [ ] Autodiscover working: Test-OutlookWebServices or Outlook profile creation test
• [ ] Calendar Free/Busy working across the hybrid boundary (if applicable)
• [ ] OWA and Outlook Mobile accessible for migrated users

T+24h:

• [ ] No mail queuing on the on-premises transport service
• [ ] No NDRs reported by users
• [ ] MX propagation confirmed globally via mxtoolbox.com
• [ ] DKIM signing active for the migrated domain
• [ ] SPF record updated to remove on-premises mail server (if fully cutover)

T+48h:

• [ ] DMARC policy evaluated — confirm no legitimate mail failing DMARC
• [ ] Migration batch closed: Complete-MigrationBatch
• [ ] Legacy on-premises Exchange transport set to receive-only (do not decommission yet)

# Verify no mail is queued on-premises post-cutover
Get-Queue -Server <on-prem-mailbox-server> | Where-Object { $_.MessageCount -gt 0 }

If queues show messages, investigate before decommissioning. There is almost always a connector or application still sending to the on-premises server.

Decision Criteria That Shape the Migration Timeline

Exchange migrations usually slip because the programme is planned around mailbox count rather than operational constraints. The schedule should be built around:

• source-environment health and storage performance
• large mailbox concentration and delegate complexity
• coexistence requirements such as Free/Busy, relay, and line-of-business applications
• realistic throughput observed during pilot batches rather than vendor-estimated averages
• the organisation's tolerance for prolonged hybrid operations

These factors determine whether the project is really a cutover-led migration, a staged coexistence programme, or a multi-wave transformation that needs stronger governance.

Common Mistakes That Extend the Cutover Window

The same issues repeatedly inflate migration duration:

• Treating pre-stage as optional. Without it, cutover night becomes a full-data migration instead of a delta completion exercise.
• Ignoring non-user mail flow. Relay, journaling, scanners, shared mailboxes, and application mailboxes often break after the user mailboxes move.
• Batching for convenience instead of dependency. Teams that share delegates, shared mailboxes, or calendar workflows should not be split arbitrarily.
• Underestimating post-cutover validation. Outlook profile repair, Autodiscover, mobile device behaviour, and connector cleanup are operational work, not admin afterthoughts.

The technical move is usually the easy part. The hard part is keeping the service predictable while both messaging platforms coexist.

Recommended Path for Enterprise Messaging Teams

The most reliable approach is:

1. Baseline throughput with pilot batches.
2. Separate large and complex mailboxes early.
3. Pre-stage well ahead of the user communication window.
4. Treat connectors, relay, and shared mailbox dependencies as first-class workstreams.
5. Keep rollback and hold-state decisions clear before the DNS cutover begins.

What to validate before each batch is closed:

• inbound and outbound mail flow
• delegate access and shared mailbox behaviour
• Autodiscover and Outlook reconnect experience
• Free/Busy across any remaining hybrid boundary
• relay and application mail paths that still depend on the old environment

When to Escalate, Not Optimise

There is a point in every large migration where more local tuning stops helping. Escalate to Microsoft, or pause the schedule, when:

• pilot throughput is materially below the assumptions used for the migration plan
• batches remain stalled despite clean source-side health
• service degradation on the source environment starts affecting production users
• cutover dates are being protected by optimism rather than by observed migration behaviour

The disciplined decision is often to re-plan the wave, not to keep forcing the same batch design harder.

Throttling problems are solvable when you plan for them. Most migrations go wrong because throttling is discovered after the cutover window has started. Book a discovery call to review your migration plan before that happens.

Carlos AnnesSenior Microsoft 365 / Hybrid Architect10+ years designing and securing enterprise Microsoft infrastructure.