Hybrid Email & Exchange

A hybrid Exchange deployment connects your on-prem Exchange Server organisation with Exchange Online (Microsoft 365) so both coexist as a single unified email system. Users on either side share the same domain, see the same address book and can view each other's calendar availability. Mail routes correctly between on-prem and cloud mailboxes without any configuration visible to end users. The hybrid connection is established through Microsoft's Hybrid Configuration Wizard, which sets up the connectors, OAuth trust and namespace plumbing between the two environments.

No. The hybrid topology is designed precisely for organisations that need to keep some mailboxes on-prem permanently, or for those planning a phased migration that may take months or years. Executives, regulated roles, users whose workflows depend on on-prem applications, and any mailbox that needs to stay under direct infrastructure control can remain on Exchange Server indefinitely. On-prem and cloud users work together without friction across the shared namespace.

The Hybrid Configuration Wizard establishes an OAuth trust relationship between Exchange Server and Exchange Online that enables free/busy lookups to cross the boundary. When an on-prem user checks availability for a cloud user, or vice versa. The query passes securely between the two organisations and returns real-time free/busy data. The Global Address List is synchronised via Entra ID Connect, so contacts and address book entries are consistent on both sides.

Entra ID Connect (formerly Azure AD Connect) is the directory synchronisation service that keeps your on-prem Active Directory and Entra ID aligned. It synchronises user accounts, group memberships, attributes and, depending on your configuration, password hashes or pass-through authentication tokens. Without it, cloud and on-prem mailboxes would be managed as separate identity stores. With it, a single change in on-prem AD propagates to the cloud within minutes, and licensing, Conditional Access policies and MFA apply from a single identity source.

It depends on mailbox count, data volumes, legacy application dependencies and how quickly the organisation can validate each wave. A 200-mailbox migration with straightforward dependencies typically runs over six to ten weeks from assessment to final decommission. Larger estates with complex transport rules, on-prem application integrations or compliance-sensitive mailbox subsets take longer. We build the wave plan and timeline in the design phase, with written milestones and decision points throughout, before any migration work starts.