Exchange SE CU2: the deadline with no date on the calendar

Microsoft has not published a date for Exchange Server SE CU2, but it is a deadline all the same: CU2 setup will refuse to install while any unsupported Exchange server, including Exchange 2016 or 2019, both out of support since 14 October 2025, remains in the organisation. Legacy servers must be fully decommissioned first.

Every other Microsoft end-of-support event comes with a date that can go in a project plan. This one does not. The trigger is a cumulative update whose release window Microsoft has already moved once, and when it ships, organisations that still have an Exchange 2016 or 2019 server in the environment will find themselves locked out of updates to the very product they upgraded to.

What exactly will Exchange Server SE CU2 block?

Exchange Server Subscription Edition (SE) can currently coexist with Exchange 2016 and 2019 in the same organisation, which is what makes migrations possible at all. Microsoft is deliberately closing that door in stages. SE RTM setup already blocks coexistence with Exchange 2013. CU2 goes much further, and Microsoft's wording is unambiguous:

Because Exchange 2016 and Exchange 2019 both left support on 14 October 2025, they are exactly what that sentence describes. Microsoft's Exchange Team blog spells out the consequence: to install Exchange SE CU2 or anything later, every older version of Exchange Server must first be decommissioned and removed from the organisation. Removed means properly uninstalled so the server no longer exists in the Exchange organisation. A legacy box that has been switched off but never uninstalled still counts, because setup checks what is registered in the organisation, not what happens to be powered on.

When is the deadline, if there is no date?

Here is the published timeline as at July 2026, and it is worth being precise about what Microsoft has and has not committed to. Exchange Server SE RTM has shipped. CU1 is targeted for the second half of calendar year 2026, and will be the first SE release to introduce new features. CU2 is targeted for the first half of calendar year 2027. No exact day has been published for either release, and Microsoft revised both windows in a May 2026 update to its upgrade blog, so the targets have moved once already.

There is a second undated deadline stacked behind the first. Exchange Server SE RTM does not require a new product key, but Microsoft has flagged that a future cumulative update will introduce a new product key requirement. Which CU, and when, is unannounced; Microsoft says the documentation will be updated when the requirements are available. Organisations planning SE deployments should expect a licensing checkpoint at some point in the CU stream and keep their subscription position tidy ahead of it.

What happens to organisations that keep a legacy server too long?

Nothing breaks on the day CU2 ships. That is precisely the trap. Mail keeps flowing, and the SE servers keep running whatever CU they already have. What stops is the ability to move forward: setup will refuse CU2 and every later release until the last legacy server is fully decommissioned.

• The SE servers freeze on RTM or CU1 while the product moves on, and over time they fall out of the servicing window that Exchange security updates are built for.
• The organisation keeps paying for the subscription that Exchange SE requires, since staying licensed means maintaining either qualifying cloud subscription licences or Software Assurance, while being unable to install the updates that subscription exists to deliver.
• The Exchange 2016 or 2019 boxes themselves have had no security updates since support ended, apart from a one-off six-month Extended Security Update program Microsoft announced, a window that has since passed. Every month they remain is accumulating unpatched exposure on an internet-facing workload with a long history of serious vulnerabilities.
• The blocked state compounds: the longer the legacy decommission is deferred, the further behind the SE servers drift, and the larger the eventual catch-up jump becomes.

Microsoft has also been explicit that it is not extending the end-of-life dates for Exchange 2016 or 2019 and is not offering ongoing extended support for either version. There is no rescue package coming. The exit paths are the ones already published.

What is the upgrade path from Exchange 2019?

For Exchange 2019 the path is genuinely straightforward. 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: same servers, same hardware, same Windows installation. An organisation on CU13 or earlier updates to CU15 first, then performs the in-place upgrade to SE. For a typical Australian business with one or two 2019 servers, this is a scheduled change window, not a migration project.

Why is Exchange 2016 the harder problem?

There is no in-place path from Exchange 2016. Moving to SE requires what Microsoft calls a legacy upgrade: build a new server, install Exchange SE on it, join it to the organisation, move every mailbox and resource across, then uninstall the 2016 servers. Legacy upgrades are also what Microsoft prescribes whenever an organisation is moving to new hardware or a newer version of Windows Server, and in practice a 2016 exit usually involves both, because in-place upgrades of the Windows operating system underneath an installed Exchange server remain unsupported.

Two details from Microsoft's guidance matter for planning. First, do not detour through Exchange 2019: since both 2016 and 2019 are now out of support, Microsoft's stated best practice is to migrate from 2016 directly to Exchange SE rather than installing new 2019 servers along the way. Second, the decommission is part of the deadline, not an afterthought; Microsoft's own upgrade table says to decommission Exchange 2016 before Exchange SE CU2. Procuring hardware, building Windows Server, installing SE, moving mailboxes over regional bandwidth and formally uninstalling the old servers is a months-long program for many businesses. Started in late 2026, it collides with a CU2 window that opens in early 2027.

Is moving to Exchange Online the simpler exit?

For many organisations, yes. Migrating mailboxes to Exchange Online removes the CU treadmill, the coexistence rules, the future product key checkpoint and the hardware refresh cycle in one move, and Microsoft lists it as a standard way to retire ageing Exchange infrastructure. If the mailboxes were staying on-premises mainly out of inertia, this deadline is the natural moment to reassess.

But the businesses still running on-premises Exchange in Australia in 2026 usually have a reason: regulatory or contractual requirements to keep mail infrastructure on-premises, or regional sites on links where a cloud-hosted mailbox is a daily frustration. Those organisations should note that the CU2 rules apply to them regardless of architecture. Microsoft is clear that all Exchange Server customers are affected, whether fully on-premises, hybrid, or running Exchange only for recipient management. Hybrid deployments retain a free Exchange SE licence for recipient management via the Hybrid Configuration Wizard, though updates for that server still require Software Assurance or a qualifying cloud subscription, and Microsoft continues to offer the management tools path that removes the need for a running Exchange server where recipient management is all that remains.

What should Australian businesses do before CU2 lands?

1. 1Inventory every Exchange server in the organisation, including Edge Transport boxes, SMTP relays, hybrid management servers and anything installed years ago and forgotten. The CU2 block applies to what setup finds in the organisation, so the inventory has to be complete.
2. 2Confirm current builds. Exchange 2019 needs CU14 or CU15 to take the in-place upgrade; Exchange 2016 should be on CU23. Anything older needs updating before any path forward opens.
3. 3Choose the destination per server: in-place to SE for 2019, a direct legacy migration to SE for 2016, or a migration to Exchange Online where nothing genuinely requires the mailboxes to stay on-premises.
4. 4Schedule the work against the published windows, with CU1 targeted for the second half of 2026 and CU2 for the first half of 2027. A 2016 legacy migration that includes hardware procurement and mailbox moves needs to start now to finish comfortably inside that.
5. 5Formally uninstall every legacy server once it is empty. Decommissioning is the step that actually clears the CU2 block; a powered-off server that was never uninstalled leaves the organisation exactly where it started.
6. 6Verify the organisation is SE-only before CU2 ships, and confirm the subscription position, either qualifying cloud licences or Software Assurance, ahead of the flagged product key requirement.

Frontrow runs this as a single program for Australian businesses: the server inventory, the per-server path decision, the SE upgrade or legacy migration itself, and the formal decommission that clears the CU2 block, alongside an honest assessment of whether each mailbox still needs to be on-premises at all.