Exchange Server 2019 reached general availability yesterday, on October 22. Windows Server 2019 is the messier half of the story: it shipped on October 2, then Microsoft pulled it days later after reports the in-place upgrade could delete user profile data, and as we write it still has not been re-released. The release notes will fill weeks of blog posts about Security Baseline defaults, Storage Spaces Direct maturity, and Exchange's preferred architecture updates. This post is the question clients actually ask us in the hallway after the launch webinar: should we still deploy Exchange on-premises at all?
We run hybrid programs for government and enterprise estates — fifteen thousand-plus mailboxes moved, Exchange 2010 and 2013 farms still in coexistence, ADFS and pass-through authentication in production. Our answer is not a slogan. It is a fork with honest criteria.
The default in late 2018
For most organizations whose constraints are ordinary — commercial, regulated but not air-gapped, users who already live in Outlook and mobile ActiveSync — cloud-first mail with hybrid as a bridge is the default we recommend. Office 365 (Exchange Online) takes patching, DAG design, and a large fraction of DR off your plate. The hybrid server remains for identity, management, and any lingering on-prem dependencies; it is not a second full enterprise farm.
Deploying a greenfield Exchange 2019 multi-DAG footprint in 2018 needs a reason stronger than "we have always had Exchange in the basement."
When on-prem Exchange 2019 is still rational
We still design on-prem or long hybrid when one or more of these are true:
- Sovereignty and disconnect. True disconnected networks, or legal requirements that mailbox data cannot leave a specific facility, still exist. Marketing "government cloud" options help some of these; they do not help all of them.
- Line-of-business coupling. Applications that insist on MAPI against an on-prem store, or journaling architectures that have not been re-architected, can force a longer on-prem tail. The fix is often application modernization — budget that as a program, not an Exchange footnote.
- Latency and scale edge cases. Rare, but some campus designs with pathological WAN conditions still prefer local mailbox databases. Measure; do not assume.
- Migration runway. You are not "choosing on-prem forever"; you are standing up Exchange 2016/2019 as a supported hop off Exchange 2010 before end of support. That is a valid tactical deploy even if the strategic target is Online.
If none of these apply and someone wants Exchange 2019 because Server 2019 is new and shiny, push back.
Windows Server 2019: what we actually care about for the mail and identity tier
For the servers that remain — hybrid Exchange, ADFS or PTA agents, file, RDS — Server 2019 is a reasonable target OS when you have a patching and hardware plan. Storage Spaces Direct has matured since 2016; we will consider it for hyper-converged file and backup tiers more readily than we did two years ago. We still will not put a customer's first S2D cluster under their only Exchange DAG without a pilot.
Security baselines and credential guard-related hardening are welcome; test against your backup agents and monitoring stack before you enforce domain-wide.
Hybrid-minimal vs cloud-first: the fork we draw on whiteboards
Cloud-first: mailboxes in Exchange Online; hybrid for management and identity; on-prem Exchange footprint as small as the HCW and dependency analysis allow; public folders and shared namespaces planned deliberately.
Hybrid-minimal: same direction, but a defined set of mailboxes or system mailboxes remain on-prem for a dated period with exit criteria.
On-prem persistent: full DAG(s), full patching program, full DR test cadence — funded as a product, not as "temporary."
The failure mode is accidental persistent hybrid: hybrid was meant to be a year and becomes five because no one owned the exit. Write the exit in the SOW.
Exchange 2019 notes without the brochure
Preferred Architecture still matters: simplified namespace, DAG design, no nonsense multi-role sprawl from 2010-era habits. MetaCacheDatabase and search changes will need ops runbook updates. Clients coming from 2010 should not leapfrog without a supportability review — sometimes 2016 hybrid is the lower-risk hop if skills and time are constrained; sometimes 2019 is fine. The constraint is usually calendar and app dependency, not the minor version pride.
Cost honesty
On-prem Exchange is not "free because we own Windows." It is hardware or host capacity, backup, DR, certificates, patch weekends, and the people who know transport rules. Exchange Online is subscription and network and identity. Compare five-year TCO with the same assumptions about growth and eDiscovery. We have seen both sides win the spreadsheet depending on starting point.
Hybrid configuration still earns its keep
Even cloud-first shops usually keep hybrid for a period: management endpoints, free/busy during migration, and the occasional application that authenticates against on-prem Exchange quirks. The Hybrid Configuration Wizard is better than it was, and still not something you run once and forget. Certificate lifecycle, OAuth between endpoints, and MRS proxy health remain operational work.
If you deploy Exchange 2019 solely as a hybrid anchor, size it as a hybrid anchor — not as a latent 50,000-user DAG "just in case." Overbuilding hybrid servers is how temporary becomes permanent in the budget.
Identity couples the decision
Exchange on-prem vs Online is inseparable from Azure AD Connect, federation or PTA, and Conditional Access trajectory. A decision to "stay on-prem for mail" while moving the rest of productivity to the cloud creates split personality for security policy. Align the identity roadmap with the mail roadmap in the same steering committee, not sequential projects that surprise each other.
What we are doing on active programs
- Exchange 2010 estates: runway to hybrid Online remains the primary recommendation; 2019 on-prem only where criteria above hold
- Exchange 2013 hybrid already: evaluate whether 2019 hybrid upgrade is needed for supportability or whether Online move finishes first
- New Server 2019 builds: fine for domain controllers, file, RDS, management — not an automatic Exchange install trigger
Decision worksheet we leave with clients
Score each 1–5 (5 = strongly true):
- Mailbox data must remain in a facility Azure regions cannot satisfy
- Application dependencies on on-prem Exchange are funded to remove within 24 months
- We have staffed Exchange admin capacity for DAGs, certificates, and patching for five years
- Our identity roadmap is cloud-first with hybrid as bridge only
- Our CFO compared five-year on-prem TCO to Online with equal growth assumptions
If (1) is high, on-prem or specialized cloud stays on the table. If (3) is low and (4)–(5) are high, stop designing big DAGs. If (2) is high, you are not choosing on-prem — you are choosing delay. Delay is valid when funded; it is toxic when silent.
Server 2019 for everything else
Separately from Exchange: domain controllers, file servers, RDS session hosts, and management jump boxes can move to Server 2019 on their own lifecycle. Do not couple OS current with mail platform decision unless they truly share a maintenance window. Couplings create artificial emergency upgrades.
If you're facing this
If Server 2019 and Exchange 2019 landed as a mandate to refresh the mail platform, decide the fork first: cloud-first hybrid, dated hybrid-minimal, or true persistent on-prem. We design all three; we refuse to pretend they cost the same in risk and labor. Bring your dependency list and your real sovereignty constraints — not just the launch deck.