Exchange Server SE vs Exchange Online: Which Way Forward?

October 2025 quietly ended an era. Support for Exchange Server 2016 and 2019 finished, and with it the last of the old perpetual-license Exchange servers fell out of support. If you want to keep running Exchange on your own hardware today, there is exactly one supported way to do it: Exchange Server Subscription Edition, usually shortened to Exchange SE.

That single fact reframes the whole on-premises question. The choice is no longer "keep the server we already paid for" versus "start paying a subscription." Both supported paths are now subscriptions. The real question is which subscription you want: one that comes with a server you must run, or one that does not.

What Exchange SE actually is

Exchange SE is the successor to Exchange 2019 and Microsoft's ongoing on-premises Exchange product. The important characteristics:

• It is the only supported on-premises Exchange. Exchange 2016 and 2019 left support in October 2025; 2010 and 2013 left years earlier. Running any of them today means no security patches, ever.
• It is subscription licensed. Staying supported requires active subscription coverage (server licenses plus user or device CALs with Software Assurance, or equivalent cloud subscription licensing). There is no "buy once and run it for a decade" option anymore.
• It follows a continuous update model. Rather than big-bang versions every few years, SE receives ongoing cumulative updates, which you still have to install yourself, on hardware you still have to own and operate.
• Upgrading to it from 2019 is an in-place step, but from anything older it is a real migration. Exchange 2016 and earlier cannot jump straight to SE in place; getting there means a legacy migration project of similar shape to a cloud migration.

In other words: SE is a legitimate, supported product, and it deliberately prices on-premises Exchange like the service it actually is, rather than the one-time purchase it used to pretend to be.

The comparison that matters

The last row deserves emphasis. If you are on Exchange 2016, 2013, or 2010 today, you cannot avoid a migration project by choosing SE. You will do roughly the same amount of moving either way; the only question is whether you land on a server you keep maintaining or in a service you do not. The full cost picture of that ongoing maintenance is laid out in our true cost comparison.

When Exchange SE is the right answer

There are organizations for which SE is genuinely correct, and we help them deploy it. The honest list:

• Regulatory or contractual data residency. Some regulated environments and government contracts require mail to remain on infrastructure the organization physically controls. If your compliance obligation says the data cannot leave your premises, SE is the supported way to honor it.
• Hard application dependencies. A small number of line-of-business systems require a local Exchange server and cannot be re-pointed to Exchange Online. Sometimes the fix is replacing the app; when it is not, SE (often in a hybrid design) keeps it alive. See our hybrid pros and cons guide for how that plays out.
• Genuinely disconnected or bandwidth-starved sites. Ships, remote industrial sites, and locations with unreliable connectivity can justify local mail infrastructure.
• Organizations with real Exchange engineering on staff. If you already employ people who patch, monitor, and defend Exchange well, the operational burden of SE is a known quantity rather than a hidden risk.

When Exchange Online wins (which is most of the time)

For a typical SMB with none of the constraints above, the SE path means paying a subscription and buying hardware and doing the patching and owning the attack surface, to end up with a mailbox that behaves the same as the cloud one from the user's chair. The economics rarely survive contact with a spreadsheet, and the security story is worse: unpatched or slow-patched Exchange servers remain one of the most reliably exploited systems on the internet, and with SE the patching cadence is still yours to keep.

There is also a strategic point. Microsoft's investment clearly centers on Exchange Online; SE exists to keep the customers who truly need on-premises supported, not to win new deployments. Betting your mail platform on the path the vendor maintains out of necessity is a decision you should make deliberately, not by default.

A simple decision framework

1. Do you have a written requirement (law, regulation, contract) that mail stays on-premises? If yes, plan SE or hybrid. If it is a preference rather than a requirement, keep going.
2. Does any application break without a local Exchange server? If yes, first price replacing or re-pointing the app; hybrid often beats full on-premises here.
3. Do you have staff who can patch and defend an internet-facing Exchange server indefinitely? If no, SE's real cost includes hiring or contracting that skill, forever.
4. If you answered no, no, and no: Exchange Online is your answer, and the only remaining question is the one-time migration, whose typical pricing we cover in How Much Does an Exchange Migration Cost?

What a specialist changes

Whichever way you go, you are facing a project: to SE from anything older than 2019, or to Exchange Online from anywhere. This decision is also easy to get wrong expensively, in both directions: we have unwound "everything to the cloud" projects that broke a regulated workflow, and we have retired SE servers bought for an application that a two-hour reconfiguration could have re-pointed at Exchange Online. A partner who does only migrations has seen both failure modes and scopes the destination before moving a single mailbox. If the answer is SE or hybrid, we will tell you so and build it; if it is Exchange Online, we will get you there with a fixed price and no lost mail. If you are weighing whether to run the project yourselves, DIY vs Migration Partner walks through that call honestly.