I'm preparing to migrate a hybrid on-premises Exchange 2016 environment to Exchange Server Subscription Edition and want to identify the major prerequisites, risks, and common problems before starting. My understanding is that Exchange 2016 cannot be upgraded directly in place to SE, so the supported approach is to build new SE servers, establish coexistence, move mailboxes and resources, validate the environment, and then decommission the Exchange 2016 servers. The source mailboxes should remain available until each move completes, but once the old servers are removed there is no ordinary rollback path beyond restoring backups.
I'm also considering moving to Exchange 2019 first and then upgrading to SE, although I understand that in-place upgrades are blocked or otherwise not the preferred migration method. Areas I'm reviewing include mailbox and archive sizes, Active Directory schema preparation, certificates, virtual directory URLs, mail flow, connectors, DAG configuration, SMTP relay, hybrid configuration, public folders, client compatibility, and backup validation. Public folders may need to be handled as a separate project rather than converted during the main server migration.
For anyone who has completed a similar migration: what caused the most trouble, what should be tested during coexistence, and what would you do differently?
4 Answers
A thorough inventory and staged testing made the biggest difference for us. We collected the AD domain and forest functional levels, server and CU versions, mailbox and archive counts, mailbox sizes, shared and disabled mailboxes, mail flow routes, certificates, client versions, and backup status before building anything.
We then prepared new SE servers, installed the current release and updates, imported and assigned the certificates, matched the virtual directory URLs, configured connectors and receive settings, created the DAG and databases, and tested OWA, Autodiscover, SMTP relay, and mail flow. We moved a small pilot group first, recorded the results, and only then migrated the remaining mailboxes. After updating the hybrid configuration and application endpoints, we monitored the environment for about a week before removing the Exchange 2016 servers.
One important detail: test Extended Protection in advance, but be careful when enabling it during coexistence. We also had to clean up old certificates and service-principal configuration after the migration.
Before choosing between a direct new-server migration and the Exchange 2019 stepping-stone approach, confirm how many mailboxes and resources are still hosted on-premises. Include archives, shared mailboxes, public folders, application relay, certificates, connectors, and any unusual mailbox sizes in the inventory. Those details determine how long the coexistence period and final cleanup will take.
Another workable route is to build a new two-node Exchange 2019 DAG, move the remaining on-premises mailboxes from Exchange 2016, remove the old servers, and then perform the supported upgrade from 2019 to SE. That gives you a clean migration off 2016 before the SE upgrade.
In-place upgrading Exchange 2016 directly is not simply discouraged—it is blocked. Building new servers is the practical path. Also, don’t plan around a conventional rollback after decommissioning the old environment; Exchange migrations are normally validated through pilot moves, coexistence testing, and backups rather than reversed after cleanup.
Your overall plan is sound, but make the new server's virtual directory URLs and certificates match the existing Exchange 2016 configuration before moving users. Otherwise, Outlook clients can bounce between servers and produce certificate warnings or repeated prompts during coexistence.
I would also keep public folders separate from the server migration. Converting them to shared mailboxes may be a good long-term direction, but combining that work with the Exchange migration makes troubleshooting much harder. Treat it as its own project with its own testing and cutover plan.
We saw authentication prompts when clients moved between the old and new versions, even though the same issue had not appeared in our earlier migration. If possible, keep the transition window short and test Outlook clients during the pilot rather than waiting until the end.