Exchange Server Migration: On-Prem and Online

Exchange migration projects rarely fail at the move-mailbox step. They fail at autodiscover not propagating, at MRSProxy missing a certificate SAN, at public folders that nobody discovered until cutover Saturday, at a throttling policy that capped the migration service account silently. This pillar walks you through every exchange migration scenario — on-prem to on-prem, on-prem to Exchange Online, hybrid coexistence, and the protocol-level mechanics (MRSProxy, autodiscover, MAPI/HTTP, modern auth) that the documentation assumes you already know.

The shapes of Exchange migration#

Five distinct migration shapes show up in production. Pick yours before any tooling discussion.

Exchange on-prem to Exchange on-prem#

A legacy hardware refresh: move from an old Exchange version to a newer one in the same forest. Microsoft's supported in-place upgrade ended years ago, so you're effectively doing a side-by-side: stand up new servers, move mailboxes, decommission old. Native Move-Mailbox or New-MoveRequest handles it.

Exchange on-prem to Exchange Online (cutover)#

A single-shot move for small estates from Exchange 2010+ to Microsoft 365. No hybrid, no coexistence — flip the switch, rebuild Outlook profiles, and accept the user-visible disruption. Works under approximately 150 mailboxes.

Exchange on-prem to Exchange Online (hybrid)#

The default path for anything larger. Configure hybrid via the Hybrid Configuration Wizard, link the on-prem org to the tenant, and use native New-MoveRequest cmdlets to move mailboxes without breaking Outlook profiles, free/busy, or mail flow. The migrate Exchange to Office 365 guide covers this in operational detail.

Exchange Online to Exchange Online (cross-tenant)#

A tenant-to-tenant move. Microsoft's cross-tenant mailbox migration is generally available and uses MRS over the Microsoft network — much faster than IMAP or EWS. The tenant-to-tenant migration guide has the cross-tenant specifics.

Exchange to a non-Exchange destination#

Migrating out of Exchange to Google Workspace, IMAP-only hosts, or other platforms. Native Microsoft tooling doesn't support this; you'll use a third-party tool reading the source over EWS or MAPI/HTTP. See migrate Exchange to Google Workspace for the most common out-of-Exchange case.

The Office 365 migration playbook covers the destination side when you're heading into Microsoft 365; this guide focuses on the Exchange-specific mechanics.

Discovery for an Exchange source#

For an Exchange source, your discovery has to capture protocol-level state most tooling won't fingerprint for you:

• Exchange version, cumulative update level, and patch level on every server.
• Mailbox count, total size, item count distribution.
• Public folder hierarchy — count, size, and modern public folder vs legacy public folder.
• Shared mailboxes and resource mailboxes (rooms, equipment).
• Distribution groups, dynamic distribution groups, mail-enabled security groups.
• Delegations and "send on behalf" relationships.
• Mobile devices via ActiveSync association.
• Existing throttling policies — both default and any custom ones.
• Outlook client versions in use. Outlook 2016 and newer handle MAPI/HTTP; older clients depend on Outlook Anywhere over RPC/HTTP.
• Third-party integrations: archiving (Mimecast, Proofpoint, Barracuda), journaling, signature management, encryption gateways.
• Address book policies and address list scoping.

MRSProxy and the transport layer#

For any hybrid or hybrid-style migration to Exchange Online, the Mailbox Replication Service Proxy (MRSProxy) is the bridge. Conceptually it sits on your Client Access role and publishes EWS over HTTPS so Exchange Online's MRS can pull mailbox data.

The conceptual requirements (specifics vary by Exchange version — check current Microsoft documentation when you plan):

• MRSProxy enabled on the EWS virtual directory.
• A publicly trusted TLS certificate with the right SAN entries, including your autodiscover and EWS hostnames.
• HTTPS on port 443 reachable from Exchange Online's published IP ranges.
• The EWS endpoint published through your reverse proxy or load balancer.
• A migration endpoint defined in the destination tenant pointing at your MRSProxy URL.

A common failure pattern: the certificate is valid and trusted, but the SAN list is missing the EWS hostname. Migration endpoint tests pass, real mailbox moves fail at SSL handshake. Inspect the cert chain Exchange Online sees, not the one your browser sees.

Autodiscover: the silent killer#

Autodiscover is the protocol Outlook uses to figure out where a mailbox lives. In a hybrid Exchange world, autodiscover decides whether Outlook talks to on-prem or to Exchange Online for any given mailbox.

The lookup order Outlook follows (simplified):

1. Local Outlook autodiscover XML override (if configured).
2. SCP record in Active Directory (for domain-joined clients).
3. https://<smtp-domain>/autodiscover/autodiscover.xml
4. https://autodiscover.<smtp-domain>/autodiscover/autodiscover.xml
5. DNS SRV record _autodiscover._tcp.<smtp-domain>
6. Outlook's hard-coded fallback to autodiscover.outlook.com for known M365 domains.

During a hybrid migration, autodiscover keeps pointing to your on-prem org until you change it. That's correct — on-prem owns mail flow until cutover. After the final mailbox moves, you switch the public autodiscover record to autodiscover.outlook.com.

The autodiscover glossary entry covers the protocol in detail, including the SCP-vs-DNS resolution order that catches domain-joined clients.

Common autodiscover failures:

• Stale local Outlook cache. Clear %LOCALAPPDATA%\Microsoft\Outlook autodiscover XML files.
• SCP record still pointing at on-prem after Exchange decommission. Manually remove it.
• DNS record TTL too long. Drop to 300 seconds before cutover.
• Certificate mismatch on the autodiscover endpoint.

Cutover vs staged vs hybrid (for Exchange specifically)#

The generic cutover-vs-staged-vs-hybrid logic applies, but Exchange has version-specific constraints worth calling out.

Cutover#

• Works for Exchange 2010 SP3 and newer.
• Capped at 2,000 mailboxes by Microsoft; practically capped at ~150 for predictable timing.
• All mailboxes move in a single batch.
• Mail flow re-routes at MX switch, no coexistence.
• Outlook profiles rebuild post-cutover.

Staged#

• Only formally supported for Exchange 2003 and 2007.
• Mailboxes move in batches, with mail flow coexisting via the Hybrid Agent or via a manual SMTP relay.
• For Exchange 2010+, "staged-style" is achieved by batching New-MoveRequest in hybrid mode.

Hybrid#

• Requires Exchange 2010 SP3 or newer on-prem.
• Requires Entra Connect (formerly Azure AD Connect) for identity sync.
• Requires MRSProxy enabled on the EWS endpoint.
• Supports long-term coexistence — months or years if needed.
• Allows native New-MoveRequest from on-prem to tenant.
• Preserves Outlook profiles across the move.

The cutover vs staged vs hybrid breakdown has the decision matrix with cost and timeline estimates.

Throttling policies during migration#

Exchange Server's throttling engine is granular. By default, the policies that govern day-to-day client behaviour also govern your migration service account, which means your migration tool gets throttled the same way Outlook does.

The pattern to apply:

1. Create a dedicated throttling policy with relaxed EWS limits (EWSMaxConcurrency, EWSMaxBurst, EWSRechargeRate, EWSCutoffBalance).
2. Apply it explicitly to your migration service account via Set-ThrottlingPolicyAssociation.
3. Verify with Get-ThrottlingPolicyAssociation before the pilot batch runs.
4. Remove the association the day the migration completes.

Do not modify the default throttling policy. You'll affect every account in the org and create issues that survive the migration project.

On Exchange Online side, throttling is enforced by Microsoft and you can't relax it. The published EWS soft limit is approximately 2,000 items per hour per mailbox, plus tenant-wide ingestion ceilings. The Office 365 throttling fix guide covers the tenant-side recovery pattern when you hit the wall.

MAPI/HTTP and modern auth#

Exchange 2013 introduced MAPI over HTTP as the replacement for Outlook Anywhere (RPC over HTTP). By Exchange 2016 it was the default; by 2019 RPC/HTTP was effectively gone.

What this means for your migration:

• Outlook 2013 and later prefer MAPI/HTTP.
• Outlook 2010 falls back to RPC/HTTP, which requires Outlook Anywhere enabled on Exchange.
• MRSProxy still uses EWS over HTTPS; MAPI/HTTP is a client protocol, not a migration protocol.
• Modern authentication on MAPI/HTTP is configurable per-org; if your org has it forced on, basic auth clients will fail.

For Exchange Online, modern auth has been mandatory for most protocols since 2022. The modern auth required fix walks through the specific errors and the OAuth-app-registration recovery path.

Public folders: the migration within the migration#

Public folder migration is its own discipline. The current Microsoft path:

• Confirm public folders are "modern" (mailbox-based) on the source. If they're legacy public folders on Exchange 2010, migrate them to modern first, then migrate to Exchange Online.
• Generate a public folder mapping CSV mapping source PF mailboxes to destination PF mailboxes.
• Provision destination public folder mailboxes before the migration runs.
• Use the Microsoft-provided public folder migration scripts.
• Plan for a separate cutover window.

Do not attempt to migrate public folders in parallel with user mailboxes. The cmdlets share enough underlying state that you'll get mysterious failures on both sides.

Outlook Anywhere and the legacy client problem#

If your org still has Outlook 2010 or older clients, Outlook Anywhere (RPC over HTTP) needs to keep working until those clients upgrade. You cannot decommission Outlook Anywhere on the on-prem server just because Exchange Online doesn't need it.

The compatibility story:

• Outlook 2010 — requires Outlook Anywhere; cannot connect to Exchange Online directly after February 2023's modern-auth enforcement.
• Outlook 2013 — supports MAPI/HTTP and modern auth with recent updates.
• Outlook 2016+ — full modern auth, full MAPI/HTTP.

Audit Outlook versions during discovery. Don't migrate to Exchange Online without an upgrade plan for any client older than 2016.

The cutover sequence#

The full sequence for a hybrid Exchange-to-Exchange-Online migration:

T-minus four weeks#

• Hybrid Configuration Wizard run, mail flow tested.
• Entra Connect syncing without errors.
• MRSProxy endpoint tested with a test mailbox.
• Pilot batch (5–10 mailboxes) complete.

T-minus two weeks#

• Bulk migration batches running.
• Public folder migration scoped and scheduled separately.
• Mobile device communication sent.
• DNS TTLs dropped to 300 seconds.

T-minus one week#

• Final bulk batches complete.
• Public folders migrated and validated.
• Shared mailbox auto-mapping verified post-move.

Cutover weekend#

• Friday evening: final delta sync starts via New-MoveRequest with -SuspendWhenReadyToComplete.
• Saturday morning: deltas complete. Run Complete-MigrationBatch.
• Saturday midday: MX switch, autodiscover switch.
• Saturday afternoon: mail flow validation.
• Sunday: monitor and re-run any straggler moves.

Post-cutover#

• Decommission on-prem Exchange servers gradually (do not rush this — Microsoft requires at least one Exchange server for hybrid identity management until Edge Server or modern alternatives are in place).
• Remove SCP autodiscover records.
• Revoke any temporary throttling policy exemptions.

The email migration checklist has the printable cutover sequence with sign-off boxes.

Common Exchange migration errors#

The errors you'll see and what they mean:

• MapiExceptionShutoffQuotaExceeded — destination mailbox quota hit during move. Increase quota and resume.
• Too many simultaneous connections — throttling policy limiting concurrent EWS connections.
• MigrationPermanentException: The connection to the server was terminated — usually MRSProxy timeout or load balancer killing long-lived connections. Check idle timeout on your reverse proxy.
• AUTHENTICATIONFAILED — modern auth misalignment, expired service account password, or a Conditional Access policy blocking the migration endpoint.
• Folder UTF-7 conversion error — non-ASCII folder names that the IMAP-style converter mishandles. Pre-rename on source.
• Message too large for destination — destination tenant 150 MB cap exceeded by an oversized source message.
• STARTTLS handshake failed — usually a TLS version mismatch or a cert chain issue on the MRSProxy endpoint.
• Couldn't find recipient — directory sync hasn't completed; the destination mail-enabled user doesn't exist yet.

If a move is stuck for more than 8 hours with no progress, it's stuck. The Exchange migration stuck fix walks through the recovery pattern: Get-MoveRequestStatistics, identify the failed item, suspend, resume.

Post-migration validation#

Run this checklist for every batch:

• Item count delta per folder within 1%.
• Total size delta per mailbox within 2%.
• Free/busy resolves on-prem-to-cloud and cloud-to-on-prem during coexistence.
• Shared mailbox auto-mapping works in Outlook desktop.
• Calendar delegations preserved.
• Send-on-behalf permissions preserved.
• Mobile devices reconnect or are re-enrolled.
• Mail flow inbound: send from gmail.com, outlook.com, a personal domain.
• Mail flow outbound: send from each migrated mailbox to an external test address.
• Public folder permissions intact (if PFs are in scope).

Decommissioning on-prem Exchange#

You cannot just turn off the last on-prem Exchange server after migration. The Recipient Editor in Active Directory still requires Exchange tooling for managing mail-enabled attributes on synced objects. Microsoft has been moving toward an "Exchange Management Tools only" model where you keep the schema and management tools without running the server, but the specifics evolve.

Until that path is fully supported in your version, plan to keep one on-prem Exchange server running with no mailboxes, used only for recipient management. The hybrid Exchange architecture guide covers the long-term hybrid identity model.

What good looks like at the 72-hour mark#

A successful Exchange migration is one where, 72 hours after MX switch:

• Inbound mail flow is fully on Exchange Online.
• No more than 2% of users have reported a user-visible issue.
• Outlook profiles either auto-rebuilt via autodiscover (hybrid) or were rebuilt via the rollout script (cutover).
• Mobile devices reconnected without help-desk intervention.
• Free/busy resolves end-to-end.
• Public folders (if in scope) accessible to all delegated users.
• The dedicated migration throttling policy is removed.
• Any Conditional Access exemptions for the migration service account are revoked.

Anything less is a follow-up batch.