Skip to content
Pro IT NW

Field notes · 15 min read ·

Share

Exchange 'ESU expired'? There's no Exchange ESU — here's the real deadline

There is no ESU program for Exchange Server. Exchange 2016/2019 lost all support — including paid support — on October 14, 2025. The next hard wall is Exchange SE CU2 (expected H2 2026), which blocks coexistence with legacy Exchange.

If you've landed here searching "Exchange 2019 ESU expired" or "Exchange ESU April 2026," start with the correction: there is no Extended Security Updates (ESU) program for Exchange Server. ESU is a Windows / Windows Server / SQL Server program — Exchange was never on the list. What actually happened is simpler and harder: Exchange Server 2016 and 2019 reached end of support on October 14, 2025, and there is no paid bridge to extend them. We covered the runway in Exchange Server 2019 EOL: your real migration deadline; this post is what to do now that support is gone.

If your organization is still running Exchange Server 2016 or 2019 in 2026 — either as a full mailbox server or as the hybrid recipient-management box that Exchange Online migrations left behind — you are operating unsupported infrastructure that handles email. And the risk isn't only the CVE everyone fixates on. After 30 years of running Exchange, the failures that actually take a business down are: no Microsoft support case to open when mailflow breaks, mailflow-disaster scenarios with no vendor backstop, and third-party integrations (backup, archiving, signatures, security gateways, scan-to-email, line-of-business apps) that progressively drop support for the unsupported version and break on their timeline, not yours — a pattern that repeats every Exchange EOL cycle. This post lays out the four exit paths, the hours each one takes for 50–1,500-seat shops, and the cost of staying. The deadline that should drive your timeline is Exchange SE CU2's coexistence block, expected H2 2026.

What actually expired — and the ESU myth

Here's the correction, because many teams have this wrong: there is no Extended Security Updates (ESU) program for Exchange Server. ESU is a paid bridge for Windows 10, Windows Server, and SQL Server — not Exchange. Nothing called "Exchange ESU" expired in April 2026, because it never existed. What expired was support itself, on October 14, 2025. If you've been trying to figure out how to buy Exchange ESU to extend 2016/2019, stop — there is nothing to buy. The dates that actually matter:

MilestoneDateWhat it means
Exchange 2016 / 2019 end of support Oct 14, 2025 No more security updates, bug fixes, time-zone updates, or technical support. This is the real cliff.
ESU program for Exchange? Does not exist ESU covers Windows 10, Windows Server, and SQL Server only. There is no paid bridge for Exchange.
Exchange SE available 2025 The supported replacement; in-place upgrade from 2019 CU14/CU15, legacy upgrade from 2016.
Exchange SE CU2 coexistence block expected H2 2026 SE CU2 Setup blocks coexistence with out-of-support Exchange. Migrate side-by-side before it ships.
Client-side EWS retirement (Outlook / third-party) Oct 2026 Outlook for Mac, Outlook mobile, and third-party apps must move to Microsoft Graph. Separate timeline.

Exchange 2016 and 2019 binaries still install and run. SetupAssist works. The Information Store starts, the Transport service routes mail, OWA renders. The product hasn't been removed from existence — it has been removed from the patch train. Every CVE published against Exchange after October 14, 2025 is permanent in your environment unless and until you move off the version.

The functional state today: on-prem Exchange 2016/2019 is now in the same lifecycle bucket as Windows Server 2012 R2 post-ESU and Exchange 2010 post-2020. It runs. It is not supported. Microsoft Support will not open a case on it. Cyber insurance underwriters are asking about it on renewal questionnaires. CISA tracks new exploits in the KEV catalog as they're observed in the wild.

Why hybrid Exchange shops are hit harder than full on-prem

The mid-market population still running on-prem Exchange in May 2026 splits roughly into two camps. The first is the handful of shops who never moved mailboxes to the cloud at all — typically for regulatory, sovereign-data, or latency reasons. The second, much larger camp is shops who moved every mailbox to Exchange Online years ago but kept one on-prem Exchange server around for recipient management. The second camp is hit harder than the first. Here's why.

The "we only kept it for recipient management" pattern

For a decade, Microsoft's official guidance for hybrid Exchange was: if you have any AD-synced mail-enabled users, keep at least one on-prem Exchange server for Set-RemoteMailbox, Set-DistributionGroup, and recipient attribute writes that AD-sync pushed into Entra ID. Most mid-market hybrid migrations from 2017–2023 ended in exactly that state — Exchange Online for mailboxes, one tiny Exchange 2016 or 2019 server running on a Hyper-V host in the comm room for recipient management, patched quarterly by the IT team. That server was an Exchange server with all the attendant CVE surface, just with one mailbox database and no end-user mail flow.

The end-of-support cliff applies to that server identically. The fact that it holds no real mailboxes does not exempt it. The Information Store, the EWS endpoint, the IIS Exchange application pool, the Transport service, the management shell — all the components that have been exploited in past CVEs — are running on it.

What stops working when the hybrid server is unpatched

Nothing visibly. That is the trap. The Exchange Hybrid Configuration Wizard runs against the unpatched server with no error. Set-RemoteMailbox completes. Mail flow works. AD-attribute sync via Entra Connect keeps running. The user experience is unchanged. What is changing is the CVE surface: every Exchange CVE published since October 14, 2025 — and every one published until the day you decommission that server — is unpatched in your environment, with no path to patch it.

The EWS retirement adds a second timer

Separate from the end-of-support cliff, Microsoft is retiring client-side Exchange Web Services (EWS) on October 1, 2026 per the published Microsoft Learn Exchange updates page. That timeline is targeted at client apps (Outlook for Mac, Outlook mobile, third-party EWS integrations) moving to Microsoft Graph, not server-to-server hybrid free/busy. But it does mean any third-party application in your environment using EWS against Exchange Online (signature managers, archive products, journaling, mail-flow scanners) needs a Graph migration plan in parallel with the on-prem decommission. Two clocks, not one.

The four real exit paths

Four paths from where you are today. The right one depends on whether you have mailboxes on-prem, whether you have a regulatory or operational reason to stay on-prem, and how much of the migration work has already been done.

Path A — Exchange Subscription Edition in-place upgrade

Stay on-prem. Upgrade from Exchange 2019 CU14+ to Exchange Subscription Edition. Same deployment model, new licensing. Microsoft shipped Exchange Server SE in 2025 — the announcement is on the Exchange Team blog and the lifecycle entry is on the Microsoft Lifecycle page.

What changed under the hood between Exchange 2019 and Exchange SE is small — Microsoft has been explicit that the code base is the same family, the upgrade is an in-place CU-style install, and existing Exchange 2019 hardware that meets the spec can carry forward. What changed in the commercial model is the licensing: per-mailbox-per-year subscription, no perpetual Server + CAL pricing, software-only delivery. Pricing is set by your Microsoft EA, CSP, or MPSA terms and shifts with quantity bands and contract cycle — work the current quote through your licensing partner rather than budgeting from a list price that may already be stale. Windows Server licensing for the host is separate and unchanged.

When this is right: sovereign-data or regulatory constraints that prohibit cloud mailbox storage, latency or bandwidth realities that make Exchange Online impractical, or a 3+ year depreciation schedule on existing on-prem hardware that makes a cloud cutover financially painful right now. For the still-on-prem-by-choice shops, this is the supported path.

Hours for a 50–500-seat single-server upgrade: 60–120 hours of senior labor. That covers prerequisite validation (the host has to be on Server 2019 or 2022, CU14+, .NET in spec), schema prep, the in-place setup, certificate re-binding, internal/external URL validation, hybrid configuration wizard re-run if hybrid, and post-upgrade smoke testing including mail flow, OWA, ActiveSync, and EWS. Add hardware refresh time if the host is older than Server 2019. Multi-server DAG environments scale up roughly linearly per node.

Modern Lifecycle, no fixed EOL: Exchange SE sits on Microsoft's Modern Lifecycle policy. There is no fixed end-of-support date the way 2016 and 2019 had. As long as you stay on a supported CU (typically the current and previous), the product remains in support indefinitely. The trade is the subscription — you are paying every year, forever, instead of every 5–7 years for a CAL refresh.

Path B — Full Exchange Online cutover and hybrid decommission

Move any remaining on-prem mailboxes to Exchange Online. Decommission the on-prem Exchange server entirely. Use cloud-only recipient management — Set-Mailbox, Set-MailUser, and New-DistributionGroup via Exchange Online PowerShell, or the Microsoft 365 admin center, or the Exchange admin center in the cloud. The Microsoft Learn decommission guide covers the supported sequence.

When this is right: this is the answer for the large majority of mid-market shops in May 2026. If your mailboxes are already in Exchange Online and the only thing left on-prem is the recipient-management server, the decommission is mostly a matter of doing the work that the original hybrid project deferred. If you still have some mailboxes on-prem, the migration plus decom is one combined project. The labor is straightforward; the failure modes are well-documented.

Hours for a 50–500-seat full cutover plus decom: 80–160 hours of senior labor. Discovery (mailbox inventory, public folder status, third-party EWS integrations, transport rules, journaling, signature management, archive products), pilot migration, full cutover for any remaining on-prem mailboxes, public folder migration to Microsoft 365 Groups or retirement, hybrid configuration wizard reversal, Exchange uninstall from each node, Entra Connect attribute writeback configuration if needed, post-decom validation. The 1,500-seat band runs 160–280 hours depending on public folder load and third-party integration count.

Path C — Hybrid Modern Auth bridge to cloud-only recipient management

A newer option that's underappreciated. Microsoft published the Manage hybrid Exchange recipients with management tools guidance starting in 2023. The pattern: install the Exchange Management Tools (the PowerShell module) on a domain-joined member server — no Exchange Server installation, just the management tools — and use them against Exchange Online to write recipient attributes that AD-sync back to on-prem AD. No hybrid Exchange server retained for recipient management.

The version of this most mid-market shops will land on uses cloud-only recipient management through the Exchange Online admin center plus EXO PowerShell for bulk operations, with the Exchange Management Tools as a fallback for the handful of advanced AD-side scenarios that still need them. The on-prem Exchange server goes away; AD-attribute sync continues to flow through Entra Connect; recipient management happens cloud-side; the CVE surface drops to zero.

When this is right: mailboxes already 100% in Exchange Online, hybrid Exchange server retained only for recipient management, no on-prem mailbox migration remaining. The smallest, fastest, lowest-risk path of the four.

Hours for a 50–500-seat HMA bridge plus decom: 40–80 hours of senior labor. Cloud-only recipient management validation, Exchange Management Tools install on a clean member server if needed, hybrid configuration wizard reversal, Exchange Server uninstall, certificate cleanup, AD attribute validation, post-decom audit. The 1,500-seat band runs 60–120 hours.

Path D — Migrate to Exchange Online, keep Entra Connect for AD sync only

The fully-cloud destination. Mailboxes in Exchange Online, no Exchange Server anywhere on-prem, no Exchange Management Tools, no hybrid configuration. AD on-prem is retained for desktop authentication and file-share access; Entra Connect syncs identities from AD to Entra ID; mail attribute management happens entirely in Exchange Online.

This is Path B's destination plus a layer of hygiene work — pruning legacy Exchange attributes from AD that no longer need to round-trip, validating that no application still depends on on-prem Exchange anything (signature managers, journaling, archive, mail filters, line-of-business apps that send via on-prem SMTP relays), and standing up cloud-native replacements for any of those that need them. For shops that want the on-prem Exchange chapter genuinely closed, this is the destination.

When this is right: when leadership has signed off that on-prem Exchange is over, no regulatory reason to retain it, willingness to do the application-side hygiene work in parallel with the decom.

Hours for a 50–500-seat full migration plus full decom plus hygiene: 100–200 hours of senior labor. All of Path B plus the application-side hygiene (third-party EWS migration to Graph, on-prem SMTP relay replacement with Exchange Online direct send or high-volume email service, journaling and archive product cloud cutover, signature manager cloud version), plus DR planning for the cloud-only state (tenant-restore strategy, mailbox retention policy, backup vendor decision, Entra Connect resilience). The 1,500-seat band runs 200–360 hours.

Summary table

PathEnd state50–500 seats (hrs)500–1,500 seats (hrs)Right for
A — Exchange SE upgrade On-prem Exchange, subscription-licensed 60–120 120–240 Regulatory / sovereign-data / hardware-depreciation constraints
B — EXO cutover + hybrid decom Mailboxes in EXO, no on-prem Exchange 80–160 160–280 Most mid-market shops in May 2026
C — HMA bridge to cloud-only mgmt Mailboxes already in EXO, mgmt cloud-only 40–80 60–120 Hybrid-for-mgmt shops with mailboxes already migrated
D — Full EXO + AD-sync only No Exchange anywhere on-prem 100–200 200–360 Shops that want the on-prem Exchange chapter closed

Hour and cost ranges by seat band

Fixed-fee labor ranges by seat band, senior-led, USA-delivered:

SeatsPath A (SE)Path B (EXO + decom)Path C (HMA bridge)Path D (full EXO)
50 $12K–$22K $15K–$28K $8K–$15K $20K–$35K
200 $18K–$32K $22K–$45K $12K–$22K $32K–$55K
500 $25K–$45K $32K–$60K $18K–$32K $45K–$75K
1,500 $45K–$75K $55K–$95K $28K–$50K $75K–$135K

These are labor-only ranges. They do not include Microsoft licensing (Exchange Online plan, Exchange SE subscription, Entra ID P1/P2 if needed for Conditional Access on the migration path), hardware refresh if you take Path A on aged iron, or third-party migration tools if you choose to use them for very large mailbox moves. We don't resell any of that — the client procures directly.

What happens if you stay on Exchange 2019 after end of support

Beyond the operational risks above — no paid support, mailflow disasters, third-party decay — the security exposure compounds. Three more, in order of how soon they start hurting.

CVE exposure accumulates. The Hafnium-class Exchange vulnerabilities of 2021 — ProxyShell (CVE-2021-34473 et al.), ProxyLogon (CVE-2021-26855 et al.) — had patches. The Microsoft Security Response Center shipped fixes, customers who applied them within hours were largely fine, customers who didn't were not. The Exchange CVEs that arrive after October 14, 2025 will not have patches for 2016 or 2019. There is no MSRC fix path. The exploit hits the wild, proof-of-concept code lands on GitHub within days, and your unpatched server is part of the addressable target population until you take it off the network.

Cyber insurance underwriters are watching. The renewal questionnaire most underwriters are now running explicitly asks whether the insured runs on-prem Exchange Server, what version, and whether it is currently in support. The honest answer ("yes, 2019, out of support since October 14, 2025") raises premium, lowers limits, increases retention, or causes the carrier to walk. The audit isn't theoretical — large-claim ransomware events in 2022–2024 had post-mortem findings that named unpatched Exchange as the entry vector, and the underwriters learned from them.

CISA and ransomware actors are watching too. Exchange vulnerabilities are added to the CISA Known Exploited Vulnerabilities (KEV) catalog with high frequency — the catalog tracks vulnerabilities being actively exploited in the wild, and Exchange CVEs have been a recurring entry since 2021. Ransomware affiliate groups explicitly prioritize unpatched Exchange targets in their initial-access scanning. The longer you stay on 2019 after end of support, the larger the gap between your patch level and the public exploit set, and the more likely a routine internet-scan picks you up.

The honest read: running out-of-support Exchange 2019 is not a "we'll get to it next quarter" risk — it's a "we are accumulating a security debt that compounds weekly and that our insurer knows about" risk. Treat the decision the same way you'd treat running Windows Server 2012 R2 unpatched in 2026.

Common mistakes we're seeing in May 2026

Buying Exchange SE without realizing it's a subscription, not a perpetual license

The Exchange SE licensing model is genuinely different from Server + CAL. There is no perpetual license. You pay per-mailbox-per-year, every year, for the life of the deployment. Shops budgeting Exchange SE as a one-time capex line item are budgeting wrong. The right line is operating expense, modeled out for the 5–10 year horizon you actually plan to keep the server. Run that math against Path B or Path D's one-time labor cost plus the Exchange Online subscription you're almost certainly already paying for inside your Microsoft 365 plan, and Path B/D usually wins on TCO.

Keeping the hybrid server "just for recipient management" past end of support

The hybrid recipient-management pattern was right guidance for years. It is not right guidance now. Cloud-only recipient management is supported, documented, and adequate for the workload. Keeping the hybrid server alive past end of support to avoid a 40–80 hour decommission project is trading low-effort one-time work for indefinite CVE exposure. The math does not pencil out.

Decommissioning the hybrid server before Entra Connect attributes are validated

The on-prem AD has Exchange-specific attributes — proxyAddresses, mailNickname, msExchRecipientTypeDetails, msExchRemoteRecipientType, and a long tail of others — that AD-sync writes into Entra ID. Some of those are required for mail routing; some are vestigial. Before the Exchange uninstall, validate which attributes are still being written, by what, and where their authoritative source is. Microsoft published guidance in the decommission article, and it's worth reading end-to-end before any uninstall.bat gets typed. Shops that skip the attribute audit end up with broken mail routing post-decom and spend more time fixing it than the audit would have taken.

Cutting over the migration without DR planning for the cloud-only state

When the on-prem Exchange is gone, your DR posture changes. There is no more on-prem mailbox-database backup; restore semantics are different in Exchange Online; the retention policy you had in Veeam or whichever on-prem backup product does not have a direct equivalent in EXO. Plan the cloud-side DR before the cutover, not after. Microsoft's native retention and litigation hold capabilities cover much of it; tenant-restore products fill specific gaps; the right answer depends on regulatory exposure and recovery objective. Don't decommission first and figure out DR later.

Thinking cloud-only recipient management is more painful than it is

Cloud-only recipient management has a reputation among hybrid-era admins for being half-finished. That reputation was accurate in 2018–2021 and is dated now. The Exchange Online admin center, EXO PowerShell, and the Microsoft 365 admin center together cover the recipient-management workload that the on-prem Exchange Management Shell used to handle. The handful of advanced scenarios that still need on-prem tools — certain msExch* attribute writes for specific edge cases — are covered by the Exchange Management Tools installed on a member server, no Exchange Server required. The workflow change is real but small; the muscle memory transfer takes a couple of weeks for the IT team and stops being a friction after that.

Pricing transparency

Fixed-fee labor ranges, restated as the line items most often quoted in May 2026 engagements:

  • Exchange SE upgrade discovery — $5K–$10K. Read-only assessment of the existing 2019 environment, CU level, hardware, certificate state, and hybrid configuration. Output is a go/no-go on the in-place upgrade plus a detailed task list. Standalone engagement.
  • Hybrid Exchange decom project (100–500 seats) — $15K–$35K. Recipient-management hybrid server retired, attributes validated, Exchange uninstalled, Entra Connect reconfigured if needed, post-decom audit. Path C or the decom portion of Path B.
  • Full EXO migration + hybrid decom (100–500 seats) — $25K–$60K. Discovery, pilot, cutover for any remaining on-prem mailboxes, public folder handling, third-party integration migration, hybrid uninstall, hypercare. Path B or D.
  • Larger seat bands (500–1,500) — scaled from the 50–500 band ranges in the table above.

Labor-only. No resale margin on Microsoft licensing, Cloud PC, or third-party migration tools. The fixed-fee structure exists because mid-market buyers are correctly skeptical of T&M scopes on infrastructure work, and because the discovery phase exists to turn assumptions into facts before the implementation phase commits.

Related reading

Sources and further reading

The 30-second version

Exchange 2016 and 2019 lost all support on October 14, 2025 — and there is no ESU program for Exchange to buy more time. Every week since is accumulating CVE exposure with no patch path. Four exit options: Exchange Subscription Edition in-place upgrade (60–120 hrs, for on-prem-by-necessity shops), Exchange Online cutover plus hybrid decommission (80–160 hrs, the right answer for most), Hybrid Modern Auth bridge to cloud-only recipient management (40–80 hrs, smallest path if mailboxes are already in EXO), or full Exchange Online plus Entra-Connect-only on-prem AD (100–200 hrs, the cleanest destination). Cyber insurance underwriters and CISA are both watching unpatched Exchange. The right time to start was last quarter; the second-best time is this week.

If you'd like a senior engineer to walk through your environment and scope the right path, the project intake form takes about three minutes and you'll get scope plus a fixed-fee range inside two business days.


Pro IT NW does senior-led Microsoft project work. Vendor-neutral. Labor-only. Based in Seattle, delivered USA-wide. We don't take resale margins on Microsoft licensing, Exchange Subscription Edition, or third-party migration tooling — we recommend the right configuration and you procure directly.

Written by the team at Pro IT NW · Senior-led Microsoft project consultancy · Seattle / USA-wide.

Have a project on the runway?

Tell us the workload, the seat count, and the deadline. We'll come back inside two business days with scope and a fixed-fee range.