The deadline that changes the conversation has already passed. On October 14, 2025, Microsoft ended support for both Exchange Server 2016 and Exchange Server 2019. If your organization still runs email on either, you are now operating unsupported infrastructure: no more security patches, bug fixes, or technical support from Microsoft. The server still turns on and mail still flows, which is exactly what makes it dangerous. On-premises Exchange has been one of the most heavily attacked pieces of enterprise software of the last five years, and an unpatched one is a standing invitation.
Looking past on-premises Exchange is no longer a strategic preference to schedule for someday. It is a decision the calendar has already made for you. The only open questions are where your email goes next and how cleanly you get there. This guide lays out the three real options in 2026, the security reality that makes delay the worst choice, and why for most organizations the smartest move is to stop running email infrastructure in-house at all.
What Actually Happened in October 2025
End of support is a specific, hard line, not a gentle nudge. After October 14, 2025, Microsoft no longer provides security fixes for newly discovered vulnerabilities, bug fixes for stability or usability issues, time-zone updates, or technical support for Exchange Server 2016 and 2019. Microsoft’s own guidance is blunt: migrate as soon as possible.
The reason this matters so much more for Exchange than for most end-of-life software is the threat history. Exchange is a mail server that sits at the edge of your network, authenticates users, and holds the keys to identity. That combination has made it a prime target, and attackers have repeatedly turned Exchange flaws into full network compromise. Running a version that will never be patched again, in a product class that attackers actively hunt, is a risk that compounds every single day the server stays online.
Your Three Options Now
There are exactly three supported paths forward. Choosing well starts with being honest about why you were on-premises in the first place.
1. Exchange Online / Microsoft 365
Microsoft’s recommended and simplest destination is Exchange Online as part of Microsoft 365. You stop buying, patching, cooling, and upgrading mail servers entirely. You get larger, resilient mailboxes, built-in anti-spam and anti-malware, data-loss prevention, retention and eDiscovery, and tight integration with Teams, SharePoint, and OneDrive, always on the latest version. The one real consideration is data residency: your mail lives in Microsoft’s cloud, which some regulated or sovereignty-bound organizations cannot accept without careful review.
2. Exchange Server Subscription Edition (SE)
For organizations that genuinely must keep email on-premises, Microsoft released Exchange Server Subscription Edition on July 1, 2025. It is now the only supported on-premises version of Exchange. Two things changed with it. First, licensing is subscription-based: you need server licenses and client access licenses with active Software Assurance, or cloud subscription licenses. The perpetual, buy-it-once model is gone. Second, it follows the Modern Lifecycle Policy, meaning it is evergreen with no year-numbered versions, as long as you stay current with the roughly twice-yearly updates. Exchange 2019 upgrades to SE in place; Exchange 2016 requires a side-by-side migration, and that has its own deadline before a later SE update removes the legacy path.
3. Hybrid, and the trap inside it
Hybrid deployments move mailboxes to the cloud while keeping a foot on-premises, which is a reasonable transition state. But there is a trap worth knowing before you assume hybrid lets you fully escape. If you migrate mailboxes to Microsoft 365 but keep Entra Connect synchronizing your on-premises Active Directory, Microsoft requires you to keep at least one Exchange server on-premises for recipient management. In other words, a partial migration can leave you owning, patching, and securing an Exchange box indefinitely, which undercuts much of the reason you moved. Half-measures here carry ongoing cost and risk.
| Path | Best for | The trade-off |
|---|---|---|
| Exchange Online / M365 | Most organizations; simplest exit | Mail lives in Microsoft’s cloud (residency review) |
| Exchange Server SE | Must-stay-on-prem, regulated data | You still own hardware, patching, and a subscription |
| Hybrid | Transition state, phased migration | May force keeping one Exchange server indefinitely |
| Do nothing | No one | Unsupported, unpatched, actively targeted |
Why Staying Put Is the One Unacceptable Choice
The security case against running unsupported on-premises Exchange is not theoretical. It is the most consistently exploited product in recent enterprise memory.
In 2021, the ProxyLogon vulnerability (CVE-2021-26855) and its chained partners drove a global mass-exploitation campaign against on-premises Exchange, serious enough that CISA issued an emergency directive ordering federal agencies to act. ProxyShell and ProxyNotShell followed. These were not obscure bugs; they were internet-wide events that compromised tens of thousands of servers and, because Exchange sits next to Active Directory, frequently led to full network takeover.
And it has not stopped. In August 2025, a new hybrid-Exchange vulnerability, CVE-2025-53786, prompted CISA to issue Emergency Directive ED-25-02, because a shared service principal between on-premises Exchange and Exchange Online could let an attacker escalate quietly from the on-premises server into the cloud tenant. The pattern is unmistakable: Exchange remains a front-line target, and the attacks keep coming. A server that will never receive another patch is defenseless against the next one. This is where the conversation connects to managed security: an internet-facing mail server is precisely the kind of asset that needs continuous patching and monitoring you cannot provide if the vendor has stopped shipping fixes.
What About Organizations That Truly Must Stay On-Premises?
Some organizations have a genuine, defensible reason to keep email off the public cloud: strict data-residency laws, regulatory mandates that data never leave a controlled environment, or contractual obligations that Microsoft’s multi-tenant cloud cannot satisfy. For them, Exchange Server SE is the supported answer, but it comes with the full weight of running mail infrastructure in-house, now on a subscription meter.
There is a middle path that regulated organizations often miss. You can run Exchange SE, or the surrounding infrastructure, in a dedicated, single-tenant managed private cloud rather than in your own building or in a public multi-tenant cloud. That keeps data in a known, controlled, compliant location with clear residency, while a provider carries the hardware, the patching, the hardening, and the monitoring. It resolves the usual tension between “we must control where the data lives” and “we cannot keep running this ourselves.” You get the control the regulation demands and the operational relief the deadline is pushing you toward, at the same time.
How a Clean Migration Actually Works
The word migration makes people picture a risky weekend and a flood of support tickets. Done properly, it is a staged, low-drama process. The shape is similar whether you are moving to Exchange Online, standing up Exchange SE, or handing the whole thing to a managed provider.
- Assess and inventory. Document every mailbox, distribution list, shared mailbox, public folder, connector, and third-party integration hanging off Exchange. The surprises that derail migrations almost always live in this layer, so finding them first is the most valuable step.
- Sort out identity. Decide how Active Directory and identity will work after the move, including whether Entra Connect stays in the picture, because that decision determines whether you can fully retire on-premises Exchange or must keep a management server.
- Pick the path per group. You do not have to move everyone the same way on the same day. A phased migration, moving a pilot group first, validating mail flow and client behavior, then expanding, keeps risk contained and surfaces issues while they are small.
- Migrate mailboxes and data. Move mailboxes in batches, preserving folder structure, calendars, permissions, and delegate access. Keep users informed so a changed login or a re-authentication prompt does not generate panic.
- Cut over and decommission. Once mail flow is confirmed on the new platform, update DNS and MX records, retire connectors, and properly decommission the old Exchange servers rather than leaving them powered on and forgotten. A dormant, unpatched Exchange box is still an attack surface.
None of these steps is exotic, but the sequence and the details matter, and the cost of getting them wrong is measured in outages and lost mail. This is precisely the kind of project where experience pays for itself, because a team that has done it many times knows where the sharp edges are.
The Mistakes That Turn a Migration Into an Incident
A handful of avoidable errors account for most painful Exchange migrations. Knowing them in advance is the cheapest insurance you can buy.
- Leaving the old server running. After a migration, an unpatched Exchange box left online for a few remaining functions is a live liability. Either bring it into a supported state or decommission it deliberately, do not just stop using it.
- Underestimating the hybrid tail. Teams routinely assume they have fully left on-premises Exchange, then discover the recipient-management dependency that requires keeping a server. Plan for it up front so it is a choice, not a surprise.
- Forgetting the surrounding systems. Applications that relay mail through Exchange, scanners and copiers that send to internal addresses, and line-of-business tools with SMTP settings all break if you cut over without accounting for them. The inventory step exists to catch exactly this.
- Skipping backup and recovery planning. A migration is a moment of change, and change is when you most want a tested rollback and a clean backup. Confirm your recovery position before you move, not after something goes wrong.
Every one of these mistakes is a reason organizations increasingly hand the whole project to a provider who does migrations for a living, rather than asking a stretched internal team to learn on the most attacked server in the building. Which leads to the real point behind the deadline.
The Bigger Point: Email Is Undifferentiated Heavy Lifting
Step back from the deadline for a moment, because it is pointing at something larger. Running your own mail server is a lot of specialized, high-stakes work that does not differentiate your business in any way. Your customers do not care whether your Exchange server is patched. They only notice when it fails or gets breached. Email is the textbook example of undifferentiated infrastructure: essential, demanding, a constant security liability, and completely invisible when it works.
The Exchange end-of-support deadline is a forcing function to ask a better question than “which version do we install next?” The better question is “why are we in the business of running this at all?” For most organizations, the honest answer is that they should not be. The same logic that moves email to the cloud applies to the servers, storage, identity, backup, and disaster recovery around it. Those are all forms of undifferentiated heavy lifting that a managed provider can run more securely and more predictably than an in-house team stretched across a dozen other priorities.
This is where IT Vortex fits. We help organizations move off aging on-premises infrastructure and into a managed environment where the patching, hardening, monitoring, and recovery are our job, not yours. Whether that means a clean cloud migration, a managed private cloud for the workloads that need to stay off the public cloud, or wrapping your whole environment in managed services with proper backup and disaster recovery, the goal is the same: you stop babysitting infrastructure and get back to running your business.
The Exchange deadline already passed, which means the clock is not ticking anymore, it has rung. Every day an unsupported mail server stays online is a day of accumulating, un-patchable risk for zero business benefit. The organizations that treat this as the prompt to get out of the infrastructure business entirely will come out of it more secure and less burdened than the ones that simply reinstall the next version and start the cycle over. Looking past Exchange on-premises is really about looking past the whole idea that you should be running this yourself. Talk with IT Vortex about a clean migration off on-premises Exchange and the infrastructure around it.
Exchange On-Prem Migration: Frequently Asked Questions
Is Microsoft Exchange on-premises still supported?
Exchange Server 2016 and 2019 reached end of support on October 14, 2025, so they no longer receive security patches, bug fixes, or technical support. The only supported on-premises version is Exchange Server Subscription Edition (SE), released July 1, 2025. Running Exchange 2016 or 2019 after the deadline means operating unsupported, unpatched software.
What are my options after Exchange 2016 and 2019 end of support?
Three supported paths: migrate to Exchange Online as part of Microsoft 365 (Microsoft’s recommended and simplest option), upgrade to Exchange Server Subscription Edition to stay on-premises under a subscription license, or run a hybrid deployment as a transition. Doing nothing and staying on an end-of-life server is the only genuinely unacceptable choice.
Why is unsupported on-premises Exchange so risky?
Exchange is one of the most heavily attacked enterprise products, with mass-exploitation events like ProxyLogon in 2021 and ongoing flaws such as CVE-2025-53786 in 2025 that prompted CISA emergency directives. Because Exchange sits next to Active Directory, a compromise often leads to full network takeover. An unsupported server never gets patched again, leaving it defenseless against the next vulnerability.
Should I move email to the cloud or stay on-premises?
For most organizations, moving to Exchange Online or a managed environment is the better choice, because email is undifferentiated infrastructure that is costly and risky to run in-house. Staying on-premises with Exchange SE makes sense mainly for strict data-residency or regulatory needs, and even then it keeps the hardware, patching, and security burden on your team unless you hand it to a managed provider.
