Retiring on-prem Exchange after a full migration

Every mailbox has been in Exchange Online for a year. The Exchange server in the corner still has to be patched, still needs a certificate, and still gets flagged in every security review. Why is it there? Because in a hybrid organisation where identities are synced from AD, the source of authority for mail attributes is on-prem, and Microsoft's position for a decade was that you needed an Exchange server to edit them supportably. That position has changed, and the last server can now go — provided you check what else it is quietly doing.

The hybrid deployment guide covers how you got here; this is the way out.

What the last server is actually doing

Inventory before anything else. On the server, and in the surrounding environment, look for:

• Recipient management. Admins using the Exchange admin center or the on-prem shell to create mailboxes, set proxy addresses, hide users from the address list, or manage distribution groups. This is the big one.
• SMTP relay. Printers, scanners, monitoring systems, line-of-business apps sending through the server's receive connector. Get-ReceiveConnector and, more usefully, the SMTP protocol logs for the last month show who still connects.
• Public folders. On-prem public folder mailboxes still hosting content, or a legacy public folder hierarchy that was never migrated.
• Mail flow. Is any inbound or outbound mail still routed through the server — MX pointing at it, or the outbound connector in Exchange Online sending to it for certain domains?
• Autodiscover or EWS still resolving to it for any client, device or room system.
• Journaling, third-party archiving, or fax integrations bound to it.
• Unified messaging, Skype for Business integration, or anything else from a previous era.

The SMTP relay and public folder items are where retirements stall for months, so get their inventories first.

Step 1: recipient management without the server

Since Exchange 2019 CU12, and continuing in Exchange Server Subscription Edition, Microsoft supports installing the Exchange Management Tools on a domain-joined workstation or server without a running Exchange server, to manage recipients in AD. The tools provide the recipient cmdlets (Enable-RemoteMailbox, Set-RemoteMailbox, Set-DistributionGroup, and the rest) that write the right attributes to AD, which Entra Connect or Cloud Sync then syncs. There is no Exchange admin center in this mode; it is PowerShell only, plus a one-time Add-PermissionForEMT step and a cleanup script that removes the old server's objects from AD once it is gone.

If your admins manage recipients through the EAC by habit, this is the change that needs handling. Options: train them on the cmdlets, wrap the common operations in a small script or a form, or use a third-party recipient-management tool that writes the same attributes. All are fine; "we will just edit attributes in AD Users and Computers" is not, because it is unsupported and gets proxy addresses subtly wrong.

Alternatively — and this is the cleaner long-term answer — move the source of authority for mail attributes to the cloud by converting objects to cloud-managed. That is a bigger project involving retiring AD DS altogether, and for most organisations the management-tools route is the pragmatic step.

Step 2: relay

Every device relaying through the server needs a new path. Choices, from best to worst:

• Direct send to Microsoft 365 (SMTP to the tenant's MX endpoint, no authentication, internal recipients only).
• SMTP relay via an inbound connector in Exchange Online, restricted by the sender's public IP, for devices that must send externally.
• SMTP AUTH client submission for devices that can authenticate — increasingly hard as basic authentication is retired; check current guidance.
• A small on-prem relay (IIS SMTP is gone; a Postfix box or a hardware appliance) that forwards to Exchange Online, for a mass of legacy devices you cannot reconfigure individually.

The guide on mail flow and connectors covers the connector setup. Move devices one at a time and watch the on-prem protocol logs go quiet.

Step 3: public folders and the rest

Migrate on-prem public folders to Exchange Online (a batch migration, documented and slow) or to SharePoint or shared mailboxes if the content deserves it. Remove any journaling or archiving integration. Re-point Autodiscover DNS to Exchange Online if it is not already. Confirm no outbound connector in Exchange Online still targets the server, and that the on-prem send connector is not carrying any real traffic.

Step 4: the removal sequence

Only when every item in the inventory has a new home:

1. Confirm all mailboxes are in Exchange Online: Get-Mailbox -ResultSize Unlimited on-prem returns nothing except arbitration and audit mailboxes. Confirm all public folders are migrated.
2. Change the hybrid configuration: in the Exchange Online side, remove the on-prem organisation relationship and the hybrid connectors that reference the server (inbound and outbound). Turn off OAuth configuration between the organisations. Do this deliberately; it is not the Hybrid Configuration Wizard running in reverse.
3. Install the management tools on a management server and run the documented preparation cmdlet.
4. Uninstall Exchange from the server (a clean uninstall, not a rebuild of the box). Uninstalling removes the server object from AD properly; formatting the disk does not.
5. Run the management-tools cleanup script to remove the remaining organisation-level objects that the uninstall leaves behind.
6. Remove the server's DNS records, certificates, firewall rules and the Entra Connect Exchange hybrid writeback feature if you no longer need it.

Test after step 2 and after step 5: create a mailbox with Enable-RemoteMailbox, sync, confirm it appears in Exchange Online with the right addresses.

What needs support, and what has downtime

Microsoft support is not required for any of this, though a hybrid organisation with unusual history — multiple past migrations, an organisation relationship to a tenant you no longer own — sometimes surfaces stale objects that support can clear faster. Downtime for users is nil; the mailboxes have been in the cloud all along. The risk is entirely in relay and in recipient management, and both are testable before the server is switched off.

One honest note: if you are on Exchange 2016 or 2019, both left support in October 2025, and the only supported on-prem edition now is Subscription Edition, which is licensed by subscription. Keeping a running server "just in case" therefore costs real money on top of the operational burden; check the current licensing terms for the management-tools-only scenario, and expect retiring the server to be the cheaper option on every axis.