How to Migrate Exchange to Office 365

Migrating from on-prem Exchange to Office 365 is a project where the technical work is the smaller half. Picking the right path, getting MRSProxy and Autodiscover behaving, managing throttling, and timing the public folder cutover are what determine whether your migration finishes on schedule. This guide walks through the three legitimate paths (cutover, staged, hybrid), then through the specifics that bite in any of them: throttling policies, public folder ordering, and the role of Azure AD Connect when identity comes along for the ride.

Picking the path: cutover vs staged vs hybrid#

Three first-party paths exist, and one of them is right for you based on three variables: mailbox count, coexistence duration, and identity complexity.

• Cutover. Move every mailbox in one window, then flip MX and decommission. Good for under 150 mailboxes and a one-weekend tolerance. No coexistence — anything sent during the cutover window queues on one side or the other.
• Staged. Move mailboxes in batches over weeks. MX stays on-prem until the last batch. Good for 150 to 2000 mailboxes. Requires source-side patches and a clean Exchange topology because the source is in production the whole time.
• Hybrid. Coexistence with full free/busy lookups, cross-premises permissions, and centralised admin. Requires at least one Exchange 2016+ hybrid server, Azure AD Connect, and certificate work. The right choice for prolonged coexistence (months) and for organisations that may keep some workloads on-prem permanently.

If you have a hybrid Exchange deployment already, the hybrid Exchange overview covers the architecture. If you have not seen Autodiscover trip up a migration before, the Autodiscover glossary entry is worth five minutes.

Source-side prerequisites#

Regardless of path, get these right before you create a migration endpoint:

• Exchange is patched to a supported cumulative update. Microsoft will refuse to validate a migration endpoint against ancient builds.
• MRSProxy is enabled on the client access services. Validate it externally using the Microsoft Remote Connectivity Analyzer's "Exchange Server" tests.
• EWS is reachable from the public internet on the same FQDN as your Autodiscover record. Internal-only EWS will not work for Microsoft's remote move pipeline.
• Disconnected mailboxes and orphaned public folder mail-enabled objects are cleaned up. Orphans cause batch failures that look like permission errors but are not.
• A migration admin account exists with the ApplicationImpersonation role and sufficient mailbox read access.

The Exchange migration guide covers source-side hygiene in more depth, including the Exchange-version-specific gotchas.

Destination-side prerequisites#

On the Office 365 side:

• Domain verified, MX TTL lowered to 300 seconds 24 to 48 hours before planned cutover.
• Users provisioned and licensed. License before migration, not after — Exchange Online will refuse mailbox moves into unlicensed targets.
• If going hybrid, the Hybrid Configuration Wizard has run successfully and the OAuth or Office 365 sharing relationship is in place.
• Mailbox throttling policy reviewed. Default policy can throttle the migration's own connections if you push too hard. You can apply a relaxed throttling policy to the migration admin account.

How to run the migration#

1. Choose your migration path

   Score your environment against mailbox count (under 150 leans cutover, 150 to 2000 leans staged, anything larger or with prolonged coexistence leans hybrid), how long you can tolerate coexistence (zero leans cutover, weeks leans staged, months leans hybrid), and identity complexity (cloud-only identity leans cutover/staged, on-prem AD with SSO leans hybrid). Write the decision down — it shapes every subsequent step.

2. Prepare the source Exchange environment

   Patch Exchange to a supported CU. Validate that MRSProxy is enabled by running an external test from Microsoft's Remote Connectivity Analyzer against your Autodiscover and EWS endpoints. Resolve any TLS/certificate warnings — Microsoft's pipeline will refuse a connection that returns even a cosmetic certificate error. Clean up disconnected mailboxes, orphaned public folders, and any litigation hold quirks.

3. Stand up the destination Office 365 tenant

   Verify the destination domain. Provision users — by direct sync if you are setting up Azure AD Connect, or by CSV import for cloud-only. License every target mailbox. If you are going hybrid, run the Hybrid Configuration Wizard now and confirm cross-premises free/busy works in both directions before scheduling user batches.

4. Create the migration endpoint

   In the Exchange Admin Center, go to Migration > Endpoints. Create a new remote move endpoint (for hybrid) or an Exchange Outlook Anywhere endpoint (for staged) pointing at your MRSProxy URL. Use the migration admin account credentials. Validate the endpoint — if validation fails, fix the source-side issue (usually a cert or DNS problem) before you go further. Do not create batches against a failing endpoint.

5. Run a pilot batch

   Pick 3 to 5 representative mailboxes: a normal user, a heavy mailbox (>30 GB), one with extensive shared calendar use, one with delegate permissions to other mailboxes, and a shared mailbox. Move them, then verify item counts, Sent items, calendar attendees, and delegate permissions. Open Outlook desktop on Windows and Mac, plus mobile. If any client fails to connect after the move, fix the underlying Autodiscover issue before you touch anything else.

6. Migrate mailboxes in batches

   Group users into batches of 50 to 100. Stagger batch start times by 30 to 60 minutes. Run during off-hours in the source time zone. Monitor batch progress in EAC and in your migration tool. Watch for Too many simultaneous connections and similar throttling responses — back off if you see them sustained. Expect 90 to 180 minutes per 10 GB at typical throttle ceilings.

7. Migrate public folders

   Public folders are their own beast. Run them after mailbox batches complete and verify. Use Microsoft's PowerShell scripts for the migration — there is no GUI path. Lock public folder write access on-prem during the final delta sync to avoid divergence. Validate permissions on the destination side; public folder ACLs occasionally need a manual touch.

8. Cut over Autodiscover and decommission

   Switch the Autodiscover record from on-prem to autodiscover.outlook.com. Outlook desktop will detect the change on next launch and walk users through a re-prompt. Communicate this. Monitor for clients that do not re-prompt cleanly — usually because of a cached profile or a hard-coded server name. Plan the on-prem Exchange decommission for 30 to 90 days post-cutover; in hybrid scenarios you keep at least one on-prem Exchange server for recipient management.

Throttling: source and destination#

Exchange Online enforces throttling at multiple layers, and on-prem Exchange has its own throttling policies. Realistic ceilings:

• Microsoft's migration pipeline auto-paces to stay under tenant ceilings but you can be too aggressive on the source side and starve normal users.
• Third-party tools doing EWS-based moves push through MRSProxy and are subject to the same throttling. Most tools (Mailbox Taxi included) cap per-mailbox concurrency to 2 to 4 threads.
• The combined practical ceiling per mailbox is roughly 1 to 3 GB per hour depending on average message size and source storage speed.

If your source Exchange is running on spinning disk, that is your bottleneck, not the network. Move source databases to SSD-backed storage before the migration if you can.

Public folders: the boss fight#

Public folders are the single most common cause of an Exchange migration overrunning:

• They migrate last, not first. Mailboxes can rely on public folders during migration if you set up coexistence in hybrid, but the final cut moves public folders after mailboxes.
• The hierarchy must be clean. Orphaned mail-enabled public folder objects in AD will cause batch failures.
• The Microsoft PowerShell migration scripts have version-specific quirks. Use the script set that matches your source Exchange version, not an older or newer one.
• Permissions on public folders sometimes need to be re-set after migration. Audit a sample post-move.

If you are unsure your public folder estate is clean, run the Microsoft PublicFolderToMailboxMapGenerator.ps1 and check that every mailbox bucket is under the 50 GB ceiling Exchange Online enforces.

Azure AD Connect at a high level#

For cutover and most staged migrations, you can run cloud-only identity. For hybrid you need Azure AD Connect. Even if you are going cutover, consider setting up Azure AD Connect before cutover if there is any chance you will want on-prem AD as the identity source later — retrofitting AAD Connect after Office 365 mailboxes exist is messier than doing it first.

Set the source-of-authority correctly. If on-prem AD is authoritative, AAD Connect writes into the cloud. If you are decommissioning AD entirely, plan the cutover of authoritative source and the eventual AAD Connect decommission separately from the mailbox move.

Errors you will recognise#

• AUTHENTICATIONFAILED — migration admin credentials are wrong or the account lost ApplicationImpersonation.
• Too many simultaneous connections — you exceeded EWS per-user throttling. Reduce concurrency.
• MRSProxy unavailable — MRSProxy disabled, EWS unreachable, or certificate problem. Re-validate with Microsoft Remote Connectivity Analyzer.
• Message too large for destination — message over Exchange Online's 150 MB ceiling. Skip and report.
• Folder UTF-7 conversion error — folder name contains characters that fail IMAP encoding. Rare on Exchange-to-Exchange but seen on archives imported from elsewhere.

Communication#

Users care about three moments:

1. The announcement. "We are moving to Microsoft 365. Here is when. Here is what changes."
2. The 72-hour notice. "Your mailbox is in batch 4. Cutover is Thursday at 8pm. Mobile will need re-adding."
3. Cutover day. "We are live on Microsoft 365. Outlook may prompt for new credentials. Here is the help-desk."

The 72-hour notice has the highest read rate. Make it useful.

After cutover#

Keep on-prem Exchange running for at least 30 days. Reasons:

• Late mail that bounced during MX propagation.
• Recipient management in hybrid setups (you keep one Exchange server long-term for this).
• Time to chase down clients that did not re-prompt cleanly.

If you are running a parallel Exchange-only path (no Microsoft 365 license intended), the Exchange Server to Exchange Online write-up covers the same territory framed as Exchange-only. For the pillar context, the complete email migration guide ties this to the broader migration framework. And if you need the Microsoft-side prerequisites laid out separately, the Office 365 migration guide is the right deep-dive.