If you still run Exchange Server 2016 or 2019 on your own hardware, the last safety net goes away at the end of October 2026. Mainstream and extended support already ended on October 14, 2025. What kept some servers patched since then was a paid Extended Security Update (ESU) program, and Microsoft has said plainly that it will not be extended again.
This piece is for the admin who has to pick a route in the next few weeks. It covers what the dates actually mean, the three realistic options, and what a move to self-hosted open-source mail looks like in practice. For that last part we lean on a migration we ran ourselves. One honest caveat up front: our project moved a university off IceWarp, not Exchange. Most of what we learned carries over. Some of it doesn't, and we'll say where.
The dates, straight from Microsoft
- October 14, 2025: end of support for Exchange 2016 and 2019. No more bug fixes, security fixes, time zone updates or technical support for anyone without an ESU contract (Microsoft Learn).
- ESU Period 1: October 2025 through April 2026.
- ESU Period 2: the start of May 2026 through the end of October 2026. It is a separate contract. If you bought Period 1, you have to buy Period 2 again. It is sold through your Microsoft account team, requires an Enterprise Agreement, and is not included in Volume Licensing or Software Assurance (Exchange Team blog).
- After October 2026: "Once October 2026 ends, there will be no further updates for Exchange 2016/2019, even if you currently have a Period 2 ESU," and "there will be no further extension of Exchange 2016/2019 ESU program timeline" (Exchange Team reminder).
Two details in the Period 2 FAQ are easy to miss. ESU updates are shared privately with paying customers only, and Microsoft says it is not committing to release any security update during Period 2 at all. So even the paid bridge only gives you fixes if Microsoft decides a vulnerability is serious enough to ship one.
An Exchange server that faces the internet and gets no patches is a serious liability. Exchange has been one of the most heavily targeted server products of the last several years. Plan as if the server has to be off the internet, or off Exchange 2016/2019, by November.
The three routes that actually exist
1. Upgrade in place to Exchange Server Subscription Edition (SE)
Microsoft's own on-premises path. You stay on Exchange, your admins keep their skills, Outlook keeps every feature it has today. The trade is licensing: SE is a subscription product, so the "buy it once, run it for ten years" model is gone. If your problem is only the deadline, this is the lowest-risk move and nothing below should talk you out of it.
2. Move to Microsoft 365 / Exchange Online
What most of the search results for this topic recommend, and for many organizations the right answer. Someone else patches the servers. You pay per user, forever, and your mail lives in Microsoft's cloud.
3. Leave Microsoft's mail stack for self-hosted open source
This is the option most guides mention in one line and then drop. It makes sense for a specific profile:
- You have enough mailboxes that per-user pricing turns into a large annual number.
- You have a hard data-residency requirement, meaning mail has to stay in-country or on hardware you control.
- For organizations in Iran and similar markets, a USD-billed subscription carries currency and sanctions risk on top of the price.
If none of those apply to you, route 1 or 2 is probably simpler. The rest of this article is about route 3, because that is where we have first-hand experience.
What we actually did: 10,000 mailboxes off a commercial suite
Lorestan University ran its email on IceWarp, a commercial on-premises mail and collaboration suite, and was paying roughly $70,000 a year in licensing for 10,000 mailboxes. We moved all of it to Stalwart Mail Server, which is open source. Infrastructure cost at the same scale is now under $4,000 a year. The full cost breakdown is in our cost case study, and the reasons organizations still choose self-hosting in 2026 are in this earlier piece. We won't repeat either here.
The deployment is deliberately boring. It runs on one server: Stalwart Community (pinned to the v0.16 line) with PostgreSQL as the datastore, MinIO for blob storage and NATS, all in Docker, with a daily backup that gets test-restored. Accounts come from the university's existing LDAP/Active Directory instead of being created one by one. That last point matters a lot if you are leaving Exchange, because your directory is already in AD.
What carries over from an Exchange world
- Directory. Stalwart can read accounts from LDAP/AD. Your users, groups and passwords stay where they are.
- Mail clients over standard protocols. IMAP, SMTP and POP3 work with Outlook, Thunderbird, Apple Mail and phone clients. Compatibility with Outlook, Thunderbird and mobile was one of our explicit acceptance criteria.
- Calendars and contacts. CalDAV and CardDAV are supported, so calendars and address books have a standard home.
- A fast webmail. Stalwart speaks JMAP, a modern protocol built for web clients. We built our webmail on it, and it is noticeably quicker than IMAP-based webmail. We wrote about why in this piece on JMAP.
What does not carry over (read this part twice)
- Exchange ActiveSync. Stalwart Community does not implement EAS. In our own project plan, ActiveSync was listed as out of scope, with a note that if a pilot showed users depended on it, we would reconsider the mail engine. If your phones and your Outlook setup rely on ActiveSync today, test this first. Don't discover it on cutover day.
- The Outlook features that only exist on MAPI/EWS. Outlook over IMAP is a different experience from Outlook against Exchange. Shared mailbox delegation, public folders, and the way free/busy and meeting rooms behave are the usual gaps. Collect the features your users actually rely on before you promise anyone a like-for-like move.
- Some admin comforts. On the Community edition, some settings management and native metrics sit behind Stalwart's Enterprise license. We replaced the metrics side with Prometheus and Grafana. Budget time for that kind of glue work.
- Somebody's pager. Self-hosting means you own deliverability, spam filtering, TLS certificates and backups. Nobody else patches it at 3 a.m.
The migration mechanics that saved us
Treat mail history as sacred. Our rule was that no mailbox is touched without a backup, and the source is never modified. History was copied with file-based export tools, followed by a weekly incremental sync that only appends and never deletes. That way a message deleted by mistake on the old system could not wipe the copy on the new one.
Verify by Message-ID, not by counting files. A folder that has the same number of files on both sides can still be missing messages and have duplicates of others. Unique Message-IDs are what tell you the history arrived intact.
Pilot one department first. This was the lesson we'd push hardest. Moving a small group first surfaced DNS and DKIM mistakes while only a handful of mailboxes were affected. None of the problems were exotic. They were the kind you only notice once real mail flows through new records, and it's far better to find them with twenty users than with ten thousand.
Get DNS and reputation right before the big cutover. SPF, DKIM, DMARC and a correct PTR record for the sending IP all have to be in place. If your new server sends from an IP address with no history, expect to warm it up gradually. A cold IP that suddenly sends a university's worth of mail gets throttled or junked by the big providers.
Think about login recovery. On your own mail server, "we'll email you a reset link" is circular. We added SMS one-time-password login with 2FA, and at this scale it mattered more for day-one adoption than any webmail feature. We also added an opt-in email-to-SMS alert for staff who don't sit in their inbox all day.
If you have five weeks, not five months
A cross-platform migration of a few thousand mailboxes is not something to rush before October 31. If you can't finish in time, the honest order of moves is:
- Get the Exchange servers covered first. That means an in-place upgrade to Exchange SE, or Period 2 ESU if you already have it, or at minimum taking OWA and other Exchange endpoints off the public internet.
- Take inventory: mailbox count, total size, who uses ActiveSync, which shared mailboxes and public folders matter, and which applications relay mail through Exchange.
- Stand up the new platform alongside the old one and move one pilot department.
- Fix what the pilot finds, then migrate department by department with incremental sync running the whole time.
- Switch MX records only when the pilot has run cleanly for a while.
Whether you land on Exchange SE, Microsoft 365, or your own servers, the deadline itself is not negotiable. Leaving an unpatched Exchange server on the internet in November 2026 is the one option that is clearly wrong.
The Lorestan side of this, including what 10,000 real users noticed and what they didn't, is written up here.