Exchange SE migration: the runbook for 2016 and 2019

Exchange 2019 CU14 or CU15 upgrades to Exchange Server SE in place, using the same process as installing a cumulative update. Exchange 2016 has no in-place path: build a new server, install SE into the existing organisation, move every mailbox and public folder across, then formally uninstall each 2016 server before SE CU2 arrives.

Frontrow covered the why in a companion guide: Exchange SE CU2 setup will refuse to install while any Exchange 2016 or 2019 server remains registered in the organisation, and CU2 is currently targeted for the first half of 2027. This guide is the how. Two tracks, one per source version, ending in the same place: an SE-only organisation with nothing left to block the update path Microsoft is keeping supportable.

Has Exchange SE CU1 been released yet?

No. As at 12 August 2026, Exchange Server SE CU1 has not shipped. Microsoft's build table lists SE RTM, released on 1 July 2025, as the only cumulative release, and the security update published on 11 August 2026 was issued for SE RTM. The current published windows, revised on 22 May 2026, target CU1 for the second half of calendar year 2026 and CU2 for the first half of 2027.

For migration planning, two things about CU1 matter. First, it changes nothing about coexistence: Exchange 2016 and 2019 can still exist in the organisation alongside SE CU1, so a migration that is mid-flight when CU1 ships is not in trouble. Second, Microsoft's upgrade table names either SE RTM or SE CU1 as the target server for a legacy migration from Exchange 2016, so there is no reason to wait for CU1 before starting. The door that closes is CU2, and it closes on any organisation that still has a legacy server registered when its administrators want to install it.

What should the inventory cover before anything moves?

Every migration in this guide starts the same way: find every Exchange server in the organisation, including the ones that serve no mailboxes. The CU2 coexistence check runs against what is registered in Active Directory, so a forgotten server is exactly as blocking as a production one.

• Mailbox servers, including every member of any Database Availability Group.
• Edge Transport servers sitting in the perimeter network, which are easy to miss because they do not hold mailboxes.
• SMTP relay boxes that applications, scanners and printers send through, often installed years ago and absent from current documentation.
• Hybrid management servers kept on-premises purely for recipient management after mailboxes moved to Exchange Online.
• Current builds on each server. Exchange 2016 must be on CU23 and Exchange 2019 on CU14 or CU15 before any path to SE opens; anything older gets updated first.
• Everything that touches the servers: certificates and their expiry dates, namespaces and autodiscover records, send and receive connectors, load balancer configuration, backup agents and third-party integrations.
• The licensing position: whether users hold qualifying cloud subscription licences, or the server licences and CALs carry active Software Assurance. Exchange SE requires one or the other, covered in detail below.

How does the in-place upgrade from Exchange 2019 work?

Track A is the short one. Exchange Server SE supports an in-place upgrade from Exchange 2019 CU14 or CU15, and Microsoft describes the process as identical to installing a cumulative update: the same server, the same hardware, the same Windows installation. An organisation on CU13 or earlier updates to CU15 first, then runs SE setup as the upgrade.

Microsoft has been unusually direct about the risk profile. In engineering terms it describes SE RTM as a re-branded Exchange 2019 CU16: built from CU15 plus the security updates released since, with no feature changes, no new prerequisites and no new hardware requirements. The upgrade carries the risk of a CU installation because that is what it is.

1. 1Confirm the server is on Exchange 2019 CU14 or CU15, with current security updates applied.
2. 2Confirm the licensing position: Software Assurance on the server licences and CALs, or qualifying cloud subscription licences for every user.
3. 3Take a full, verified backup. As with any cumulative update, there is no supported path back to the previous version once setup completes; restore is the rollback.
4. 4Schedule a change window sized like a CU installation. Exchange services are offline on the server being upgraded while setup runs.
5. 5For DAG members, follow the normal CU maintenance procedure: put the server in maintenance mode, move active databases, upgrade, and bring it back. Microsoft confirms in-place upgrade of DAG members is fully supported, one server at a time.
6. 6Verify mail flow, client access and backup jobs after each server, then repeat across the remaining servers.

For a typical Australian business with one or two Exchange 2019 servers, Track A is a scheduled evening's work, not a project. Microsoft's Exchange Server Deployment Assistant will generate a step-by-step checklist for the specific scenario and is worth running even for a single server. The main planning trap is rollback expectation: because the upgrade behaves like a CU, the realistic recovery position for a failed upgrade is restoring the server from backup, and the change record should say so before the window opens.

How does the legacy migration from Exchange 2016 work?

Track B is the project. There is no in-place upgrade from Exchange 2016; Microsoft prescribes a legacy upgrade, which means new servers, mailbox moves and a formal decommission. Microsoft is also explicit that the detour through Exchange 2019 is over: since both 2016 and 2019 are out of support, the stated best practice is to migrate directly from 2016 to Exchange SE rather than installing new 2019 servers along the way.

1. 1Bring every Exchange 2016 server to CU23. Nothing older is a supported migration source.
2. 2Build the destination: new Windows Server installations sized to Microsoft's Exchange 2019 guidance, which SE carries forward unchanged. SE is supported on Windows Server 2019, 2022 and 2025, with Server Core the recommended option; build on the newest, because in-place upgrades of Windows under an installed Exchange server remain unsupported and this build will carry SE for years.
3. 3Prepare Active Directory with SE setup, then install Exchange SE into the existing organisation so it coexists with the 2016 servers during the move. One current gotcha: if a Windows Server 2025 domain controller holds the Schema Master role, Microsoft requires its November 2025 or later cumulative update to be installed before any PrepareAD operation, to prevent a replication issue during the schema extension.
4. 4Configure the new servers to production standard before any mailbox moves: certificates installed, virtual directory URLs and autodiscover set, receive connectors recreated including every application relay permission, load balancing updated.
5. 5Move mailboxes in batches, starting with a pilot group, then working through the estate. Watch move throughput on regional links; the batch schedule for a site on a constrained connection can dominate the whole timeline.
6. 6Move public folders. Modern public folders live in public folder mailboxes, which move between servers in the same organisation the way ordinary mailboxes do; they still need to be in the plan explicitly, along with arbitration and other system mailboxes.
7. 7Cut over mail flow and namespaces: point send and receive connectors, MX or smart host paths, autodiscover and client access names at the SE servers, and confirm nothing still routes through 2016.
8. 8Replace any Exchange 2016 Edge Transport servers with new SE Edge Transport servers and re-establish the Edge subscription; they follow the same rule as every other 2016 box.
9. 9Uninstall every Exchange 2016 server, formally, through the removal process, once it holds nothing and receives nothing.

Hybrid organisations get a choice on the last server. A 2016 box kept only for recipient management can be replaced with an SE server under the free hybrid licence Microsoft provides through the Hybrid Configuration Wizard, noting that updates for it still require Software Assurance or a qualifying cloud subscription. Or the organisation can move to the Exchange Management Tools approach, which manages recipients through PowerShell without any running Exchange server at all, and removes the box from the CU2 equation entirely.

What licensing does Exchange Server SE require?

Exchange Server SE keeps the Exchange 2019 licensing model with one addition: an active subscription position. That means either qualifying cloud subscription licences, such as Microsoft 365 E3 or E5, for every user and device that accesses the server, or Exchange server licences and CALs with Software Assurance maintained. Microsoft notes that E3 and E5 carry Extended Use Rights that include the Office server licences at no additional charge, which is why organisations already on those plans usually take the cloud subscription route even for on-premises servers.

There is no product key change at RTM: an upgraded server keeps functioning without a new key. A future cumulative update will introduce a new product key requirement, with keys and media now retrieved through the Microsoft 365 admin center rather than the retired Volume Licensing Service Center. And despite the name, Subscription Edition performs no online licence validation; once a valid key is entered there are no further checks, and compliance is maintained through the subscription itself.

When is Exchange Online the better exit?

A business at the start of Track B is about to fund new hardware, new Windows Server licences, an SE subscription position and weeks of mailbox moves. If nothing genuinely requires those mailboxes to stay on-premises, the same project effort lands them in Exchange Online instead, with no CU treadmill waiting at the end. The companion guide covers that decision in detail; the short version is that the organisations with a real on-premises requirement know who they are, and everyone else should price both exits before committing to either.

What does a realistic Australian timeline look like?

CU2 is targeted for the first half of 2027, and Microsoft has revised these windows once already. The only safe planning assumption is that CU2 could arrive early in that window, which makes the end of 2026 the sensible completion date for legacy decommissions.

• Track A from Exchange 2019: a few weeks end to end, most of it scheduling. Licensing confirmed, backup verified, one change window per server. Comfortably done inside 2026 from a standing start.
• Track B from Exchange 2016, single site: hardware procurement is the long pole and often takes weeks before anything can be built, then come the Windows and SE builds, coexistence configuration, batched moves and cutover. A program measured in months that needs to start now to finish inside 2026.
• Track B with regional sites: add the bandwidth reality. Mailbox batches over a constrained regional link can stretch a move phase from weeks to months, and the schedule should be built from measured throughput, not assumed.
• The decommission itself: budget real time at the end for draining, verifying and uninstalling each 2016 server. It is the step that clears the CU2 block, and the one most often left dangling when a project runs late.

Frontrow runs both tracks for Australian businesses as one engagement: the inventory, the per-server path call, the SE build and mailbox moves or the in-place upgrade windows, and the formal uninstalls at the end, with the licensing position squared away before the first server is touched.