Exchange hybrid, still running in 2026

Exchange hybrid was supposed to be temporary. A great many organisations still run it, and a meaningful number run it because they moved every mailbox years ago and then discovered they could not switch the last server off.

Three things have changed recently enough that advice written even two years ago is now misleading: Exchange Server Subscription Edition replaced the version-numbered releases, the hybrid trust between your organisation and Exchange Online moved to a dedicated application, and hybrid features are migrating from Exchange Web Services to Microsoft Graph.

The problem: why the last server persists

Directory synchronisation makes Active Directory authoritative for mail-enabled objects. The cloud object’s mail attributes come from on premises, and the supported way to write those attributes is the Exchange management tools. Editing proxyAddresses by hand in Active Directory Users and Computers is not a supported recipient management method, and it goes wrong in ways that are tedious to unpick.

So the last Exchange server stays, not to hold mailboxes but to manage recipients. That is the actual dependency, and it is worth naming precisely because it determines your exit route: the server exists because directory synchronisation is running, not because mail is still on premises.

Design choice one: which server you are running

Exchange 2016 and Exchange 2019 have reached the end of their support, and the successor is Exchange Server Subscription Edition. It is licensed by subscription rather than by version, and it is the supported on-premises Exchange going forward.

The practical consequences:

• An unsupported Exchange server in a hybrid configuration is not a theoretical risk. It is an internet-adjacent, highly privileged server in your Active Directory, no longer receiving security updates. Exchange’s history of serious remotely exploitable vulnerabilities makes this the single most urgent item in most hybrid estates.
• The Hybrid Configuration Wizard is now a cloud-based application that you download and run, rather than a component of the server. Expect the wizard to update independently of your server build.
• Cumulative and hotfix updates matter more than before, because hybrid capability is now being delivered through them. The May 2026 hotfix update is a specific example: it is what enables the Graph-based hybrid flow described below.

If you are running Exchange 2016 or 2019 in hybrid today, upgrading to Subscription Edition is the first piece of work, ahead of any redesign.

Design choice two: the dedicated Exchange hybrid app

Historically, hybrid used a shared service principal in Microsoft Entra ID — an identity common across tenants. Microsoft replaced this with a dedicated Exchange hybrid application, unique to your tenant, configured by a Microsoft-supplied script (ConfigureExchangeHybridApplication.ps1).

This is a genuine security improvement: your hybrid trust is now an application you own, with permissions you can see and revoke, rather than a shared identity. It is also a migration step you must actually perform — it does not happen by itself, and the older arrangement is being retired.

Two things to plan for:

• The configuration is a script run against both Exchange Server and your tenant, requiring privileged access to each. Treat it as a Tier 0 change with a maintenance window.
• The application’s permissions are the hybrid trust. They belong on the inventory described in application consent in Microsoft Entra ID, and they should have a named owner.

Design choice three: the EWS to Graph transition

Exchange Web Services is being retired in Exchange Online in October 2026. That retirement affects your own applications, which is covered in the EWS retirement readiness plan, and it also affects hybrid itself, because several hybrid features used EWS under the covers.

The current position is a transition rather than a completed move. From the May 2026 hotfix update, Exchange Server supports a Graph API-based hybrid flow for the majority of hybrid features, and the configuration script can assign Graph permissions to the dedicated hybrid application. Some features are not yet supported over Graph and still require the EWS permissions to remain assigned.

The practical instruction is therefore specific and slightly awkward: apply the update, configure the Graph permissions, and do not remove the EWS permissions until you have confirmed that every hybrid feature you depend on is supported over Graph. Which features those are is documented and changing, so check it at the time you do the work rather than trusting a list from an article.

Architecture: what hybrid is actually doing

Worth restating, because the components fail independently and people conflate them.

Directory synchronisation writes identity and mail attributes from Active Directory to Entra ID. This is Entra Connect Sync or Cloud Sync, and it is a separate system with its own failure modes — see hybrid identity failure modes and choosing between Connect Sync and Cloud Sync.

Mail routing carries messages between the on-premises organisation and Exchange Online over connectors, authenticated by certificate. Certificate expiry here is a classic total-mail-flow outage with a date nobody diarised.

The hybrid trust — now the dedicated application — is what allows free/busy lookup, mailbox moves, and cross-premises features to work.

Recipient management is the Exchange management tools writing to Active Directory.

Autodiscover ties client connectivity together and is the usual suspect when free/busy works for some users and not others.

Trade-offs: the three exit positions

Stay in full hybrid. Keep Exchange Subscription Edition, patched, for recipient management and any remaining coexistence. This is the honest answer for organisations that still have on-premises mailboxes or applications relaying through Exchange. The cost is a supported, patched, highly privileged server forever.

Move to management-only. All mailboxes in the cloud, the remaining Exchange server kept solely for recipient management. Lower operational surface, same patching obligation. Microsoft has provided tooling intended to reduce this footprint, and the specifics are version-dependent enough that you should check the current guidance rather than assume.

Remove the dependency entirely. This requires ending directory synchronisation for mail-enabled objects — either by moving identity management fully to the cloud, or by accepting cloud-authoritative recipient management. That is an identity project, not an Exchange project, and it is the only route that genuinely retires the last server.

Most organisations that are stuck are stuck because they evaluated the third option as an Exchange decision and concluded it was impossible.

Implementation considerations

Patch first, redesign second. An unsupported Exchange server is the live risk. Get to Subscription Edition and a current update level before any architectural work.

Inventory what relays through Exchange. Multifunction devices, line-of-business applications, monitoring systems and scripts. This list is always longer than expected and it is the thing that blocks decommissioning. Direct send and high-volume email connectors are the usual replacements, and they need testing per sender.

Diarise every certificate in the hybrid path, with an owner and a renewal date.

Treat the Exchange server as Tier 0. Exchange holds extensive Active Directory permissions. An Exchange administrator is close to a directory administrator, which places the server firmly inside the boundary described in administrative tiering.

Re-run the Hybrid Configuration Wizard after significant changes, and read what it proposes rather than clicking through. It is the supported way to reconcile configuration drift.

Where this stops

This article is about the shape of the decision, not the procedure. Upgrading to Subscription Edition, configuring the dedicated hybrid app and moving to the Graph-based flow are each documented step by step by Microsoft, and each is version-specific enough that following a third-party summary is a poor idea.

It also does not cover Exchange Online Protection routing design, public folder coexistence, or multi-forest hybrid, each of which deserves its own treatment.

Verification and limits

Exchange Server Subscription Edition’s role, the cloud-based Hybrid Configuration Wizard, the dedicated Exchange hybrid application and its configuration script, and the May 2026 hotfix update’s Graph API hybrid flow — including that some features still require EWS permissions — were checked against current Microsoft documentation on 20 September 2026.

Nothing here was executed in a lab for this article. This is the fastest-moving area in the library: hybrid capability is being delivered through hotfix updates, and the set of features supported over Graph is changing. Confirm your build, hotfix level and the current supported flow against Microsoft’s documentation before planning any change, and do not remove EWS permissions based on this article.

References

• Deploy dedicated Exchange hybrid app
• What’s new in Exchange Server Subscription Edition
• Upgrading to Exchange Server Subscription Edition
• Exchange Server Subscription Edition lifecycle