Exchange Server Subscription Edition (Exchange SE) is an architectural decision as well as a software upgrade. Before changing binaries, establish why Exchange remains on-premises, which workloads depend on it and how the organisation will maintain a supported configuration. A server hosting production mailboxes has different requirements from one retained for application relay or hybrid recipient administration.

In this final part of the series, we bring together hybrid connectivity, mail routing, authentication, automation and troubleshooting. The objective is a supportable Exchange environment with explicit dependencies, controlled change and evidence that business services still work after the transition. Use Microsoft Learn’s current release information and supportability matrix as implementation gates, rather than treating an older project plan as permanent guidance.

1. Establish the target architecture and support position

Exchange SE remains Exchange Server software operated by your organisation. It does not move mailboxes into Exchange Online or transfer responsibility for operating systems, certificates, backups, monitoring and security updates to Microsoft. Subscription Edition changes the product’s servicing and licensing context; it does not remove the operational responsibilities of an on-premises deployment.

Microsoft lists 14 October 2025 as the end-of-support date for Exchange Server 2016 and Exchange Server 2019. Treat those dates separately from technical upgrade eligibility: a version might appear in a documented migration path without being an acceptable long-term production state. Validate the support position of every server that will remain during the transition.

Document the intended end state before choosing an upgrade method. Confirm licensing entitlement, server and user access requirements, and any subscription or Software Assurance conditions through the organisation’s licensing process. Do not infer entitlement from a successful installation or assume that every Microsoft 365 subscription provides identical rights.

On-premises mailboxes: retain a complete Exchange service design covering availability, storage, client access, transport, backup and recovery.

Hybrid workloads: identify whether Exchange provides mailbox hosting, migration connectivity, centralised mail transport, application relay or several of these functions.

Recipient administration only: assess Microsoft’s management-tools-only approach before committing to another running Exchange server.

The management-tools-only option has specific prerequisites and is not a substitute for mailbox hosting or SMTP relay. Microsoft’s documented procedure also distinguishes shutting down the last Exchange server from uninstalling it. Do not uninstall that server as an improvised directory-clean-up step.

2. Choose an upgrade path for the exact target release

Exchange SE introduced an in-place upgrade path from Exchange Server 2019 CU14 and CU15 to Exchange SE RTM. This is an important departure from the traditional requirement to deploy another server and move mailboxes when changing major Exchange versions. However, an RTM upgrade statement is not a promise that every later Exchange SE release accepts every earlier source build.

Record both the installed build and the intended target build, then check the current release documentation. Cumulative update prerequisites and coexistence restrictions can change. Do not select installation media solely because it is the newest download, and do not deploy an older release merely because it permits coexistence without planning the subsequent servicing steps.

Exchange Server 2016 does not have a direct in-place upgrade to Exchange SE. It requires a legacy migration approach involving another Exchange server and mailbox moves, with the intermediate and target versions selected against Microsoft’s current coexistence rules. Older Exchange servers elsewhere in the organisation can also affect Setup eligibility, even when they host no active user mailboxes.

Get-ExchangeServer |
    Format-Table Name, Edition, AdminDisplayVersion, ServerRole -AutoSize

Get-MailboxDatabase -Status |
    Format-Table Name, Server, Mounted -AutoSize

Run these commands in the on-premises Exchange Management Shell. They provide an initial organisation and database inventory, not a complete readiness assessment. Compare the displayed versions with Microsoft’s build-number documentation, and verify the installed security update level on each server; a cumulative update label alone is insufficient evidence of patch compliance.

For database availability groups, follow the documented maintenance and upgrade sequence for the applicable release. Move active workloads away from the server being serviced and verify replication health before proceeding. Temporary version differences during an upgrade must follow the supported procedure; they are not justification for leaving the group indefinitely split across releases.

3. Validate the platform before scheduling Setup

Use the Exchange Server supportability matrix to validate the exact combination of Exchange build, Windows Server version, Active Directory environment and .NET Framework version. These dependencies must be checked together. A newer operating system or framework is not automatically supported simply because it is generally available or supported by another Microsoft product.

If the existing operating system is unsuitable, plan an appropriate server replacement or migration rather than combining multiple platform changes into one untested operation. Separating platform replacement from Exchange servicing makes validation and recovery decisions clearer. Check the target release’s prerequisites and Setup requirements before approving the implementation window.

Active Directory: verify replication health, supported directory requirements, required permissions and whether schema or domain preparation is needed.

Server capacity: confirm available disk space, database and log capacity, and the resources needed while workloads run on fewer servers during maintenance.

Dependencies: validate backup software, security software exclusions, monitoring integrations, transport agents and other installed extensions against the target release.

Recovery: confirm an Exchange-aware backup and recovery procedure, including the information required for server recovery and certificate restoration.

Treat cumulative updates as full Exchange installations, not lightweight application patches. Record custom configuration and compare it after the change. Avoid relying on an undocumented collection of modified configuration files, and do not assume that a virtual machine checkpoint provides an adequate Exchange recovery strategy.

Test-ServiceHealth

Get-ExchangeCertificate |
    Format-Table Thumbprint, Subject, Services, NotAfter, Status -AutoSize

Get-Queue |
    Format-Table Identity, Status, MessageCount, NextHopDomain -AutoSize

Run these local service, certificate and transport checks on each relevant server. Investigate unexpected results before upgrading. An unexpired certificate is only one requirement: also confirm its names, trust chain, private key availability and intended service assignment. Similarly, a queue snapshot needs operational context; compare it with normal behaviour rather than imposing an arbitrary universal threshold.

4. Preserve hybrid connectivity, mail routing and recipient services

Inventory the interfaces that connect Exchange to users, applications and Microsoft 365. Include published namespaces, load balancer configuration, Autodiscover, certificates, send and receive connectors, transport rules and hybrid settings. Capture the existing design before making changes so that post-upgrade testing measures intended behaviour rather than merely the absence of obvious errors.

Distinguish an in-place upgrade from a server replacement. Replacing a server introduces dependencies that may reference its name, address or certificate. Applications can continue targeting an old SMTP endpoint even after every user mailbox has moved. Receive connector bindings, permitted source addresses and relay permissions therefore need explicit migration and testing.

Modern hybrid connectivity does not eliminate the transport design. Microsoft’s Hybrid Agent documentation distinguishes the HTTPS-based functions it supports from SMTP mail flow, which does not traverse the agent. Preserve the required SMTP connectivity and certificates independently of migration connectivity. Where topology changes require it, use the current Hybrid Configuration Wizard and validate the resulting configuration.

Get-HybridConfiguration |
    Format-List Domains, Features, ReceivingTransportServers,
        SendingTransportServers, TlsCertificateName

Get-SendConnector |
    Format-List Name, Enabled, AddressSpaces, SmartHosts,
        DNSRoutingEnabled, SourceTransportServers

These commands expose useful configuration references but do not prove end-to-end hybrid health. Test internal delivery, external delivery, Exchange Online-to-on-premises delivery and the reverse path. Where applicable, test free/busy access, mailbox moves and application submissions. Retain message identifiers and timestamps so that failed tests can be investigated across both environments.

For legacy migrations, include arbitration and other system mailboxes in the documented migration and decommissioning procedure, along with any public folder workloads. Moving visible user mailboxes is not sufficient evidence that a database or server can be removed. Complete the relevant Microsoft removal checks before retiring infrastructure.

5. Operate Exchange SE as a continuously maintained service

An Exchange SE deployment needs an ongoing servicing process, not just a successful implementation project. Track cumulative updates, security updates and the applicable support requirements. Maintain a representative validation environment, a change approval process and a clear owner for reviewing Microsoft’s release documentation before each deployment.

Keep service health and security validation distinct. A server can deliver mail while retaining an unsuitable published endpoint, expired secondary certificate or unsupported component. Review client access, administrative access, connector permissions and TLS dependencies against the current Microsoft guidance for the installed release.

Check the prerequisites for protections such as Extended Protection rather than assuming that existing reverse proxies, load balancers or TLS termination arrangements remain compatible. Use the documented deployment guidance and validation process for the exact topology. Do not resolve an upgrade problem by permanently weakening authentication or transport controls without understanding the underlying dependency.

Automation should respect the boundary between on-premises Exchange and Exchange Online. Scripts using Exchange Online management connectivity do not automatically manage local servers or replace the on-premises Exchange Management Shell. Review connection methods, permissions, module dependencies and target environments before reusing automation from earlier parts of this series.

Retain Setup logs and a post-change evidence pack containing version checks, service results, queue observations, database availability group health where applicable, certificate checks and functional test outcomes. This provides a useful baseline for later incidents and helps distinguish an upgrade-related change from a pre-existing configuration issue.

6. Short production-readiness checklist

Architecture approved: the purpose of every retained Exchange server is documented, including relay and hybrid dependencies.

Support and licensing checked: source, intermediate and target releases have been assessed against current documentation and organisational entitlement.

Upgrade route confirmed: the exact source build, target media, coexistence restrictions and sequencing are recorded.

Platform ready: operating system, .NET Framework, Active Directory, capacity and third-party dependencies meet the target requirements.

Recovery prepared: backups, recovery instructions, certificates and decision points are available to the implementation team.

Services tested: mail flow, client access, hybrid functions and application relay have named owners and recorded acceptance results.

Operations handed over: monitoring, patch ownership, documentation and any remaining decommissioning tasks are assigned.

7. Conclusion: upgrade the operating model, not just the version

Exchange Server Subscription Edition provides a supported direction for organisations that retain on-premises Exchange requirements. The strongest implementation starts by proving those requirements, then chooses a documented upgrade or migration route and validates every dependent service.

Across this series, the same architectural principle applies: separate responsibilities and verify the connections between them. Hybrid connectivity, SMTP transport, identity, certificates and server servicing are related, but success in one does not establish health in the others. A well-run Exchange SE environment makes those boundaries explicit and maintains evidence that they continue to work.

What’s new in Exchange Server: Exchange SE capabilities and upgrade context

Exchange Server supportability matrix: platforms, dependencies and support dates

Exchange Server build numbers and release dates

Upgrade Exchange to the latest cumulative update

Manage hybrid Exchange recipients using management tools

Microsoft Hybrid Agent: supported capabilities and limitations

Originally published on Solution Savy. Need help with this? Book a consultation.