Exchange ESU Period 1 expired — your real deadline

If you've landed here searching "Exchange 2019 ESU expired" or "Exchange ESU April 2026," start with what actually expired: Period 1 of the paid Exchange Server ESU program ended April 14, 2026. Microsoft does offer a last-resort, security-updates-only ESU program for Exchange 2016 and 2019 — but it is a short bridge, not a long-term lever. Mainstream support ended October 14, 2025, ESU then ran in two six-month periods, and Period 2 ends at the end of October 2026 with no further extension. After that there are no security updates at any price. We covered the runway in Exchange Server 2019 EOL: your real migration deadline; this post is what to do now that the bridge is nearly 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 the one that actually has a date on it — ESU Period 2 ending in October 2026. Exchange SE's CU2 coexistence block is the second pressure, and it still has no announced date, which is a reason to be early rather than a reason to wait.

What actually expired — and the ESU bridge that's almost gone

Here's the correction, because many teams have this half-wrong: there is a paid Extended Security Updates (ESU) program for Exchange Server 2016 and 2019 — but it is a costly, last-resort, security-only bridge that is now nearly used up. Mainstream support ended October 14, 2025. ESU then ran in two six-month periods: Period 1 ended April 14, 2026 (that's what "expired"), and Period 2 ends at the end of October 2026, which Microsoft has confirmed is final. ESU ships only Critical/Important security fixes — no bug fixes, no technical support, no new features — and is bought per server through a Microsoft account team, not self-serve. If your plan was to lean on ESU for another budget cycle, recalibrate: the bridge closes in October 2026. The dates that actually matter:

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 — and through ESU Period 2 (ending October 2026) Microsoft still ships Critical/Important security fixes to enrolled, per-server-licensed builds. But the moment that bridge closes, every new CVE published against Exchange 2016/2019 is permanent in your environment unless and until you move off the version — and ESU is a paid, last-resort stopgap, not a destination.

Two months of ESU left, and no release date for Exchange SE CU1

Two facts changed the shape of this decision in August 2026, and they pull in opposite directions. Read them together, because taken one at a time they suggest opposite actions.

The paid bridge is nearly out, and there is no Period 3. Microsoft structured Exchange Server ESU as two six-month periods after the October 14, 2025 end of support and has stated there will be no further extension once Period 2 closes at the end of October 2026. There is no third period to buy. From the middle of August, that is roughly two months of coverage remaining — and only for organizations that enrolled in Period 2 and keep their servers on a serviced build. This is the part teams most often mis-file. October 2026 is not a renewal line for next year's budget; it is the date by which the estate has to be running something else.

The destination's first cumulative update has no date. Exchange Server SE reached general availability in 2025, but its first cumulative update, CU1, has slipped again and Microsoft has not published a replacement date. Microsoft returned to the subject in mid-August 2026. The explanation reported is that the team is prioritizing the monthly security releases and validating an increased volume of AI-discovered vulnerabilities, with CU1 being rebuilt continuously against those fixes. One caveat on sourcing, because it matters for how much weight to put on the wording: the Exchange Team blog renders its article bodies client-side and returns nothing readable to our tooling, so we are working from Petri's August 17, 2026 report rather than paraphrasing a page nobody here has opened. Treat any specific CU1 release date quoted elsewhere as unsourced.

The resolution, because the two facts get combined into the wrong conclusion. An absent CU1 date is not a reason to wait for CU1. What an in-place upgrade lands on is SE RTM, which has been available since 2025 — and SE RTM is one of the builds Microsoft shipped the August 2026 Exchange security updates for. Exchange SE sits on the Modern Lifecycle policy with no fixed end-of-support date; Exchange 2016 and 2019 have a hard October deadline with an enrollment gate in front of the updates that remain before it. Holding an unsupported server past October to wait for a cumulative update that has no announced date is the worst available sequence, and it is a sequence several teams are talking themselves into right now.

What CU1's absence does change is how much planning weight the SE servicing calendar can carry. If your project plan had a milestone that read "upgrade after CU1 ships," that milestone no longer has a date behind it and needs to be re-cut against the October ESU date instead. The same caution applies to the CU2 coexistence block, which will eventually stop SE Setup from coexisting with out-of-support Exchange and also has no announced date — you cannot schedule around a date Microsoft has not set, so schedule around the one it has. And before you land on SE, it is worth knowing what the subscription model commits your team to operationally, which is a separate post: landing on SE is not the finish line, staying current on it is the ongoing cost.

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

The mid-market population still running on-prem Exchange 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: unless you have paid into ESU, every Exchange CVE published since October 14, 2025 is unpatched on that box — and once ESU Period 2 closes in October 2026, even the paid patch path is gone for every CVE published after it, right up until the day you decommission the server.

And the "it's only a management server" argument is one Microsoft has now closed itself. In the August 11, 2026 release post it states that Exchange Online is already protected but the security update still needs to be installed on your Exchange servers "even if they are used only for management purposes" — the vendor, unprompted, naming the exact box this section describes. The August updates shipped for Exchange Server SE RTM, Exchange Server 2019 CU14 and CU15, and Exchange Server 2016 CU23. A management-only server that is Period 2-enrolled and on one of those builds has a patch to install; one that is neither has an exposure it cannot close.

The EWS retirement is the third clock — and it points at Exchange SE

Read the scope first, because this is the part most often reported wrongly. Microsoft's Exchange Team states that "Today's announcement and the retirement of EWS apply only to Microsoft 365 and Exchange Online (all environments); there are no changes to EWS in Exchange Server." Nothing about EWS on your on-premises servers is being switched off, and nothing in this retirement gives the on-prem estate a new deadline. What is being retired is EWS as a way of calling into Exchange Online.

That still lands on a hybrid organization, and it lands squarely on the version question. In the same post the Exchange Team states that "only Exchange SE will support Graph for calls to Exchange Online, so hybrid customers will have to use Exchange SE to host on-premises mailboxes." Set that beside the ESU clock and the squeeze is plain: paid coverage on the 2016 or 2019 server ends in October 2026, and the on-premises version you run is also what decides whether hybrid calls into Exchange Online have a supported path once EWS is gone. Those two arguments used to be made separately, to different people, and each one was individually deferrable. Together they are not.

The tenant-side work is a genuinely separate job with its own, much shorter deadline — the EWSEnabled property, the allow list, the end-of-September 2026 window that exempts a tenant from the October 1, 2026 automatic change, and two similarly named controls that administrators are currently confusing with one another. We have written that up in our EWS retirement write-up, and the underlying post is the Exchange Team's "Exchange Online EWS, Your Time is Almost Up"; Microsoft Learn carries the timeline in Deprecation of Exchange Web Services in Exchange Online. One thing worth carrying over from the on-prem side of the house: the scope widened once already, after the January 2024 Midnight Blizzard incident, "from third party applications to include all Microsoft applications." So it is not a vendor's problem you hand off and forget. Inventory every application calling EWS against Exchange Online — signature managers, archive products, journaling, mail-flow scanners, line-of-business apps — and give each one a Graph migration date; Microsoft ships EWS Usage Reports in the admin center and an EWS Analyzer tool for exactly that inventory.

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.

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. 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, EWS integrations (Microsoft and third-party), 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 (EWS migration to Graph for Microsoft and third-party apps, 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

Hour and cost ranges by seat band

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

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. For Exchange CVEs that arrive after October 14, 2025, the only MSRC fix path is the paid ESU program — and only its Critical/Important fixes, only for enrolled servers, and only through the end of ESU Period 2 in October 2026. After that there is no fix path at any price. 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.

Common mistakes we're seeing

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 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.

Update — September 2026: the last baseline that patching can meet

On September 2, 2026 the Exchange Team announced a change to the throttling and blocking of mail from on-premises Exchange servers into Exchange Online, and it turns the argument in this post from a support question into a mail-flow one. Verbatim: "starting in the second week of September 2026, we will raise the oldest allowed version for Exchange 2016 or Exchange 2019 servers that connect to Exchange Online over an inbound connector type of OnPremises to at least the last available public update version, released in October 2025." By the time you read this, that is either imminent or already in effect.

Raising a baseline is not new — Microsoft notes it has been doing it periodically, and says "so far, these changes have been implemented silently." This one was announced, and the reason it was announced is the sentence after it.

Read that against the rest of this post. Everything above frames ESU Period 2 and Exchange SE as a support decision — whether you keep receiving security updates. Microsoft has now attached a second, harder consequence to the same fork: at the next baseline raise, a server that is neither ESU-enrolled nor upgraded to Exchange SE stops being able to deliver mail into Exchange Online over that connector. Not "runs unsupported." Stops delivering. For a hybrid organization, that is the difference between a risk you are carrying and a business interruption with a date attached.

The scope is narrower than the headline, and the narrowness matters

Microsoft is specific about what is covered, and it is worth checking your own connectors before assuming you are affected. The change:

• "Applies to servers that connect to Exchange Online over an inbound connector type of OnPremises."
• "DOES NOT apply to servers that send email to Exchange Online in other ways (different types of connectors etc.)"
• "DOES NOT (currently) apply to 'all servers in your organization', but only to servers that connect to Exchange Online over an inbound connector type of OnPremises." — and Microsoft adds, "This might change in the future."

So the first question is not "what version are we on" but "how does our on-premises Exchange actually hand mail to Exchange Online." A shop relaying through a third-party gateway, or using a connector of a different type, is outside today's scope. A standard hybrid deployment is inside it.

What we would check this week

1. Identify your inbound connector type. This decides whether the change reaches you at all, and it takes minutes.
2. Establish your build number against the October 2025 public update. Microsoft names that release as the new floor rather than a KB number in the announcement, so compare against your own update history.
3. Decide the ESU-or-SE question now rather than at the next raise. That is the whole point of the announcement, and "several months" is Microsoft's own estimate, not a commitment.
4. Know where the pause control is before you need it. Microsoft links guidance on how to pause throttling and blocking for out-of-date servers. It is a breathing-space mechanism, not a fix, and it is better located calmly than during an incident.

Microsoft closes the announcement with a point worth repeating to anyone treating the baseline as a target: "the fact that the 'oldest version to avoid throttling and blocking in Exchange Online' is always older than the latest version available does not mean that we consider versions older than the latest security update 'safe to use'." The baseline is the floor for mail delivery. It is not a statement about your risk.

Update — September 2026: the September update, and the cycle Period 2 has left

Microsoft shipped the September 8, 2026 Exchange Server 2019 CU14 security update, KB5121610, and its own update article restates the Period 2 gate: “Organizations that are enrolled in the Period 2 Extended Security Update (ESU) program are eligible to receive released security updates until the end of October 2026. To continue receiving the latest security updates, organizations not enrolled in the ESU program should migrate to Exchange Server Subscription Edition (SE).”

Set beside the Period 2 mechanics above, that sentence puts a specific shape on what remains of the bridge: with the September cycle now out, on our reading, the October 2026 update cycle is the last one that falls inside the Period 2 window as Microsoft has described it. Plan the move to Exchange Server SE around that cycle rather than around a later date Microsoft has not published. This does not change what the rest of this post says about Exchange SE CU1 — there is still no announced release date for it, and nothing in the September update changes that.

Update — September 2026: what Period 2 actually is, and the sentence that governs eligibility

The ESU bridge described above has a shape worth spelling out, because several of its terms surprise people who assume ESU works like a subscription that rolls. The governing sentence is this:

“Only customers who enrolled in the Period 2 Extended Security Update (ESU) program are eligible to receive Exchange Server 2016 and 2019 security updates released between May and October 2026.”

Four things about Period 2 that are not obvious.

• It is a separate contract, and nobody is enrolled automatically. Period 1 enrolment does not carry forward. If you bought Period 1 and did nothing since, you are not in Period 2.
• You can buy Period 2 without having bought Period 1 — you simply do not receive the Period 1 packages. Because Exchange updates are cumulative, the earlier fixes still arrive inside the later ones.
• It runs from the start of May 2026 to the end of October 2026 — six months, with no further extensions. It covers Exchange 2016 CU23 and 2019 CU14/CU15. It requires an Enterprise Agreement and is purchased through your Microsoft account team, which means per-server pricing is quoted rather than published.
• Microsoft does not commit to releasing any security updates during Period 2. You are buying eligibility to receive updates if they ship, not a guarantee that they will.

That last point is the one to carry into a budget conversation. ESU is insurance on a window that closes at the end of October 2026 regardless of what you spend, and the enrolment instructions changed — any purchase from April 15, 2026 onward is Period 2 and comes with a new ESU User Guide, so the steps your team wrote down during Period 1 no longer apply.

Related reading

• The second, undated pressure on the same servers: Exchange Server SE: the CU2 coexistence deadline.
• The tenant-side EWS job, with a much shorter deadline: EWS retirement: the opt-out now runs to end of September.
• What landing on SE commits your team to afterwards: Exchange Server SE: what modern servicing commits you to.
• The companion decision tree: Exchange Server 2019 EOL: your real migration deadline.
• If this migration also involves a tenant consolidation: Tenant-to-tenant M365 migration playbook.
• Service detail: Microsoft 365 Migration service.
• Service detail: Exchange Hybrid Decommission service.
• Service hub: All services.

Sources and further reading

• Exchange 2016/2019: Throttling and Blocking up to the Final Public Update Baseline, the Exchange Team, September 2, 2026. Source for the September 2026 update above: the second-week-of-September timing, the October 2025 floor, the connector scope, and Microsoft's statement that the next raise will be met only by ESU-enrolled or Exchange SE servers. The administrator reports of blocking on compliant versions come from the comment thread on that post and are identified as such.
• Microsoft Learn — Exchange Server build numbers and release dates (shows ESU-delivered Security Updates)
• Microsoft Lifecycle — Exchange Server 2019
• Microsoft Tech Community — Exchange Team blog (Exchange SE RTM/GA posts)
• Microsoft Learn — Decommission on-premises Exchange Server
• Microsoft Learn — Manage hybrid Exchange recipients with management tools
• Microsoft Learn — Modern Lifecycle Policy (covers Exchange SE)
• Microsoft Learn — Deprecation of Exchange Web Services in Exchange Online (the October 2026 / April 2027 timeline and the widened scope)
• Microsoft Exchange Team Blog — Released: August 2026 Exchange Server Security Updates (the Period 2 enrollment gate and the hybrid management-server requirement)
• Microsoft Exchange Team Blog — Exchange Online EWS, Your Time is Almost Up (Exchange Online scope, and the Exchange SE requirement for hybrid Graph calls)
• Petri, August 17, 2026 — reporting on the Exchange Server SE CU1 delay. Microsoft's own post on the delay is on the Exchange Team blog, which renders article bodies client-side; we have relied on this reporting rather than paraphrase a page we could not retrieve.

The 30-second version

Exchange 2016 and 2019 lost mainstream support on October 14, 2025. The paid ESU program buys a little more time — but Period 1 already expired (April 14, 2026) and Period 2 ends in October 2026 with no Period 3 behind it, so it's a last-resort bridge, not a plan, and roughly two months of it are left. Meanwhile Exchange SE's first cumulative update, CU1, has slipped again with no replacement date — which is not a reason to wait, because SE RTM is available now, has no fixed end-of-support date, and received the August 2026 security updates. If you're hybrid, add a third pressure: per Microsoft's Exchange Team, only Exchange SE will support Graph for calls to Exchange Online, so the on-premises version also decides whether hybrid keeps a supported 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. And as of September 2026 there is a fourth pressure that is not about support at all: Microsoft is raising the version floor for on-premises servers that deliver mail into Exchange Online over an OnPremises connector, and states that the next raise after this one will be met only by servers that are ESU-enrolled or already on Exchange SE. That turns the same decision into a mail-delivery one. 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.

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.