Exchange hybrid deployment

A hybrid Exchange deployment connects an on-premises Exchange Server organisation with Exchange Online so the two behave as one mail system: a shared address book, cross-premises calendar free/busy, secure internal mail flow, and — the real point — the ability to move mailboxes to the cloud transparently, in waves, while everyone keeps working. It's the standard migration pattern for any organisation of size coming off on-prem Exchange, and for some it becomes a long-term operating mode.

Be honest with yourself about which of those two you're doing. "Hybrid as a bridge" and "hybrid as a destination" are both legitimate; drifting from the first into the second because nobody scheduled the last migration wave is how organisations end up patching Exchange servers in 2030.

What hybrid provides

Once configured:

• Single namespace — mail.yourcompany.com and Autodiscover work for both on-prem and cloud users.
• Cross-premises free/busy — calendar availability resolves correctly in both directions.
• Cross-premises mail flow over TLS-secured connectors, treated as internal — no internet hop, headers and internal-sender status preserved.
• A unified global address list, because both sides share the directory synced through Entra Connect.
• Mailbox moves in both directions — onboarding to the cloud and, rarely but usefully, offboarding back.
• OAuth between the organisations, which lights up cross-premises archive access, eDiscovery, and MailTips.

What's required

• A supported on-premises Exchange Server to act as the hybrid endpoint.
• Microsoft Entra Connect (or Cloud Sync) syncing identities — see Entra Connect vs Cloud Sync, and note that Exchange hybrid writeback is one of the scenarios that still favours classic Entra Connect.
• A public certificate trusted by both ends for mail flow and web services.
• DNS in order: Autodiscover, MX, SPF, and the namespaces the wizard will bind.
• The Hybrid Configuration Wizard (HCW) run against your tenant.

The HCW deserves demystifying, because it looks like magic and is actually bookkeeping: it creates and configures send/receive connectors on both sides, sets up the federation trust and organisation relationships for free/busy, enables OAuth, and stamps the configuration into both organisations. Almost everything it does can be inspected afterwards in the admin centers — and when hybrid breaks, re-running the HCW is the supported first repair step.

Full vs minimal hybrid

• Full hybrid — the complete coexistence feature set: free/busy, MailTips, sharing policies, message tracking, cross-premises moves. Required if the two organisations will coexist for a long period.
• Minimal hybrid — mail flow and mailbox moves only, designed for organisations that will be cloud-only within months and don't need calendar coexistence in the meantime.

Choose minimal if the migration project has an end date this fiscal year; choose full if coexistence will outlive anyone's patience. There's also Exchange Modern Hybrid, which uses a Microsoft-published agent to avoid inbound firewall ports for the hybrid endpoints — worth knowing for security-constrained networks, with some feature trade-offs.

Migration patterns

• Hybrid migration — the modern default. Mailboxes move in batches via the Mailbox Replication Service (MRS Proxy) while users keep working; the final incremental sync and cutover happen when you complete the batch, and Outlook simply reconnects to Exchange Online. No PST files, no data loss, no flag day.
• Cutover migration — everything at once, only sensible under ~150 mailboxes, and even then hybrid batches are usually less stressful.
• Staged migration — a legacy pattern for ancient Exchange versions; if this applies to you, the migration is the least of your problems.

The broader project — licensing, DNS cutover, client rollout — is covered in the guide on migrating from on-premises Exchange to Microsoft 365.

The last Exchange server problem

Here's the part that surprises people: after the last mailbox moves to the cloud, you usually can't just turn off Exchange on-prem. While Entra Connect syncs your AD to the cloud, the on-prem Active Directory remains the source of authority for mail attributes — and the only supported way to edit those attributes is Exchange management tooling. Editing proxyAddresses by hand in AD works right up until it doesn't.

The historical answer was keeping one Exchange server running forever, unloved and unpatched. The current answer is better: the Exchange Management Tools role (Exchange 2019 CU12 and later) lets you manage recipient attributes with PowerShell and no running Exchange server at all, provided recipient management is your only remaining need. Alternatively, moving identity management fully to the cloud — no Entra Connect, cloud-mastered users — removes the problem entirely, which is realistic for smaller organisations.

Also on the horizon: Exchange Server Subscription Edition (SE) is now the only supported on-prem version, sold by subscription. If your hybrid server estate is on 2016 or 2019, the support clock has run out — upgrading the hybrid endpoint to SE (an in-place upgrade from 2019) is part of any "hybrid as destination" plan, and a good forcing function for the "why are we still hybrid?" conversation.

Practical advice

1. Decide bridge vs destination, and put the decommission date in the project plan.
2. Run full hybrid unless you'll be done within a quarter.
3. Move pilot mailboxes early — IT first — and let the batch tooling do the work.
4. When the last mailbox lands, decommission down to Management Tools (or nothing), not down to "one server we'll deal with later."

Hybrid Exchange is mature, well-trodden technology. The failure mode isn't technical — it's the migration that never quite finishes.