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 lessons learned before starting.
My understanding is that Exchange 2016 cannot be upgraded directly in place to SE. The supported approach is to build new SE servers, configure coexistence, move mailboxes and resources to the new databases, validate everything, and then decommission the Exchange 2016 servers. The original mailboxes remain available until the move completes, but after the legacy servers are removed there is no simple rollback; recovery would require restoring from backups.
Another possible route would be to migrate to Exchange 2019 first and then upgrade those servers to SE, although I understand that in-place upgrades have significant limitations and may be blocked depending on the versions involved.
I'm also planning to account for mailbox and archive sizes, Active Directory schema updates, certificates, connectors, virtual directories, client compatibility, backups, public folders, SMTP relay applications, and hybrid configuration. Public folders may need to be handled separately or converted to shared mailboxes.
For anyone who has completed a similar migration, what prerequisites or problems did you encounter? Were there any issues with authentication, Outlook clients, mail flow, public folders, or the final decommissioning that you would handle differently?
3 Answers
Make the server names, certificates, and virtual directory URLs line up as closely as possible before moving users. Inconsistent URLs or certificate names can cause Outlook to bounce between servers, produce warnings, or repeatedly request credentials during coexistence.
I would also treat public folders as a separate workstream. They can complicate an otherwise predictable mailbox migration, so document their dependencies and decide whether they should be retained or moved to shared mailboxes before scheduling the main cutover.
One practical route is to build a new Exchange 2019 DAG, move the remaining on-premises mailboxes from 2016 to it, remove the old 2016 servers, and then perform the supported upgrade path from 2019 to SE if the installed versions meet the requirements. The important point is that Exchange 2016 does not have a direct in-place upgrade to SE; building new servers is the safe and supported migration method.
Do not treat rollback as a normal part of the plan. Keep verified AD, Exchange, and database backups, but focus on thorough pilot testing, application relay testing, hybrid configuration validation, and a controlled decommissioning process instead.
A structured inventory and pilot migration helped us the most. Before building the new servers, we recorded the AD and forest functional levels, Exchange versions and cumulative updates, mailbox and archive sizes, shared and disabled mailboxes, certificates, connectors, mail flow, backup status, and client versions.
We then built the new servers, installed the required prerequisites, imported the certificates, matched the virtual directory URLs, configured receive and send connectors, created the DAG and databases, and tested OWA, Autodiscover, SMTP relay, and mail flow. Moving a small pilot group first exposed issues before the larger batches began. We also monitored the environment for several days after the move before removing the legacy servers.
We saw authentication prompts when clients moved between the old and new server versions. If possible, keep the coexistence window short and test Outlook behavior with real client versions before starting the main batches.
That matches my understanding as well. The 2016-to-2019 stage is a server migration, not an in-place upgrade. Once the old servers are gone, restoring from backup is the recovery option rather than reversing the migration.