Exchange Server 2016 and 2019 Are Out of Support: Exchange Server SE, and the EWS Block on 1 October 2026

Exchange Server 2016 and Exchange Server 2019 reached end of support on 14 October 2025. No security updates, no bug fixes, no technical support. Microsoft then sold a bridge: an Extended Security Update programme in two six-month periods, the second running from May to the end of October 2026 and bought separately from the first (an ESU purchase is Microsoft's charge, on your bill). It covers only Exchange 2016 CU23 and Exchange 2019 CU14 or CU15, and only updates rated Critical or Important. Microsoft has said there is no third period, so a server on ESU today has roughly eight weeks of patches left.

The second clock is in the tenant, not the server room. From 1 October 2026 — just over three weeks from now — Microsoft begins blocking Exchange Web Services requests to Exchange Online, and on 1 April 2027 the interface is removed for good.

There is a quieter third one already ticking. From the second week of September 2026 Microsoft raised the oldest build it accepts from an Exchange 2016 or 2019 server sending into Exchange Online over an on-premises inbound connector: at least the final public update from October 2025. Below that line mail is reported, then throttled, then rejected. On an unpatched hybrid server, that one reaches you before either headline date. We keep the running list on our Microsoft deadlines page.

Exchange Server Subscription Edition is the on-premises successor, released in July 2025. Technically it is undramatic: the first release is code-equivalent to Exchange 2019 CU15 plus its May 2025 hotfix, so this is not a re-platforming. Two things do change, and both are commercial and operational rather than technical.

First, licensing. SE is an entitlement you keep current, not a box you buy once. You need server licences and client access licences with active Software Assurance, or cloud subscription licences such as Microsoft 365 E3 or E5 covering every user or device that touches the server. If Software Assurance lapses, your rights fall back to Exchange 2019 — which is out of support. Treat SE as a renewal line in the budget rather than a capital purchase, and confirm it before planning the technical work. If your agreements are a mix of old purchases and inherited paperwork, our Microsoft Volume Licensing review is the place to start.

Second, cadence. SE follows the cumulative update rhythm with N-1 support: the current CU and the one before it are supported, and that is all. Fall two updates behind and you are running an unsupported server again without having changed version. Somebody has to own that patching, in writing, with a maintenance window already agreed. Most of the Exchange estates we are asked to rescue did not fail on architecture. They failed because nobody owned the next update.

Here is the part that changes sequencing for anyone still on Exchange 2016. Microsoft has said that Setup in SE CU2 will block coexistence with all unsupported versions — 2013, 2016 and 2019 — and allow only SE-to-SE. CU2 is scheduled for the second half of calendar year 2026, with no published date, so the honest planning assumption is that it can arrive at any point between now and the end of the year.

Why that matters depends on where you are. From Exchange 2019 CU14 or CU15 the move to SE is an in-place upgrade that behaves like installing a cumulative update: same server, same name, a change window and a validation pass.

From Exchange 2016 there is no in-place path. You build new SE servers alongside the old ones, move the client namespaces and the certificate, migrate mailboxes, archives and public folder mailboxes, then uninstall 2016. Every step of that depends on the two versions talking to each other — which is precisely what CU2 removes. A 2016-to-SE project planned around a CU2 date that does not exist is planned on hope. Build now, and let the coexistence window close behind you rather than in front of you.

For many of the organisations asking us about SE, the cheaper answer is not to run an Exchange server at all. The entitlement, the patching, the certificates, the internet exposure and the hybrid plumbing are all costs you can stop paying.

For smaller estates a cutover migration to Exchange Online moves every mailbox in one pass, typically over a weekend. For larger ones, or where you need staged moves and shared free/busy while people cross over, a hybrid migration from your own Exchange Server is the safer shape. Public folders are their own project, planned as a separate public folder migration rather than assumed into the mailbox batches.

Then finish the job. The last server has to be properly decommissioned — uninstalled through the supported procedure, not powered off — so no stale server objects, connectors or service connection point records are left in Active Directory. One caveat before you promise the board a server-free estate: if you still synchronise identities from on-premises Active Directory, check Microsoft's current recipient management guidance for your configuration before you assume the last box can go.

Exchange Web Services is the older SOAP interface that applications have used to read and write mailbox data for the better part of two decades. Microsoft stopped adding features to it in 2018 and told developers to move to Microsoft Graph. The retirement now landing applies to Exchange Online only; EWS in Exchange Server on-premises is not part of it.

The mechanics matter more than the headline. From 1 October 2026 EWS requests to Exchange Online are blocked unless the tenant has explicitly set EwsEnabled to true and configured an allow list of Microsoft Entra application IDs. Tenants that have never touched the setting — where it is still blank — will have it changed to false as the rollout reaches them. The allow list is a transition mechanism, not a reprieve: it applies to direct EWS connections only, not to Graph or REST, and on 1 April 2027 EWS access is removed permanently and the list stops meaning anything.

What tends to be on the list when clients go looking: line-of-business applications that file mail into a system of record, CRM connectors, backup and archiving agents, signature and disclaimer tools, room booking systems, scan-to-mail and fax gateways, and a long tail of scripts built on the EWS Managed API. Vendors have had years of notice, but the fixed version is often a major release nobody budgeted for.

Microsoft Graph is the replacement, and for anything you maintain yourself the rewrite is per application rather than a global find-and-replace: not every EWS operation has a one-to-one Graph equivalent, and permissions are modelled differently. If that work needs hands, it is what our Microsoft Graph API integration service does. One hybrid note: per Microsoft's guidance at the time of writing, the shared service principal that hybrid used for EWS was blocked in October 2025, and hybrid organisations are expected to move to the dedicated Exchange hybrid application with its Graph-based permission model.

While you have the inventory open, add basic authentication for SMTP AUTH client submission. Microsoft's published timeline leaves it unchanged through December 2026, then disables it by default for existing tenants at the end of December 2026 — administrators can still re-enable it, and new tenants created afterwards will not have it at all. The final removal date is to be announced in the second half of 2027.

That is the same hunt as the EWS one: every printer, scanner, alarm panel, backup job and small application that sends mail through Microsoft 365 with a username and password. Do both inventories in one pass, from message trace and sign-in logs rather than from memory. If you would rather hand that to someone, our Exchange Online Administrator on Demand service is bought by the hour for exactly this kind of work.

Inventory first, and on paper. Every Exchange server with its version, cumulative update and last security update. Every application, appliance and script that touches a mailbox, with the vendor contact and the protocol it uses.

Then decide stay or leave once, for the organisation, rather than server by server. Regulated data residency, an air-gapped site or an application that must have a local mailbox is a reason to stay. Habit is not.

If you are staying, settle the licensing position first, because it determines whether SE is available to you at all, then run the in-place upgrades from 2019 or start building SE servers if you are on 2016. If you are leaving, book the migration and the decommission in the same plan, so the servers actually come out instead of lingering as an unpatched attack surface.

Run the tenant-side work in parallel either way — the EWS allow list and the Graph plan, the SMTP AUTH inventory — because none of it depends on what you decide about the servers. And if nothing can move before 31 October 2026, write down a containment position instead of drifting into one: the last published update installed, Extended Protection enabled with its prerequisites checked, the admin panel off the public internet, and a dated plan for leaving that state. Containment is a bridge with a written end, not a destination.