The last Exchange server can go: what changed in 2026

In many organisations there is an Exchange server nobody needs any more. The mailboxes have long been in the cloud, work happens through Exchange Online, and still the old machine runs on, gets patched, backed up and licensed. Until now the reason was compelling. Since 2026 it no longer is.

Why the last server had to stay

Anyone keeping user accounts in the local Active Directory and synchronising them to the cloud also manages the mailbox-related values locally, from additional email addresses and archive status through to forwarding and sender lists. The Exchange management tools were the intended route for editing them, and in practice that meant an existing Exchange server. So it stayed.

Microsoft documented it that way for years: one server stays, even when no mailbox sits on it. For operators that meant effort without return (including the duty to keep it current), and once support has ended that is no longer possible. Running an Exchange server reachable from the internet without receiving security updates is a risk that grows with every month.

What has changed

Microsoft has moved the management of these attributes into the cloud. Mailboxes can be marked as cloud-managed; the Exchange values are then maintained in Exchange Online and written back from there into the local Active Directory. The technical term is writeback.

The process has two directions, and they belong kept apart. Upwards nothing changes: the identity (name, sign-in, groups) still comes from the local Active Directory. For the Exchange values, by contrast, responsibility moves to the cloud, they are maintained there, and Entra Cloud Sync brings them back down into Active Directory. One point matters here: what gets written back is a defined subset of the Exchange values, not all of them. It covers the email addresses (proxy addresses and the primary address) and the freely usable custom fields that grown environments often hang line-of-business applications on. Other values can be edited in the cloud but do not reappear in the local directory. Which ones those are belongs checked field by field against the Microsoft documentation before any migration.

One prerequisite tends to be glossed over in announcements: writeback requires Entra Cloud Sync. Anyone synchronising with the classic Entra Connect Sync today, and that is most organisations, does not have to replace it for that reason. Microsoft explicitly describes the two as running side by side: Connect Sync keeps handling directory synchronisation exactly as before, Cloud Sync is installed in addition and handles only the writeback of the Exchange fields. What does need checking is the version: Connect Sync must be current, or synchronisation fails on the converted mailboxes.

That removes the reason to keep the last server. On-premises applications that read their address data from Active Directory can keep working, which is precisely what the writeback is for. „Can" is to be taken literally: whether it holds in a given case depends on which fields the application reads, whether those belong to the written-back set, and how sensitive the application is to the delay. That is exactly the checking job before the change.

What this means in practice

• One fewer server to patch, back up and monitor, and one fewer that has to be updated under time pressure when a vulnerability appears.
• Less attack surface: an internet-facing Exchange server is a known target, and a server that has been removed drops out as an entry point.
• Clearer arrangements: mailbox administration happens in one place, not two.
• The prerequisites remain, and they are specific: the local Active Directory must carry the Exchange schema. Entra Cloud Sync must be set up in addition, with a provisioning agent from version 1.1.1107.0. And anyone running Entra Connect Sync needs at least version 2.5.190.0 there. With an older one, synchronisation keeps trying to populate the converted mailboxes from below and fails doing so. All three points are to be verified, not assumed.

On maturity, and this belongs before any planning: both stages (cloud-side management and writeback) are now generally available, so no longer in preview. In the admin centre, however, the configuration you have to create still carries the label „Preview". That is not a contradiction but an indication of how recent this is: anyone adopting it should test in a lab first and switch the server off only once it demonstrably holds for their own configuration.

One switch deserves particular care: the change can be enabled per mailbox or for the entire tenant. The tenant-wide variant belongs enabled only once every mailbox really is in the cloud and no new ones are created on premises. Enabling it too early produces accounts that no longer arrive cleanly in Exchange Online. That state is unsupported and cannot be undone without help.

The pressure comes from another direction anyway: support for Exchange Server 2016 and 2019 ended on 14 October 2025, no more security updates. Anyone wanting to keep the last server has to move it to the Subscription Edition, which has since been the only supported on-premises version. That puts the question differently than before: not „why switch it off", but „why install another version for a task the cloud can take over".

What to settle before the server goes off

Switching off is the last step, not the first. Beforehand it belongs checked what still points at the server, and in grown environments that list is regularly longer than expected.

• Applications and devices that send email through the server: scanners, ERP systems, monitoring, time recording. They need an alternative route first, depending on the case a sending account in Exchange Online, a relay or direct send, each with its own limits on volume and sender validation.
• The directory record Outlook uses to find its settings (AutoDiscover, or the Service Connection Point in Active Directory). If it still points at the old server, Outlook looks there, even when nothing is left.
• Connections and records referring to its name: in DNS, in certificates, in firewall and connection filter rules.
• System mailboxes, public folders and distribution groups: cloud-side management including writeback applies to user mailboxes. Distribution groups and contacts originating in the local directory are not covered by it. Managing those from the cloud is a separate step of its own. What still sits here determines the order of work.
• The hybrid connection itself: send and receive connectors, the trust between on-premises and cloud, and the configuration the hybrid wizard created. It belongs withdrawn in order, otherwise setup blocks or routes remain in the tenant that nobody serves any more.
• The removal itself: an Exchange server is uninstalled through its setup, not by deleting the virtual machine. Which route is the supported one depends on what still sits on the server. Microsoft has its own guide for this, and it belongs read beforehand.
• The way back: as long as it is not confirmed that everything runs without it, the server is only switched off, not dismantled. An observation period of a few weeks is not over-caution but the time it takes for monthly and quarterly runs to pass through once.

We check these dependencies, move the administration and accompany the decommissioning, as part of a Microsoft 365 migration or as a step of its own. How hybrid environments play out otherwise is under hybrid infrastructure. A first conversation costs nothing.

Status: August 2026, verified against the Microsoft documentation. The set of fields written back, the prerequisites and the volume limits have changed several times in recent months and will change again. Before making a change, look up the current state, not this article.