Exchange Server SE: the CU2 coexistence deadline after 2019 end-of-life

If you are still running Exchange Server 2016 or 2019 in mid-2026, the most important date is already behind you: support ended October 14, 2025. No more security updates, no bug fixes, no time-zone updates, and — the part teams underestimate — no technical support of any kind. There is no paid escalation case to open when something breaks.

The next date that matters is the one nobody has on the calendar yet: the release of Exchange Server SE Cumulative Update 2 (CU2). CU2 Setup will block coexistence with any Exchange version that's out of support when it ships — which now means 2016 and 2019. That single change closes the last clean window to migrate side-by-side. This post explains why that window matters more than the CVE headlines, and what a senior operator actually does about it this quarter.

First, kill the ESU myth

The single most common misconception we hear from IT directors right now: "We'll just buy Exchange ESU and deal with it next budget year." There is no such thing.

The Extended Security Updates program — the paid bridge that lets you keep getting critical patches past end of support — exists for Windows 10, Windows Server, and SQL Server only. Exchange Server is not on that list and never has been. The confusion is understandable: many shops bought Windows Server 2012 R2 ESU or are buying Windows 10 ESU right now, and they assume the same lever exists for Exchange. It does not.

That means October 14, 2025 was a hard wall for Exchange in a way it was not for Windows. Your Exchange 2016/2019 servers keep running, but Microsoft has stopped producing anything for them: no security fixes for the next transport-layer vulnerability, no bug fixes, no time-zone data, and no support contract you can invoke when a queue backs up at 2 a.m.

What end of support actually costs you (it's not the CVE)

Security teams frame EOL Exchange as "a vulnerability you might catch." That's real, but after 30 years of running Exchange in production, it's not what takes a business down. Here's the operational reality, in the order it bites.

1. No Microsoft lifeline

On a supported product, when mailflow breaks in a way you can't diagnose, you open a paid Microsoft support case and escalate. On an out-of-support product, you can't even buy that case. The escalation path is gone. Whatever is wrong, you and your team own it alone — at whatever hour it surfaces, with whatever depth of Exchange transport knowledge you happen to have on staff. For most mid-market teams that knowledge lives in one or two heads, and those heads go on vacation.

2. Mailflow disaster scenarios

EOL Exchange is exactly where transport, queue, and hybrid-mailflow problems turn into multi-day outages. A certificate expiry on the hybrid connector, a poison message wedging the transport queues, a TLS negotiation change on the other side of your send connector, a database that won't mount after a patch you applied to the underlying Windows Server — each of these is recoverable on a supported product with vendor backing. On an unsupported product, each one is a coin flip against your own tribal knowledge, with no backstop and no fix coming. Email is the one system where "down for a day" means the whole company stops.

3. Third-party ecosystem decay

This is the slow killer, and it's the one every operator who has lived through an Exchange EOL cycle recognizes immediately. Your Exchange server is never alone. It's wired into:

• Backup and recovery agents that hook the Information Store
• Archiving / journaling platforms with version-specific connectors
• Email signature and disclaimer engines that run as transport agents
• Mail-hygiene / security gateways and inbound/outbound filtering
• Fax and scan-to-email from MFPs and line-of-business appliances
• Line-of-business integrations — ERP, ticketing, CRM, anything that relays through Exchange

Every one of those vendors maintains a support matrix. As Exchange 2016/2019 ages out, those vendors progressively drop the unsupported version — and eventually a routine agent update, a new appliance firmware, or a TLS change simply stops working against your box. It happens unpredictably, expensively, and on the vendor's timeline, not yours. This pattern repeats every single Exchange EOL cycle. Teams that have been through one know it's a "when," not an "if."

Put those three together and the picture is clear: staying put isn't holding steady, it's degrading. The environment gets less supportable every month you don't move — and the migration gets harder, not easier, because of the deadline in the next section.

The destination: Exchange Server SE

Exchange Server Subscription Edition (SE) is the supported continuation of on-premises Exchange. SE RTM is available now and is code-equivalent to Exchange Server 2019 CU15 — effectively a cumulative upgrade to 2019, not a re-architecture. It moves you to the modern subscription model and keeps you supported into the mid-2030s, with cumulative updates on Exchange's usual cadence of roughly one to two per year.

If you have a real reason to keep mail on-premises — regulatory requirements, a mandate that data not sit in a foreign datacenter, unique settings the cloud can't meet, or because you still manage cloud mailboxes via Active Directory and Entra Connect — SE is the destination. (If you migrate mailboxes to Exchange Online but keep Entra Connect managing accounts in AD, you still need at least one Exchange server for recipient management; that server should be SE, not a dead 2016/2019 box.)

Two upgrade paths to SE

A few hard constraints that catch people:

• In-place is 2019-only. In-place upgrades from anything earlier than Exchange 2019 — including Exchange 2016 — are not supported. From 2016 you do a legacy upgrade.
• If you're on 2019 but behind on CUs, you must first get to CU14 or CU15 before the in-place upgrade is available. Plan that CU step into the timeline.
• From Exchange 2013 (if you still have any), you must legacy-upgrade to 2019 CU14 and fully remove 2013 first — SE RTM Setup already blocks coexistence with 2013.
• Exchange 2016 coexistence with SE requires Exchange 2016 to be on its final cumulative update (CU23) across all 2016 servers, including any Edge Transport servers — and only until CU2 (next section).

The CU2 coexistence block — the closing window

Here is the deadline almost nobody has internalized. Two changes are reshaping how SE coexists with older Exchange:

1. SE RTM Setup already prevents coexistence with Exchange Server 2013.
2. SE CU2 Setup will prevent coexistence with any Exchange version that is not supported at the time CU2 releases — which now means Exchange 2016 and 2019, both already out of support since October 14, 2025.

Translate that into operational terms:

Microsoft has not published a firm CU2 release date, and we won't invent one. Exchange ships roughly one to two CUs per year, so CU2 is best planned as expected in the second half of 2026 — the next CU after the current SE train. The point isn't the exact date; it's the direction. The clean, side-by-side migration path is open today and will close. The longer you wait, the more likely your legacy box has to be completely gone before you can even land on a current SE build — which means a harder, more compressed cutover with less room to fall back.

What a senior operator does this quarter

Concrete runbook, in order. None of this requires a big-bang project — it requires starting before the window narrows.

1. Inventory the org honestly. Every Exchange server, its version and exact CU level, every Edge Transport server, the hybrid configuration state, public folder topology, and the full list of third-party agents and integrations touching transport and the Information Store. Most environments don't have this written down accurately — and that gap is where every blown Exchange migration starts.
2. Pick your path per the table above. On 2019 CU14/CU15 with adequate hardware? In-place is your low-risk route. On 2016, on old hardware, or wanting to move to newer Windows Server? Legacy upgrade — add SE, migrate, decommission.
3. Get current-enough to coexist. If you're on 2019 behind CU14, schedule the CU step now. If you're on 2016, confirm every 2016 server (including Edge) is on CU23 before you introduce SE.
4. Stand up SE and establish coexistence — before CU2. This is the time-sensitive step. Add the SE server to the organization while RTM-era coexistence with 2016/2019 is still permitted.
5. Migrate mailboxes, public folders, and resources off the legacy servers onto SE (or to Exchange Online, if that's the destination). Validate mailflow, hybrid connectors, autodiscover, and every third-party integration against the new server.
6. Fully decommission the legacy servers the supported way — don't just power them off. Clean removal from the org is what lets you then install or patch to SE CU2 without Setup blocking you.
7. Land on a current SE build and set a CU cadence. SE gets one to two CUs a year; bake patching into your operational calendar so you never drift out of the supported window again.

The sequencing matters: steps 4 and 5 are the ones that get materially harder once CU2 ships. Do them while coexistence is still on the table. If you want a senior engineer to validate the path and run the cutover, start a project — two-business-day response with scope and a fixed-fee range.

Common mistakes we're seeing right now

Assuming Exchange has an ESU bridge

Covered above, worth repeating because it drives bad planning: there is no Exchange ESU. If your roadmap budgets "Exchange ESU year 1," delete that line and replace it with the migration. The bridge does not exist.

Powering off old servers instead of decommissioning them

Turning off a legacy Exchange server is not the same as removing it from the organization. Leftover org objects, connectors, and AD artifacts will block SE CU2 Setup and create support headaches. Decommission the supported way, not the lazy way.

Discovering third-party support gaps mid-cutover

Inventory your backup, archiving, signature, security, and scan-to-email vendors' support matrices before you cut over, not after a transport agent stops loading on the new server. If a vendor doesn't support SE yet, you need to know in week 1.

Treating "it still runs" as "it's fine"

Out-of-support Exchange runs right up until the day it doesn't, and the day it doesn't is the day you discover there's no one to call. "It still runs" is the most expensive sentence in IT operations.

Related reading

• The countdown framing for email infrastructure: Exchange 2019 EOL: your last six months.
• The ESU misconception, in depth: Exchange "ESU" expired April 2026 — what now.
• Parallel decision tree for collaboration infrastructure: SharePoint Server 2019 EOL July 2026: three paths.
• If your move is M&A-driven and surfaces tenant consolidation: Tenant-to-tenant M365 migration playbook.
• Pillar hub: Microsoft 365 & Hybrid Exchange.

Sources and further reading

• Microsoft Learn — Upgrading to Exchange Server Subscription Edition (SE)
• Microsoft Learn — Exchange Server 2019 and 2016 end of support roadmap
• Microsoft Learn — Lifecycle FAQ: Extended Security Updates (ESU)
• Microsoft Learn — Exchange Server system requirements

Where to start

If you're still on Exchange 2016 or 2019: the date you already missed (October 14, 2025) cost you support. The date you can still beat (SE CU2, expected H2 2026) is the one that keeps your migration clean. Inventory this week, pick your path, and establish SE coexistence before CU2 closes the side-by-side door.

A senior engineer can walk the whole path with you — version-and-CU assessment, in-place vs. legacy decision, coexistence setup, mailbox cutover, and supported decommission. The project intake form takes about three minutes, and you'll get a scope and a fixed-fee range back within two business days. See the Hybrid Exchange decommission service for what that engagement looks like.

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 Exchange, SE licensing, or any of the destinations in this post.