Exchange Server to Exchange Online Migration

Moving from Exchange Server to Exchange Online is the most common migration shape in the Microsoft world, and almost always done via hybrid. The technical work is well-understood, the tooling is mature, and the failure modes are familiar. What separates a clean migration from a painful one is the order: get hybrid right first, validate free/busy and OAuth before you touch a mailbox, then do the moves in disciplined batches. This guide walks through the hybrid-first path with the OAuth and public folder specifics that derail projects when ignored.

Hybrid or not?#

You have three paths, the same as for any Exchange to Microsoft 365 move:

• Cutover. One window, no coexistence. Under 150 mailboxes and a high downtime tolerance.
• Staged. Batches over weeks, MX stays on-prem until the last batch. 150 to 2000 mailboxes.
• Hybrid. Full coexistence, OAuth-based free/busy, cross-premises permissions. The right choice for any environment where users on both sides need to see each other's calendars during the migration, or where decommission is a long-tail process.

For Exchange-to-Exchange-Online specifically, hybrid is the default. The free/busy story alone justifies it: during a six-week coexistence, users still meeting each other still expect calendar lookups to work. Without hybrid, those lookups fail or return stale data.

If you have not deployed hybrid before, the hybrid Exchange overview covers the architecture in enough depth to plan from. The broader provider-agnostic move pattern is in Exchange to Office 365; the present post is the same territory framed for Exchange-only shops who do not see this as a "Microsoft 365" project.

OAuth: do this before you move a mailbox#

OAuth between on-prem Exchange and Exchange Online is what makes free/busy, MailTips, and message tracking work cross-premises in modern hybrid deployments. The Hybrid Configuration Wizard sets it up. Things to know:

• OAuth replaces the older organisation relationship sharing for new deployments. If your environment already runs the legacy sharing, you can migrate to OAuth, but doing it as part of the broader Microsoft 365 move is a clean opportunity.
• The OAuth handshake depends on healthy Autodiscover, valid certificates on Exchange external endpoints, and the right service principal in Microsoft Entra ID.
• Failures present as "free/busy is broken between tenants". The root cause is almost never free/busy itself — it is OAuth not completing.

Source-side prerequisites#

Regardless of path:

• Exchange is patched to a supported cumulative update.
• MRSProxy is enabled and EWS is externally reachable on the same FQDN as Autodiscover.
• Certificates are valid, including the chain. Microsoft's pipeline refuses connections with any certificate warning.
• Disconnected mailboxes are cleaned up. Orphan mail-enabled public folder objects in AD are removed.
• The migration admin has ApplicationImpersonation and the necessary scopes.
• Litigation hold and retention policies are documented. They migrate with the mailbox but the metadata occasionally needs reapplication.

The Exchange migration guide covers source-side hygiene in more depth.

Destination-side prerequisites#

On the Exchange Online side:

• Microsoft Entra ID is populated, ideally by Azure AD Connect from on-prem AD.
• Every target mailbox is licensed (Exchange Online Plan 1 or Plan 2, or the bundled SKU).
• The Hybrid Configuration Wizard has run and free/busy is verified.
• Mailbox throttling for the migration admin is appropriate. Default policy throttles aggressive migration traffic.
• The Autodiscover record still points at on-prem Exchange. It will flip at cutover.

How to run the migration#

1. Decide on hybrid vs non-hybrid

   Score your environment: mailbox count, coexistence duration, whether free/busy needs to work cross-premises, identity model. Most enterprises moving Exchange Server to Exchange Online land on hybrid. Document the decision and the rationale — it will be asked about by the steering group and by future operators wondering why one Exchange server is still running.

2. Patch and prepare on-prem Exchange

   Bring Exchange to a supported CU. Validate MRSProxy and EWS externally with Microsoft's Remote Connectivity Analyzer. Resolve all certificate warnings — even cosmetic ones. Clean up disconnected mailboxes, soft-deleted recipients, and orphan public folder mail-enabled objects in AD. The on-prem environment must be in a clean state before the hybrid configuration runs.

3. Run Azure AD Connect

   Set up Azure AD Connect from on-prem AD to Microsoft Entra ID. Wait for the initial sync to complete and confirm every user that needs a destination mailbox is present in Entra ID with the correct UPN and proxyAddresses. If users have UPN suffixes that do not match the destination domain, fix that now — the Hybrid Configuration Wizard will not migrate accounts but it will use the synced data and any mismatch shows up as a mailbox routing problem later.

4. Run the Hybrid Configuration Wizard

   Download the current Hybrid Configuration Wizard from the Microsoft 365 admin centre and run it from an on-prem Exchange server with internet access. It configures OAuth (or the organisation relationship if you are on an older Exchange version), federation trust, send and receive connectors, accepted domains, and the email address policy adjustments needed for hybrid. After it completes, test cross-premises free/busy from a pilot on-prem mailbox to a pilot cloud mailbox in both directions. If free/busy fails, do not proceed to batches.

5. Create the migration endpoint and pilot

   In the Exchange Admin Center, create a remote move migration endpoint pointing at your on-prem MRSProxy URL. Use migration admin credentials. Validate the endpoint. Pick 3 to 5 pilot mailboxes — one normal, one heavy (>30 GB), one with extensive shared calendar use, one with delegate permissions, and a shared mailbox. Move them, then verify item counts, Sent integrity, calendar attendees, delegate permissions, and that Outlook desktop on Windows and Mac plus mobile clients reconnect cleanly.

6. Move mailboxes in batches

   Group remaining users into batches of 50 to 100. Stagger batch start times by 30 to 60 minutes to avoid hitting tenant-level throttling in one wave. Run off-hours in the source time zone. Monitor batch progress in EAC and watch for Too many simultaneous connections or Connection was aborted — both are throttling signals. Reduce concurrency rather than retry harder. Expect 90 to 180 minutes per 10 GB mailbox at typical throttle ceilings.

7. Migrate public folders

   Public folders go last. Run Microsoft's PowerShell-based public folder migration scripts (matched to your source Exchange version, not a different version). Lock source-side public folder writes during the final delta sync to avoid divergence. Validate ACLs on the destination — public folder permissions occasionally need a manual touch after migration. If your public folder estate has not been touched in 18 months, consider archiving instead of migrating. Less to migrate means less to break.

8. Flip Autodiscover and start decommission planning

   Switch Autodiscover from mail.yourcompany.com to autodiscover.outlook.com. Outlook desktop will detect the change on next launch and walk users through a re-prompt. Communicate that. Monitor for clients that do not re-prompt cleanly — usually because of a cached profile, a hard-coded server name, or an outdated mobile app. Plan the on-prem Exchange decommission for 30 to 90 days post-cutover. Keep at least one residual hybrid Exchange server long-term for recipient management of any AD-synced users.

Free/busy lookup during coexistence#

Free/busy is the indicator that hybrid is healthy. During coexistence:

• On-prem users querying a cloud user's calendar go via the organisation relationship or OAuth handshake to Exchange Online.
• Cloud users querying an on-prem user's calendar go the other direction.
• A small delay (1 to 5 seconds) on the first lookup is normal; subsequent lookups are cached.
• Persistent failures usually trace to certificate issues, broken Autodiscover, or a stale federation trust. Microsoft's Test-FederationTrust and Test-OrganizationRelationship PowerShell cmdlets surface the right diagnostics.

If you see lookups working in one direction but not the other, the broken direction is the one to investigate first. Asymmetry almost always points at a specific endpoint, not a fundamental config error.

Public folders revisited#

Public folders are where Exchange-to-Exchange-Online migrations overrun:

• Migrate them after mailboxes, never before.
• The source-side hierarchy must be clean. Run PublicFolderToMailboxMapGenerator.ps1 and check no mailbox bucket exceeds Exchange Online's 50 GB ceiling.
• The PowerShell migration scripts have version-specific quirks. Match the script set to your Exchange version.
• After migration, validate ACLs on a sample. If permissions are wrong, fix on the destination, not by re-running the migration.

Throttling#

Realistic ceilings:

• Per-mailbox concurrent connections: 2 to 4 threads is typical. More starts triggering throttling.
• Per-batch throughput: 1 to 3 GB per hour per mailbox, depending on message size profile.
• Tenant-level: Microsoft's pipeline auto-paces, but third-party tools (Mailbox Taxi included) need to respect the same ceilings.

Throttling messages to watch for in tool logs: Too many simultaneous connections, Connection was aborted, OAuth2 token expired (which is sometimes a transient retry storm, not an actual auth failure).

Errors you will recognise#

• AUTHENTICATIONFAILED — migration admin credentials wrong or ApplicationImpersonation revoked.
• STARTTLS handshake failed — certificate issue on the source-side EWS endpoint.
• MRSProxy unavailable — MRSProxy disabled or EWS unreachable.
• Message too large for destination — message exceeds 150 MB. Skip and report.
• Too many simultaneous connections — throttling. Reduce concurrency.

Communication#

Three messages, same as any large migration:

1. Project announcement, two weeks out.
2. 72-hour notice to the user's batch.
3. Cutover-day note with the help-desk contact.

The migration cuts each user's mobile profile. Make that the headline of the 72-hour notice. Everything else is secondary in the user's mind.

After cutover#

Keep at least one on-prem Exchange server running long-term in hybrid configuration. It is used for recipient management of any AD-synced users that remain — you cannot fully manage hybrid recipients from Exchange Online's admin UI alone. Microsoft licenses this residual server free for tenants in hybrid configuration.

For the broader pillar context, the complete email migration guide sets out the framework that applies to every provider pair. The Office 365 migration guide covers the destination-side prerequisites in more depth and is worth reading even if you think of this as an Exchange-only project. And the Autodiscover glossary entry is five minutes well spent if you have never had Autodiscover break a migration.