Skip to content
Pro IT NW

Field notes · 10 min read ·

Share

Exchange Server 2019 EOL: your real migration deadline

Exchange 2016/2019 went out of support October 14, 2025 — no patches, no support, and no ESU program for Exchange. The next hard wall is Exchange SE CU2 (expected H2 2026), which blocks coexistence with legacy Exchange.

If your organization is still running Exchange Server 2016 or 2019 in 2026, start with the fact most teams get wrong: mainstream end-of-support hit on October 14, 2025, and — unlike Windows or SQL Server — there is no Extended Security Updates (ESU) program for Exchange to buy you a paid bridge. Your servers still run, but Microsoft has stopped producing security fixes, bug fixes, and technical support for them. There is no "we'll just buy ESU next budget year." It does not exist for Exchange.

So the real question isn't "how long can we keep patching" — it's "how cleanly can we migrate, and before what deadline." The deadline that actually bites is Exchange Server SE Cumulative Update 2 (CU2), expected in the second half of 2026: its Setup blocks coexistence with any out-of-support Exchange version, which now means 2016 and 2019. After CU2 ships, you can't stand up a new Exchange server next to your legacy box and migrate gradually — the old server has to be fully gone first. We break that down in the CU2 coexistence deadline.

This post is the plain-English decision tree we walk every client through right now. It assumes you're an IT director, CIO, or CFO who needs to make a decision this quarter, not a deep-dive on Exchange administration.

Where we actually are right now

The dates that matter, in one table:

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 date has passed.
ESU program for Exchange? None There is no ESU for Exchange Server. ESU covers Windows 10, Windows Server, and SQL Server only.
Exchange Server SE available 2025 The supported on-prem destination. 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 (2016/2019). Migrate side-by-side before it ships.

There are exactly four paths from here. We'll walk each one with the math, the timeline, and the most common way each one fails.

Path 1: Full cloud — Exchange Online

Move every mailbox to Exchange Online. Decom the on-prem Exchange server entirely. Manage recipients via Entra ID (or a tiny Exchange Management server if you have hybrid attribute requirements).

This is the right answer for most mid-market companies. The license you're already paying for in your Microsoft 365 plan covers Exchange Online. The operations cost of running on-prem Exchange — patching, backup, hardware, the email-flow tribal knowledge — is a tax most organizations would happily stop paying.

Realistic timeline: 6–14 weeks for a typical 100–500 mailbox environment. Discovery (1–2 weeks), pilot migration (1–2 weeks), full cutover (4–10 weeks depending on mailbox sizes and bandwidth), hypercare (2 weeks). Add 4–6 weeks if the on-prem environment has public folders, complex mail rules, or a third-party signature/archive product.

Where this fails: people forget that "moving mailboxes" isn't the whole job. Public folders need to be migrated or retired. Mail-enabled distribution groups need attention. Service accounts and application relay configurations almost always have undocumented Exchange dependencies that surface mid-cutover. The actual decommission of the on-prem Exchange server is its own project — and it's the one most organizations skip. Three years later, that Exchange server is still running because nobody finished the job.

Path 2: Exchange Server Subscription Edition (Exchange SE)

Microsoft shipped Exchange Server Subscription Edition in 2025. It's an in-place upgrade from Exchange 2019 CU14 or CU15, and a legacy (migrate-and-decommission) upgrade from Exchange 2016. Same on-prem deployment model, new licensing — subscription-based instead of perpetual.

Why might you choose this? You have a real reason to keep mail on-premises:

  • Air-gapped or sovereign-cloud requirements (some defense, intelligence, healthcare)
  • Regulatory restrictions that prohibit cloud email storage in your jurisdiction
  • Latency or bandwidth realities that make cloud impractical (rare, but real)
  • Existing investment in on-prem infrastructure with a depreciation schedule that doesn't end for 3+ years
Reality check: if you're considering Exchange SE because "we've always done it this way," that's not a reason — that's an inertia. Run the numbers honestly. The license + operations + opportunity cost of on-prem Exchange almost always loses to Exchange Online unless you have one of the constraints above.

Realistic timeline: 4–8 weeks for the upgrade itself, assuming you're already on 2019 CU15. Add prep work to get there if you're on an earlier CU or on 2016. Plan for Cumulative Updates every 4–6 months in perpetuity.

Path 3: Hybrid coexistence — keep Exchange for recipient management only

A historical workaround. Exchange-mailboxes in the cloud (Exchange Online), with one tiny on-prem Exchange server kept around to manage recipient attributes that AD synced into Entra ID. This was Microsoft's recommendation for years.

It's not anymore. As of recent guidance, you can manage Exchange recipient attributes directly in Entra ID without an on-prem Exchange server. The hybrid recipient management server is no longer necessary, and keeping it around extends your patching and operations burden for no benefit.

If you're in this state today: the right move is to decommission the on-prem Exchange recipient management server entirely and move recipient management to Entra ID. We've documented the process on the Exchange Hybrid Decommission service page.

Path 4: Defer with risk acceptance

Continue running Exchange 2016 or 2019 with no patch path of any kind — out of support since October 14, 2025. No security updates. No support. Your cybersecurity insurance carrier will almost certainly raise your premium or deny renewal. Your auditors will write you up. Your security team will, correctly, treat the unpatched Exchange box as a critical risk.

This is not a recommendation. It's listed only because some organizations end up here through inaction. If you're reading this and you don't have a plan for Path 1, 2, or 3 in motion by July 2026, you've effectively chosen Path 4.

The decision tree, simplified

Your situationRight path
Mailboxes already in Exchange Online, on-prem Exchange just for recipient mgmt Path 3 (decommission recipient-mgmt box)
Most mailboxes still on-prem, no regulatory constraint blocking cloud Path 1 (full cloud)
Hard regulatory or sovereign-cloud requirement to keep mail on-prem Path 2 (Exchange SE)
"We have time" / "We'll figure it out later" Re-read this post. You don't have time.

What we recommend doing this week

Independent of which path is right for you, three things should happen in the next two weeks:

  1. Inventory. Confirm Exchange version, CU level, mailbox count, public folder status, third-party integrations (signature management, archive, journaling, mail filtering). Most organizations don't have an accurate inventory and that's the source of every blown migration.
  2. Decision committee. Identify who has to sign off — typically IT director, CIO, CFO, security/compliance lead, and any LOB application owner with an Exchange dependency. Get them on a call. Walk the four paths. Pick one.
  3. Engage scope. Whether you're doing the work in-house or with a consultancy, get a written scope on paper with a timeline, a budget, and acceptance criteria. The cost of Path 1 with discovery, pilot, cutover, and hypercare runs $25K–$75K for a typical 100–500 mailbox environment. The cost of Path 4 is everything that breaks after Oct 14, 2026.

Common mistakes we see right now

Skipping the decommission

You moved every mailbox to Exchange Online in 2021. Great. But there's still an on-prem Exchange server running, because "we might need it for something." That server is the EOL liability. Decommissioning Exchange takes its own project and its own runbook. If nobody's planning the decom, the migration isn't done.

Underestimating public folders

Public folders are the single most common source of timeline slippage in Exchange migrations. They're old, they're often huge, the permission model is convoluted, and they have application dependencies nobody documented. Plan for them explicitly — migrate to Microsoft 365 Groups, retire entirely, or consciously keep on-prem with a documented exception.

Assuming an Exchange ESU bridge exists

The most common planning error we hear: "we'll buy Exchange ESU and deal with it next year." There is no Extended Security Updates program for Exchange Server — that lever exists for Windows and SQL Server, not Exchange. If your roadmap has an "Exchange ESU" line on it, delete it and replace it with the migration. There is no buy-time option.

Doing nothing because the budget is in next fiscal year

The cost of an emergency Exchange migration in November 2026 — when your security team is escalating to the board and your insurance carrier is on the phone — is materially higher than the cost of a planned migration in summer 2026. Bring the conversation forward.

Related reading

Sources and further reading

The 30-second version

Exchange 2016/2019 already stopped getting security updates and support on October 14, 2025, and there is no ESU program for Exchange to buy more time. The right destination for most companies is Exchange Online with a full hybrid decommission; on-prem-by-necessity shops move to Exchange Server SE. Either way, the clean side-by-side migration window closes when SE CU2 ships (expected H2 2026). Inventory this week, decide next week, scope by end of month.

If you'd like a senior engineer to walk through it with you, the project intake form takes about three minutes and you'll get scope and a fixed-fee range inside two business days. No discovery call required to start.


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 any of the recommendations in this post.

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.