On October 14, 2025, Exchange Server 2016 reached the end of extended support. So did Exchange 2019, on the same day, which made that date the single largest end-of-support event in Exchange history: every version of on-premises Exchange older than the new Subscription Edition went unsupported at once.
If you are running Exchange 2016 today, you are in the first year past the deadline. That is meaningfully different from the position of a 2010 or 2013 holdout. The gap between you and safety is still small, your server is still healthy enough for every migration method to work well, and nothing catastrophic has necessarily happened yet. This is the cheap moment to act, and this article covers exactly what changed, what to watch for, and how to get out cleanly.
What changed on October 14, 2025
Your server did not stop working, and nothing about that date was a shutdown. What ended was Microsoft's obligation to keep the product safe:
- No more security updates. Any vulnerability discovered in Exchange 2016 from that day forward will remain unpatched forever. Microsoft has occasionally made rare exceptions for truly extraordinary situations in the past, but no one should run a mail server on the hope of an exception.
- No more bug fixes or time zone updates. The last cumulative update was the last, full stop.
- No technical support. Microsoft will not open cases on Exchange 2016.
The reason this matters so much for Exchange in particular is track record. On-premises Exchange has been one of the most aggressively attacked server products of the past five years. The ProxyLogon and ProxyShell classes of vulnerabilities were exploited at mass scale in 2021, with automated scanning compromising exposed servers worldwide within days of disclosure. Supported servers got emergency patches. That is the safety net you just lost.
The first year: what actually gets risky, and when
Risk after end of support is not a cliff, it is a slope, and it is worth being precise about the shape of it:
- Months 0 to 12 (you are here). Exposure grows with each vulnerability disclosed for the shared Exchange codebase. Attackers routinely test whether fixes for supported versions point to flaws in unsupported ones, because they know those will never be patched.
- Insurance renewals. The first policy renewal after the deadline is where many organizations feel it first. Cyber insurance applications ask specifically about end-of-life software, and your answer changed in October 2025.
- Compliance reviews. Frameworks that require supported, patched software (and most do, in some form) now flag your mail platform automatically.
- The ecosystem moves on. Outlook releases, mobile OS updates, and security tools are all built and tested against supported servers. Compatibility does not break on a schedule; it erodes.
The practical takeaway: the best migration outcomes come from moving while the server is still healthy and the pressure is still low. Migrations executed during an incident, under an insurer's deadline, or after a hardware failure cost more and go worse.
Your realistic paths off Exchange 2016
Path 1: Hybrid migration to Exchange Online (the default answer)
Exchange 2016 is recent enough to do this properly. A hybrid configuration connects your on-premises organization to Microsoft 365 as one system: shared address book, secure mail flow between the two, and mailbox moves that happen in the background. Users keep working during their move and simply restart Outlook when it completes. For most organizations this is the smoothest migration Exchange has ever offered:
- Mailboxes move in scheduled batches, pilot group first, so problems surface on ten mailboxes instead of two hundred.
- Mail flow never breaks: messages route correctly to every mailbox throughout the project, wherever it currently lives.
- Passwords carry over through directory synchronization, so cutover day involves no password resets.
- For smaller environments, the same plumbing can run in a minimal or express mode: use hybrid just long enough to move everyone in one pass, then retire it.
The one discipline hybrid demands is finishing. The old server must be decommissioned (or reduced to a small management role while every mailbox lives in the cloud) at the end. An unsupported hybrid server left publishing itself to the internet has all the risk this migration was meant to remove.
Path 2: Third-party migration tooling
Migration platforms that copy data directly to Microsoft 365 remain a strong option, particularly when the 2016 server has health problems, when you are consolidating several mail systems into one tenant, or when you want the old environment kept entirely at arm's length from the new one. They trade hybrid's seamless coexistence for independence from the old server's condition.
Path 3: Exchange Server Subscription Edition on-premises
If a genuine regulatory or data-residency requirement keeps mail on your hardware, the supported on-premises product is Exchange Server Subscription Edition (SE), which is licensed by subscription rather than a one-time purchase. Exchange 2016 cannot upgrade to SE in place; the path runs through Exchange 2019 first, then an in-place upgrade to SE, or a fresh SE build with mailboxes moved across. It is a real project with ongoing costs, and you keep owning patching, backups, certificates, and hardware forever. Choose it for mandates, not inertia.
What is not on the list
Migrating to Exchange 2019 as a destination. It went out of support the same day you did. Any 2019 hop is a stepping stone to SE, never an endpoint. And "wait and see" is not a path; it is just Path 1 later, at higher risk and usually higher cost.
Comparing the options
| Path | Best fit | User disruption | What you own afterward |
|---|---|---|---|
| Hybrid to Exchange Online | Most organizations, any size | Minimal: batched background moves | Nothing: Microsoft runs the platform |
| Express/minimal hybrid | Smaller orgs, one-pass move | One scheduled switch | Nothing after decommission |
| Third-party tooling | Unhealthy servers, consolidations | One scheduled switch | Nothing after decommission |
| Exchange Server SE | Hard data-residency mandates | Low, but a long project | The entire server estate, on subscription |
How a specialist runs a 2016-to-cloud move
A 2016 migration is the most standard move in our catalog, which is precisely why the difference between a smooth one and a rough one is preparation rather than heroics:
- Discovery first. Mailboxes, shared mailboxes, public folders, distribution groups, mail-connected devices and applications, mobile fleet, and mailbox sizes. The inventory drives the licensing plan and the batch schedule, and it always finds something the org chart forgot.
- Identity groundwork. Directory synchronization set up and validated, attribute problems cleaned before they can break provisioning.
- Pilot before bulk. A pilot batch that includes a normal user, a heavy calendar user, and someone with delegate access, because that trio finds most issues.
- Batches sized to your bandwidth and Microsoft's throttling, with delta syncs keeping each batch current until its cutover moment.
- A real finish. MX and Autodiscover moved, devices reconfigured, the old server properly decommissioned, and modern security (MFA, sensible mail hygiene defaults) enabled in the new tenant. If you want ongoing management of Microsoft 365 after that, we do that too.
If your version differs, we have written the same guidance for Exchange 2019, which shares your deadline, and for the older Exchange 2013 and Exchange 2010, whose owners can tell you what year three past a deadline feels like. The broader risk case is in The Real Risks of Running Unsupported Exchange, and every route we run is on the migration paths page.
You are one year past end of support. That is late enough to act and early enough for it to be easy. The window where both things are true does not stay open.
Move while it's still the easy version of this project
Tell us your mailbox count and setup, and we will return a fixed-price hybrid migration plan with dates, free and without obligation.
Plan My Migration