A hybrid Exchange upgrade can fail in ways that do not appear on a standard server readiness report. Because many organizations now face the End of support for older versions, moving to Exchange Server Subscription Edition is a critical step for maintaining a secure environment. A working mailbox database does not prove that Autodiscover, OAuth, certificates, connectors, and Exchange Online routing will survive the transition.
An Exchange Server SE migration needs more than a successful Setup.exe run. It requires a tested plan for the systems that still depend on on-premises Exchange, even when most mailboxes live in Microsoft 365.
Use this checklist to prepare, execute, validate, and recover an Exchange Server Subscription Edition deployment without assuming you can retire on-premises Exchange.
Key Takeaways
- Exchange Server Subscription Edition has strict supported upgrade paths, so confirm your current Exchange Server 2019 or Exchange Server 2016 version and cumulative update before scheduling your migration.
- Hybrid organizations must validate more than mailbox access, including mail flow, Autodiscover, OAuth, certificates, connectors, and directory synchronization.
- Keep at least one supported on-premises Exchange server when synchronized identities still use on-premises Active Directory as the source of authority.
- Run the latest Hybrid Configuration Wizard when Microsoft guidance or your configuration change requires it, but always review the selected options before applying any changes to your environment.
- A rollback plan needs tested backups, documented settings, and a recovery decision made before the maintenance window begins.
Start With the Supported Exchange Server SE Path
Exchange Server Subscription Edition, often shortened to Exchange SE, replaces the older perpetual release model for new Exchange Server deployments. Its servicing requirements, supported Windows Server builds, including full support for Windows Server 2025, and licensing terms can change with new cumulative updates. Always verify the current system requirements in Microsoft’s Exchange Server build and version guidance before approving a migration design.
The first decision is whether you are performing an in-place upgrade or a server replacement migration.
An in-place upgrade keeps the same server name, operating system instance, Exchange configuration, databases, and virtual directory settings. This approach reduces infrastructure changes, but it also concentrates risk on one server. Notably, an in-place upgrade from Exchange Server 2019 to Exchange SE requires CU15 as the RTM state for the transition. This route is only available from specific versions and cumulative updates that Microsoft explicitly supports for the installed Exchange SE build.
A replacement migration, often considered the preferred legacy upgrade path for those moving from Exchange Server 2016, introduces new Exchange SE servers into the existing organization. You then move or replicate services, update namespaces and load balancer targets, migrate any remaining on-premises mailboxes, and remove older servers only after full validation. This approach takes longer but provides your team with a cleaner rollback boundary.
Exchange 2016 cannot be upgraded directly to Exchange SE. Organizations still running Exchange 2016 need a supported intermediate path, usually involving Exchange 2019 at the required cumulative update level, or a complete replacement deployment. Likewise, an Exchange 2019 server on an older cumulative update may need a patch before it qualifies for an in-place upgrade.
Use the current Exchange upgrade documentation as the final authority. Do not rely on a migration plan written before a newer Exchange SE cumulative update was released.
Treat the installed Exchange cumulative update as a hard prerequisite, not a minor patch detail. An unsupported starting build can stop the project before the first server changes.
Choose the operating model before building anything
Most hybrid organizations should decide what their on-premises Exchange footprint will look like after the migration. The answer affects high availability, certificate scope, backup capacity, patching, and monitoring.
A single Exchange SE server may be enough for a small organization that only manages recipients and supports limited hybrid features. However, that design creates a maintenance dependency. During an outage, administrators may lose on-premises recipient management or hybrid mail-routing capabilities.
Larger environments usually retain multiple Exchange servers, often across separate fault domains. Database availability groups may still be appropriate when on-premises mailboxes, SMTP relay workloads, compliance requirements, or recovery objectives justify them.
Do not mistake mailbox location for management location. If Active Directory remains authoritative for synchronized users, Exchange attributes such as proxy addresses, remote routing addresses, and mail-related settings still need supported management tools.
Build an Accurate Hybrid Environment Inventory
Hybrid Exchange environments accumulate exceptions over time. A line of business application may relay through an old connector, a forgotten SMTP namespace may appear in a certificate, or a third party gateway may still route messages through a legacy server. Inventory those dependencies before changing Exchange.
Start by documenting your current on-premises topology, including any existing Exchange Server 2019 infrastructure. Record every Exchange server, its version, cumulative update, security update, role, database copies, operating system, IP address, and network placement. Include servers that seem decommissioned but remain reachable, as they can still receive SMTP, HTTPS, or client traffic.
Use this read-only command within the Exchange Management Shell to confirm the Exchange server inventory:
Get-ExchangeServer | Format-Table Name,ServerRole,AdminDisplayVersion -AutoSize
This confirms what Exchange reports as installed. Compare the output with your CMDB, DNS records, load balancer pool members, and monitoring platform. Differences usually point to servers that were previously undocumented.
Next, capture the services that the environment still provides:
- List all accepted domains, remote domains, and email address policies.
- Identify every SMTP relay device, application, scanner, and multifunction printer.
- Export receive connectors and send connectors, including bindings, TLS names, IP ranges, smart hosts, and authentication settings.
- Document external and internal URLs for Outlook on the web, Exchange Web Services, ActiveSync, Outlook Anywhere where present, and Autodiscover.
- Record load balancer virtual IPs, health probes, persistence settings, and TLS offload behavior.
- Identify mail gateways, journaling systems, archive platforms, secure email gateways, and transport rules that use connector based routing.
- List remaining on-premises mailboxes, public folders, arbitration mailboxes, and discovery mailboxes.
- Detail any ongoing mailbox migration plans for remaining on-premises users.
Also document the hybrid configuration itself. Check whether the organization uses centralized mail transport, secure mail connectors, free or busy sharing, mailbox moves, or Edge Transport servers. Each selection affects what the Hybrid Configuration Wizard configures and what must remain functional after the Exchange Server SE migration.
Confirm Licensing, Windows Server, and Directory Prerequisites
Exchange SE licensing is subscription-based. Organizations commonly qualify through subscription licenses or active Software Assurance rights, but the exact entitlement rules, server licensing, and client access license requirements can change. Validate your position against current Microsoft Product Terms and your reseller or licensing representative before installing production software.
Windows Server requirements also change between Exchange SE builds. Confirm supported operating system versions, Desktop Experience requirements, .NET requirements, Visual C++ dependencies, Active Directory schema preparation steps, and Windows updates against the release documentation for the Exchange SE CU you will deploy. To ensure your environment is fully prepared, it is recommended to use the Microsoft Deployment Assistant to verify your readiness.
Do not use a general Windows Server build standard without checking it against the Exchange matrix. A supported operating system for other workloads may not yet be supported for the Exchange SE build in your plan.
Use a formal readiness checklist:
- Confirm the source Exchange version and CU supports the selected Exchange SE migration path.
- Confirm active subscription or Software Assurance rights, Exchange Server licenses, and required CAL coverage.
- Verify the target Windows Server version is supported for the planned Exchange SE CU prerequisites.
- Patch Windows Server and install all Exchange-required prerequisites before the maintenance window.
- Confirm Active Directory forest and domain functional requirements from current Microsoft guidance.
- Assign Schema Admins, Enterprise Admins, and Organization Management access only for the preparation period.
- Check free disk space for installation, transport queues, databases, logs, backups, and future CU staging.
- Validate DNS resolution, time synchronization, outbound HTTPS access, and firewall rules from each new server.
Prepare Active Directory in a controlled change window. Replication delays can turn a routine schema extension into an inconsistent deployment if remote sites have unhealthy domain controllers. Check replication first, then run the required PrepareAD command from the approved Exchange media and account context.
For hybrid organizations, directory synchronization needs equal attention. Microsoft Entra Connect Sync or Microsoft Entra Cloud Sync must continue exporting the attributes that Exchange Online uses. Confirm the source of authority for recipient properties before changing recipient management processes.
Preserve Hybrid Identity, Autodiscover, and Authentication
Exchange hybrid deployments rely on a complex set of identity and service relationships that are often overlooked because users rarely notice them. A mailbox might open in Outlook while critical background functions, such as free/busy lookup, OAuth, mobile access, or cross-premises message tracking, have already failed.
Begin by utilizing the Hybrid Configuration Wizard to refresh the organization relationship. Microsoft updates this wizard frequently, so always download and run the current version only when your change plan calls for it. Review every selected option before committing your changes. The wizard can create or update connectors, organization relationships, OAuth settings, and general hybrid service configurations.
Microsoft’s Hybrid Configuration Wizard options explain the settings that affect mail routing and feature coexistence. Avoid rerunning the wizard as a reflex. First, identify exactly what it will change and preserve exports or screenshots of the current configuration.
Autodiscover deserves its own validation. Clients may query internal Active Directory service connection points, internal DNS, external DNS, or Exchange Online endpoints. Split-brain DNS, old service connection points, and stale virtual directory URLs can create a problem that appears only for remote users or newly built devices.
Review the current Autodiscover service design and verify your intended namespace model. If an on-premises namespace remains in use, its certificate, DNS records, reverse proxy path, and load balancer health checks must point to your working Exchange Server Subscription Edition servers.
OAuth supports modern hybrid features such as free/busy and mailbox move functions. Check the existing Exchange authorization configuration by running these commands in the Exchange Management Shell before changing your servers:
Get-AuthConfig | Format-List CurrentCertificateThumbprint,NextCertificateThumbprint,ServiceName
This read-only check confirms which OAuth certificate Exchange uses and whether a next certificate has been staged. An expired, missing, or unpublished authorization certificate can break hybrid features even if SMTP mail flow remains healthy.
Use an approved test mailbox to verify OAuth connectivity via the Exchange Management Shell:
Test-OAuthConnectivity -Service EWS `
-TargetUri https://outlook.office365.com/ews/exchange.asmx `
-Mailbox hybridtest@contoso.com | Format-List
This tests whether the on-premises Exchange server can authenticate to the Exchange Online EWS endpoint for the named mailbox. Run it before and after the migration, then investigate failed output rather than dismissing warnings.
Audit Certificates, Connectors, and Mail Flow
A valid TLS certificate acts as the identity card for every HTTPS and SMTP connection into or out of your messaging environment. An Exchange Server SE deployment may inherit an existing TLS certificate during an in-place upgrade, while a replacement server requires an imported or newly issued certificate. Regardless of the chosen path, you must inspect all host names, expiry dates, private key availability, and service assignments.
Use this command to review installed certificates:
Get-ExchangeCertificate | Format-Table Thumbprint,Subject,CertificateDomains,Services,NotAfter -AutoSize
The output confirms which certificate Exchange has assigned to IIS and SMTP, the namespaces it covers, and its expiration date. Compare every listed name with Autodiscover records, Outlook URLs, SMTP connector FQDNs, and any relay host names used by applications.
Microsoft’s Exchange certificate guidance is useful when deciding whether to renew, import, or replace a certificate. Keep the federation certificate separate in your planning. It has a different role and should not be replaced casually as part of a public TLS certificate renewal.
Mail flow testing must include more than a message sent between two employee mailboxes. Test each route that carries business mail:
- Exchange Online to external recipients through the normal outbound route.
- External senders to Exchange Online recipients.
- Exchange Online to any remaining on-premises mailbox.
- On-premises mailbox to Exchange Online mailbox.
- On-premises SMTP relay applications to internal and external recipients.
- Messages that use centralized mail transport, if enabled.
- Large attachments, encrypted messages, and messages subject to transport rules.
- Messages through secure email gateways, journaling services, and archive connectors.
Inspect Exchange Online inbound and outbound connectors in the Exchange admin center. Check their smart-host values, TLS certificate name, sender or recipient domain restrictions, and enabled state. Then, compare these settings with the matching send and receive connectors on your source servers, such as Exchange Server 2019 or Exchange Server 2016.
Connector configuration must agree at both ends. For example, an Exchange Online outbound connector may expect a TLS name that the replacement Exchange server certificate does not contain. A message trace may then show a connector failure while internal testing appears normal.
For a basic on-premises transport check, run:
Test-Mailflow -TargetEmailAddress hybridtest@contoso.com
This submits a test message through Exchange transport and reports delivery latency. It confirms local transport processing, but it does not replace external route testing or Exchange Online message tracing.
Execute the Exchange Server SE Migration in Controlled Stages
A well-run migration separates preparation, installation, cutover, and validation. The ultimate goal is achieving a zero downtime migration by carefully staging your work. Avoid combining an Exchange upgrade with a namespace redesign, firewall replacement, or load balancer refresh in one maintenance window. When several components change together, finding the source of a failure takes far longer.
For an in-place upgrade, place your server into maintenance mode and confirm backups and health checks before starting Setup. For a replacement migration, install the new Exchange SE servers, apply the approved CU and security update level, configure certificates and URLs, then add them to load balancer pools only after health validation.
Use a staged execution checklist:
- Freeze unrelated Exchange, Active Directory, DNS, and load balancer changes.
- Capture server health, queue status, connector configuration, certificates, virtual directories, and hybrid settings.
- Verify backup completion and test restoration procedures against the recovery design.
- Remove the server from client traffic or load balancer rotation when the maintenance plan requires it.
- Install or upgrade Exchange SE using the Microsoft-supported path for the exact source build.
- Reapply approved configuration items that do not persist automatically, including certificates, URLs, load balancer settings, and monitoring agents.
- Run HCW only after reviewing current requirements and the changes it will apply.
- Return servers to service gradually, then test each hybrid workload before expanding traffic.
- Decommission Exchange 2016 or 2019 servers only after verifying the new environment is stable and fully operational.
For a Database Availability Group, use a maintenance sequence that respects your copy health and activation preference rules. Confirm database copies are healthy before putting a member into maintenance. Never assume a database copy is usable because its status looks mounted somewhere else.
Check transport queues throughout the work. Rising submission, retry, or unreachable queues often reveal DNS, certificate, connector, or network problems before users report missing mail.
Monitor, Back Up, and Define Rollback Before Cutover
Monitoring should cover user experience and service dependencies throughout the migration. Watch HTTPS health probes, SMTP queues, CPU, memory, disk latency, database copy health, certificate expiration, Windows event logs, and Exchange-managed availability alerts. It is also critical to monitor the health of any remaining Exchange Server 2019 nodes during coexistence. Additionally, monitor Entra Connect or Cloud Sync exports, because a directory synchronization failure can create recipient issues hours after the Exchange change.
Back up Exchange with an application-aware, VSS-capable process that your specific version and backup vendor support. Confirm that your backups cover databases, logs, and the recovery information required by your documented process for Exchange Server Subscription Edition. Hypervisor snapshots are not a substitute for a supported Exchange recovery plan.
Rollback depends on the migration type. A replacement deployment can often retain old servers outside production traffic while the new servers are validated. An in-place upgrade has a narrower recovery path, so document the approved restore or recovery method before beginning.
Your rollback record should identify the decision owner, success criteria, stop conditions, backup location, DNS reversal steps, load balancer changes, certificate bindings, connector settings, and communication plan. Set a clear deadline for the go or no-go decision.
Frequently Asked Questions
Can I perform an in-place upgrade from Exchange Server 2016 to Exchange Server Subscription Edition?
No, there is no direct in-place upgrade path from Exchange Server 2016 to Exchange Server Subscription Edition. Organizations must first upgrade to a supported version of Exchange Server 2019 or perform a side-by-side replacement migration.
Is it possible to remove all on-premises Exchange servers after moving to Exchange Server Subscription Edition?
If your organization synchronizes identities from an on-premises Active Directory to Microsoft 365, you must maintain at least one supported Exchange server. This server is required to manage recipient objects and Exchange-related attributes, as these remain authoritative on-premises.
How does the subscription model affect my existing licensing?
Exchange Server Subscription Edition requires either active Software Assurance or a subscription license to remain compliant. You should review your current Microsoft Product Terms and consult with your licensing representative to confirm your entitlement before starting your deployment.
Why is the Hybrid Configuration Wizard (HCW) important during an upgrade to Exchange SE?
Running the current version of the HCW ensures that your hybrid connectors, OAuth authentication, and organization relationships are correctly aligned with the new server environment. Always review the changes the wizard proposes before applying them, as improper configuration can disrupt mail flow and cross-premises features like free/busy lookup.
Final Checks for a Supported Hybrid Exchange Service
A successful Exchange Server Subscription Edition migration leaves hybrid services stable, documented, and supportable. Confirm the exact Exchange build, Windows Server level, licensing position, and Hybrid Configuration Wizard behavior against current Microsoft documentation before each production change. Following these steps ensures a supported path for those moving from Exchange Server 2016 or 2019 to the latest platform.
The strongest migration plan treats on-premises Exchange as an active service, even when Exchange Online hosts most mailboxes. Hybrid reliability depends on the less visible pieces, including identity, TLS, Autodiscover, OAuth, connectors, monitoring, and tested recovery procedures.
