Exchange Server 2016 and 2019 End of Support: move to Exchange SE or Online safely

Exchange Server 2016 and Exchange Server 2019 reached the end of extended support on 14 October 2025, so any organisation still running them has internet-facing mail servers that no longer receive routine security updates. Moving to a supported build keeps security updates flowing, and in a hybrid deployment it also protects the trust path into Exchange Online. This guide covers the lifecycle facts, how to find every Exchange server and the identities tied to it, the three exits (in-place upgrade to Exchange Server Subscription Edition, legacy migration, or moving to Exchange Online and removing the last server) and how to test and roll back each. It is for Exchange administrators, infrastructure leads and security teams making the decision. Day-to-day hardening of a supported server is covered in the Microsoft Exchange Server Security Guide; this page is about the lifecycle and the migration.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• Support has ended. Microsoft's lifecycle pages list the extended end date for both versions as 14 October 2025 (shown as 06:59:59 Pacific on 15 October). Paid Extended Security Updates were a short bridge, not a support plan.
• Exchange 2019 CU14 or CU15 has a low-risk route. Exchange SE RTM installs as a cumulative update on those builds and Microsoft describes it as code-equivalent to CU15.
• Exchange 2016 has no in-place route. It needs a legacy migration: install new servers, move mailboxes and public folders, then decommission.
• Coexistence has a deadline of its own. Microsoft states Exchange SE CU2 will require that no Exchange 2016 or 2019 servers remain in the organisation.
• Hybrid servers carry identity risk. The hybrid trust uses service principal credentials in Entra ID; an unsupported on-premises server with those credentials was the subject of CISA Emergency Directive 25-02.

What is changing and why

Exchange 2016 and 2019 were sold under Microsoft's Fixed Lifecycle Policy, which ends support on a set date. Their successor, Exchange Server Subscription Edition (SE), became generally available on 1 July 2025 and is serviced under the Modern Lifecycle Policy: no fixed end date as long as you stay current, no more year-numbered versions, and two cumulative updates a year planned plus security and hotfix updates as needed. Microsoft has stated a commitment to support Exchange Server through at least 2035. Microsoft staff replies on the launch post state that an SE licence requires Software Assurance; confirm licensing with your reseller.

What changes for an unsupported server:

• No security updates: new security updates are not released for 2016 or 2019 outside a paid ESU period. On supported builds, apply Microsoft security updates promptly, as listed in the Microsoft Security Update Guide.
• No support cases: Microsoft support will not help with problems on those versions.
• Compliance findings: unsupported software is a direct finding against NIST SP 800-53 SA-22 and CIS Control 2.2, and many cyber insurers ask about it.

Exchange SE also changes the product: Unified Messaging is gone, there are only Mailbox and Edge Transport roles, Extended Protection is on by default, and TLS 1.3 needs Windows Server 2022 or 2025. Future SE cumulative updates will require SE server product keys and modernised prerequisites.

Official timeline and current status

Dates as stated on Microsoft's lifecycle pages and Exchange team blog, checked 8 November 2026.

The ESU programmes were purchased, time-limited and security-only. Treat any server still on 2016 or 2019 as unsupported unless you hold a current ESU agreement and are installing its updates.

Who and what is affected

Do not forget servers that look idle: a "management only" Exchange 2016 box kept for recipient management or SMTP relay is still an unsupported Exchange server with high privileges in Active Directory.

Finding affected systems and identities

1. Enumerate every Exchange server: run Get-ExchangeServer in the Exchange Management Shell for name, version, roles and site, and compare against your CMDB. CISA ED 25-02 told federal agencies to inventory Exchange with Microsoft's Exchange Server Health Checker and record each server's CU level; the same step works for everyone.
2. Find internet exposure: list which servers publish OWA, ECP, EWS, Autodiscover, ActiveSync and SMTP to the internet, from firewall and load balancer rules and external scanning of your own ranges.
3. Check Emergency Mitigation status: on each Mailbox server, run Get-ExchangeServer with the *Mitigations* properties, or the Get-Mitigations.ps1 script in the V15\Scripts folder, to see whether the Exchange Emergency Mitigation service is enabled and which mitigations are applied. It needs outbound HTTPS to officeclient.microsoft.com.
4. Map the hybrid identities: record the hybrid configuration, the Entra application used for the hybrid OAuth trust (the shared first-party service principal or the dedicated Exchange hybrid application), the federation trust and certificate, and any Hybrid Agent.
5. Map service accounts and integrations: backup, archiving, journaling, anti-spam gateways, multifunction devices relaying through Exchange, and applications using EWS on-premises. Each needs testing against SE or a new home.
6. Record privileged groups: Exchange holds powerful rights in Active Directory (Exchange Trusted Subsystem, Exchange Windows Permissions, Organization Management). Note members now; they are part of the decommission plan.

Migration options

Option 1: in-place upgrade to Exchange SE (from 2019 CU14 or CU15)

Microsoft recommends this as the simplest path. Compared with CU15, SE RTM adds or removes no features, makes no Active Directory schema change (though /PrepareAD may be needed coming from CU14), changes no prerequisites and needs no new licence key at RTM. Upgrade server by server as you would apply a CU: put the server in maintenance mode, run setup, test, return it to service, then the next. Move to SE CU1 and later as they ship, because new features and requirements start there.

Option 2: legacy migration (from 2016, or to new hardware)

Install new SE servers into the existing organisation (schema updates required), build a new DAG, move mailboxes and public folders, move client namespaces, mail flow and certificates, recreate the Edge subscription, re-run the Hybrid Configuration Wizard if hybrid, then decommission the old servers. Microsoft also allows a legacy move to 2019 CU14 or CU15 followed by an in-place upgrade, but going directly to SE avoids doing the work twice.

Option 3: Exchange Online and remove the last server

If all mailboxes and public folders are already in Exchange Online, Microsoft supports managing hybrid recipients with no running Exchange server, using the Exchange Management Tools from Exchange 2019 CU12 or later and the Recipient Management PowerShell snap-in (Add-PSSnapin *RecipientManagement). Conditions apply: no on-premises recipients, no need for the on-premises EAC or Exchange RBAC, no need for auditing of recipient changes, and the server is used only for recipient management, never for SMTP relay. Non-domain admins need the Recipient Management EMT group created by Add-PermissionForEMT.ps1.

Decision guidance: small organisations with few mailboxes and no on-premises requirement usually gain most by moving to Exchange Online and removing Exchange entirely, because patching an internet-facing Exchange server is a heavy ongoing cost. Large or regulated organisations with on-premises requirements should get to SE quickly and plan for its twice-yearly CU cadence. Either way, plan relay first: SMTP relay is the most common reason a "last" server cannot be switched off. See the Exchange Online SMTP AUTH Basic Auth Retirement guide for relay and device options.

Testing and rollback

1. Lab first: rehearse setup in a test organisation that matches your schema, CU and third-party agents.
2. Back up and record: take system state and database backups, record virtual directory URLs, certificates, receive connectors and any customised config files, because setup can overwrite them.
3. One server at a time: in-place upgrades are per server. Keep the rest of the DAG serving users and verify OWA, Outlook, ActiveSync, mail flow, Autodiscover and hybrid mailbox moves after each.
4. Rollback reality: an in-place upgrade is not uninstalled like a patch; rollback is restoring from backup or failing users over to other DAG members while you rebuild. Legacy migration is easier to roll back because old servers stay until you decommission.
5. Last-server removal is staged: Microsoft's process is to install the Management Tools, test every recipient cmdlet you use, shut the server down and retest, without uninstalling it. The Active Directory cleanup script CleanupActiveDirectoryEMT.ps1 is irreversible; run it only when you will never run Exchange again, and never uninstall the last server.
6. DNS last: point MX and Autodiscover to Exchange Online before final shutdown so mail flow does not break.

Risks of doing nothing

• Unpatched exposure: an internet-facing server without current updates is open to exploitation of public-facing applications (ATT&CK T1190) followed by web shells (T1505.003), so plan the move before new issues are published.
• Mitigations are not fixes: the Emergency Mitigation service applies temporary URL rewrite, service or app pool mitigations until a security update is installed. Microsoft says it does not replace updates, and an unsupported server gets no update to follow.
• Cloud compromise via hybrid: CISA ED 25-02 (7 August 2025) addressed a hybrid configuration issue where an attacker with admin access on an on-premises hybrid Exchange server could move into Exchange Online. It required agencies to disconnect servers not eligible for Microsoft's April 2025 hotfix updates, including end-of-life servers.
• Forced, rushed migration: SE CU2 will block coexistence with 2016 and 2019, so delaying compresses the migration window later.

Where identity fits

Exchange is as much an identity system as a mail system. The hybrid OAuth trust is a service principal in Entra ID; Microsoft and CISA direct organisations to move from the shared first-party service principal to the dedicated Exchange hybrid application with ConfigureExchangeHybridApplication.ps1, and to reset the first-party service principal key credentials, both when hardening and when removing the last server. On-premises, Exchange security groups hold write rights over large parts of Active Directory, so leftover groups after decommissioning are standing privilege. Remove the federation trust and certificate, reset the hybrid credentials and run the AD cleanup when Exchange is gone for good. See the Azure RBAC and Service Principals Guide.

Detection, metrics and framework mapping

• Unsupported servers: count of Exchange 2016 and 2019 servers, trending to zero, with a target date.
• Exposure: internet-facing Exchange endpoints on unsupported builds (target zero now).
• Patch currency: SE servers on the latest CU and security update within your patch SLA.
• Mitigation health: Emergency Mitigation enabled and connected on every Mailbox server, checked with Test-MitigationServiceConnectivity.ps1.
• Hybrid identity hygiene: dedicated hybrid application in use and first-party service principal credentials reset, verified in Entra ID.
• Web shell watch: alert on new .aspx files under Exchange virtual directories and unusual child processes of IIS worker processes on Exchange servers.

Practitioner checklist

• Inventory every Exchange server, its version, CU, roles and internet exposure.
• Record whether you hold a current ESU agreement; if not, treat 2016 and 2019 as unsupported today.
• Update Exchange 2019 to CU14 or CU15 and plan the in-place upgrade to SE server by server.
• Plan a legacy migration for Exchange 2016, with a new DAG and Edge subscription, and remove any Exchange 2013 first.
• Decide relay and device mail flow before targeting last-server removal.
• Move the hybrid trust to the dedicated Exchange hybrid application and reset first-party service principal credentials.
• Confirm the Emergency Mitigation service is enabled and reachable on every Mailbox server.
• Finish before SE CU2 requires that no 2016 or 2019 servers remain.
• After removing Exchange, remove the federation trust, run AD cleanup and review Exchange security groups.

Standards and references

• Microsoft Lifecycle: Exchange Server 2019
• Microsoft Lifecycle: Exchange Server 2016
• Microsoft Exchange Team: Exchange Server Subscription Edition (SE) is now available
• Microsoft Learn: What's new in Exchange Server
• Microsoft Learn: Manage recipients in hybrid environments using Management tools
• Microsoft Learn: Exchange Emergency Mitigation Service
• CISA: ED 25-02 Mitigate Microsoft Exchange Vulnerability

Related NHI Mgmt Group resources: Microsoft Exchange Server Security Guide · Exchange Online Security Guide · Exchange Web Services retirement · Exchange Online SMTP AUTH Basic Auth Retirement