Somebody on your team ran Get-ExchangeServer | Format-List Name, AdminDisplayVersion a few weeks back, saw Version 15.1 (Build 2507.x), and closed the window without saying anything. That’s Exchange Server 2016. It left support on October 14, 2025, same day as Exchange Server 2019.
Mail kept flowing that day and every day since, which is why nobody escalated.
If you bought Extended Security Updates you’ve been getting patches anyway, and the whole thing has felt like a problem for later. Later has a date on it now.
The date that matters is the end of October 2026
Microsoft’s Exchange team split the ESU program for Exchange 2016 and 2019 into two paid periods. Period 1 started in October 2025 and ended at the end of April 2026. Period 2 was announced on April 15, 2026, runs from May 2026 through the end of October 2026, and arrived with a sentence worth forwarding to your leadership: there would be no further extensions of the program after that.
So this isn’t a rolling arrangement you keep renewing. From November 2026, Exchange 2016 and Exchange 2019 stop receiving security updates, and every vulnerability disclosed after that stays open on your servers permanently.
You’re reading this in August. That’s roughly ten weeks.
Period 1 enrolment didn’t roll into Period 2
Check this today, because a lot of teams assume it did.
Period 2 was sold as a standalone contract rather than a continuation. Organizations already enrolled in Period 1 had to re-purchase to receive Period 2 updates, and nobody was migrated across automatically. Any ESU bought on or after the April 15 announcement lands in Period 2 by default.
“We bought ESU” and “we’re currently receiving updates” are two different statements. Go find out which one is true.
Two upgrade methods, and Microsoft’s names for them matter
The confusion here comes from invented hybrid terminology. There are exactly two documented methods and they’re mutually exclusive.
A legacy upgrade means adding the newer server to the organization, migrating all mailboxes and resources onto it, then uninstalling the previous servers. Microsoft calls this out as necessary when moving from Exchange 2016 to 2019 or to SE, and also when you’re switching to new hardware or a newer version of Windows Server.
An in-place upgrade means installing Exchange Server SE over an existing Exchange 2019 installation, much the way you’d apply a cumulative update. Microsoft supports it from Exchange Server 2019 CU14 or CU15.
That CU14-or-CU15 detail matters more than it looks. The very latest CU is not a prerequisite, and assuming it is sends teams into a patching project they may not need. CUs are cumulative, so there’s no ladder to climb either. You aren’t applying CU14 and then CU15 in sequence.
In-place upgrade: what it actually needs
If you’re on Exchange 2019 CU14 or CU15, this is a maintenance window, not a migration. Microsoft describes SE RTM as code equivalent to Exchange 2019 CU15 apart from the licence agreement file shown in GUI setup, the product name, and the build number. There isn’t much new code to be surprised by, and new features don’t arrive until SE CU1.
Nice detail people miss: SE RTM doesn’t require a new product key. Your existing key keeps working through either upgrade method. Microsoft has said a future cumulative update will introduce a product key requirement, so file that under things to revisit rather than things to solve now.
What stops these upgrades is almost never Exchange SE. Here’s what we check first, roughly in order of how often each one halts a project.
Certificates. Exchange environments accumulate them: the one on transport, the one on the front end, the internal one somebody generated in a hurry three years ago. An upgrade is a bad time to discover that a binding half your clients depend on expired last month, and that the alert was suppressed in a monitoring rule which also predates everyone currently on the team.
Third-party transport agents. Archiving products, signature managers, mail hygiene tools, DLP agents. They hook the transport pipeline, they’re version-pinned against Exchange, and they’ll block or corrupt an upgrade when the pinning is wrong. Get the vendor’s Exchange SE compatibility statement in writing first. A forum post from a stranger running the same product isn’t a compatibility statement.
Antivirus exclusions. Microsoft publishes an Exchange-specific exclusion list covering folders, processes, and file extensions. Environments that quietly lost those exclusions during an EDR rollout see database and log problems under load, and an upgrade is exactly the kind of load that surfaces them. Verify the exclusions still exist on every server instead of assuming they survived the last endpoint tooling change.
Exchange 2013 still in the org. SE RTM setup flatly prevents coexistence with it. If there’s a 2013 server sitting there, even one nobody’s logged into since 2019, you’re removing it before SE goes anywhere.
A restore nobody has tested. Not a setup prerequisite. A prerequisite for sleeping. Run a real restore into an isolated environment before you touch production, because a backup’s entire value is whether the restore works, and you find that out exactly once.
Every one of these is discoverable in an afternoon, which is the argument for doing the discovery this week rather than in October.
Legacy upgrade: new servers, then mailbox moves
On Exchange 2016, in-place isn’t available. You’ve got two supported routes: a legacy upgrade to Exchange 2019 CU14 or CU15 and then in-place to SE, or a legacy upgrade straight to Exchange Server SE. The second is one migration instead of two, and for most 2016 shops it’s the obvious call.
Mechanically it’s the coexistence migration Exchange admins have been running since the 2010 era. Namespace planning, certificates, batch moves, public folders if you still have them, and a decommission checklist somebody actually follows so you’re not left with a dead server holding an AD object nobody will delete.
It’s also the honest answer for plenty of Exchange 2019 shops that could technically upgrade in place. Hardware at end of lease, a host OS that was on the replacement list anyway, or an environment that’s drifted far enough you don’t trust an in-place run. Microsoft names new hardware and a newer Windows Server version as legacy-upgrade triggers for exactly this reason. Watch the coexistence window though. Every week running two Exchange environments is a week with two sets of certificates, two sets of URLs, and two places a mail flow problem can start.
Exchange Online
For a lot of small and mid-sized organizations this was the right answer before any of these dates existed.
The reasons to stay on premises are real, but they’re specific: data residency requirements your legal team can point at, regulatory constraints that name a jurisdiction, applications depending on on-premises Exchange behavior you can’t rework economically, mailbox and archive sizes that make service pricing ugly, or a heavily restricted network. If none of those describe you, you’re maintaining an Exchange server because you’ve always maintained an Exchange server.
What costs money here is rarely the mailbox move. It’s the long tail: the line-of-business app relaying through an anonymous receive connector, the scanner on the third floor, the nightly job on basic auth, the shared mailbox permissions someone configured by hand in 2017 and never wrote down. That tail is the whole difference between a four-week migration and a four-month one, and it’s what the inventory below is for.
Side by side
| Path | Best when | Main constraint |
|---|---|---|
| In-place upgrade to Exchange SE | On Exchange 2019 CU14 or CU15, hardware and OS still fine, staying on premises | Prerequisites rather than effort. Existing product key still works |
| Legacy upgrade to Exchange SE | On Exchange 2016, or on 2019 with hardware or Windows Server due for replacement | Server capacity plus a coexistence window |
| Exchange Online | No hard residency constraint, mailbox sizes and compliance fit the service | Reworking everything that depends on on-prem behavior |
We’d add one thing the table can’t show. The effort gap between these paths is smaller than whoever’s selling you each one wants you to believe, and it’s almost never what decides the answer. What decides it is whether you’re allowed to keep the data somewhere else, and whether the applications hanging off Exchange survive the move.
SE CU2 is the next cliff, and it’s already documented
Worth knowing before you build a plan around a long coexistence window.
SE RTM setup already blocks coexistence with Exchange 2013. Microsoft has documented that SE CU2 setup will go further and prohibit coexistence with any Exchange version that isn’t supported at the time of release. Design a comfortable multi-month migration with an unsupported server parked in the org, and a future CU closes that door on you.
This one gets misreported a lot, usually as a specific dated CU2 deadline nobody can source. There’s no published date. There is a published behavior, and it’s enough to plan around: don’t design a migration that depends on leaving unsupported Exchange servers in the org indefinitely.
What to inventory this week
Identical for all three paths, so it’s never wasted work.
Builds. Every Exchange server, its version, its CU, its last security update, checked against Microsoft’s build number table. This one list tells you whether the in-place path is open to you.
Which ESU period you hold. Period 1 or Period 2, and whether the Period 2 updates are actually installed. Enrolled-and-unpatched is common, and it’s the worst of both.
Anything that authenticates to Exchange. Applications, appliances, scanners, service accounts, scripts, and the auth method for each. Anything on basic auth is a migration blocker and a security finding in its own right. Mail relay belongs on the same sheet: receive connectors, allowed IPs, and what sits behind them. That part is always longer than the team expects.
Public folders. Whether you have them, whether anyone still uses them, and who’s allowed to decide to retire them. They’re the most common reason an otherwise clean Exchange migration slips.
Mailbox sizes and retention. Total volume, largest mailboxes, archive configuration, legal holds. This is what makes the Exchange Online comparison real instead of theoretical.
Sequencing against a hard October date
Ten weeks is plenty for an in-place upgrade. It’s tight but workable for a legacy upgrade in a mid-sized org. It isn’t enough for a full Exchange Online migration with a messy long tail, and pretending otherwise is how people end up running unpatched servers in November.
Which is why the inventory comes first and comes this week. The sequence changes depending on what it finds. On 2019 CU14 or CU15 with clean prerequisites, you’re one maintenance window from supported and the rest of this article stops applying to you. On 2016 with public folders and forty things relaying mail, decide now between a legacy upgrade to SE (achievable) and Exchange Online (probably not by October), and if it’s Exchange Online, budget for Period 2 running out mid-migration and plan the compensating controls rather than discovering the gap in November.
The one sequencing mistake to avoid is waiting for the decision before starting discovery. Discovery is what makes the decision, and it’s the part with the longest lead time.
Where an outside team helps
An Exchange migration isn’t hard. It’s a project with a hundred small dependencies, and the failures come from the ones nobody wrote down.
Outside help earns its keep on the inventory and the runbook, where pattern recognition across other environments does the work. Your team knows your environment better than any consultant will inside a month, so pair them rather than handing the whole thing over.
Don’t outsource the decision itself. Choosing between on-premises Exchange SE and Exchange Online is a business call about where your data lives and what your obligations are, and a vendor whose revenue depends on the answer is the wrong person to make it. That includes us. Our modernization team scopes the assessment and hands the runbook to your staff to execute, and we’d rather do that than end up owning your mail platform.
Run the build inventory this week. It takes an afternoon, and it tells you whether you have a ten-week problem or a one-weekend one.