You Can Finally Decommission the Last Exchange Server: What Exchange SOA Transfer Actually Changes

If every mailbox is already in Exchange Online, why are some organizations still running an Exchange Server on-premises? For years there was a frustratingly legitimate answer: because Active Directory was still authoritative for Exchange recipient attributes. You could move the mailboxes, point MX at Exchange Online, and let users live their entire working lives in Outlook and Teams — and somewhere in the server room sat an Exchange Server whose main job was effectively "please keep me patched because somebody might need to change proxyAddresses." That architecture is finally changing. Microsoft now supports transferring the Source of Authority (SOA) for Exchange attributes to the cloud, and for organizations that meet the prerequisites, that removes the recipient-management dependency on the last on-premises Exchange Server and provides a supported path to actually uninstall it.

There are, however, enough caveats that I would not recommend seeing Set-Mailbox -IsExchangeCloudManaged $true and immediately running it against 5,000 users. The command is easy. Knowing whether your environment is ready is the project.

Why did we need the last Exchange Server in the first place?

The mailbox itself may be in Exchange Online, but a synchronized user's Exchange properties historically remained authoritative in on-premises Active Directory. Think about properties such as:

• Email addresses and aliases
• Custom Exchange attributes
• Address-list visibility
• Mail routing properties
• Various recipient settings

For directory-synchronized recipients, Microsoft did not support simply opening ADUC or ADSI Edit and manually changing the Exchange attributes you cared about. The supported management path remained the Exchange recipient-management cmdlets: Set-RemoteMailbox, Set-DistributionGroup, Set-MailContact.

That created what Microsoft now calls the Last Exchange Server problem. Your mailboxes were in Microsoft 365. Your users were in Microsoft 365. Your administrators were spending most of their time in Microsoft 365. But Exchange recipient management was still tied to Active Directory.

"Didn't Microsoft already let us shut down the last Exchange Server?"

Yes. And this is where things get confusing.

In 2022, Microsoft introduced the updated Exchange Management Tools approach with Exchange Server 2019 CU12. That allowed qualifying organizations to shut down their running Exchange Server and manage recipient attributes using Exchange PowerShell management tools from a domain-joined computer.

Useful? Absolutely. The same thing as SOA transfer? No.

Under the Management Tools model, Exchange-related authority still lives on-premises. The Exchange configuration objects and security groups in Active Directory also have to remain. Microsoft explicitly warns organizations using that model not to uninstall the last Exchange Server, because the Management Tools depend on those Active Directory objects.

SOA transfer changes the architecture rather than simply changing where you run the management cmdlets.

What Exchange SOA transfer actually does

For a synchronized mailbox, Exchange Online now exposes a property called IsExchangeCloudManaged. By default it is false. To transfer that mailbox's Exchange-attribute Source of Authority to the cloud:

Set-Mailbox -Identity [email protected] -IsExchangeCloudManaged $true

# Verify:
Get-Mailbox -Identity [email protected] |
    Format-List Identity,IsExchangeCloudManaged

Once that property is true, supported Exchange attributes stop accepting their authoritative values from on-premises synchronization and are managed through Exchange Online instead. An administrator can now set a custom Exchange attribute directly in the cloud:

Set-Mailbox -Identity [email protected] -CustomAttribute1 "Finance"

That is a significant architectural change. But the important part is what doesn't happen: the user's entire identity does not automatically become cloud-only.

Exchange SOA and User SOA are not the same thing

There are currently two related approaches, and administrators need to keep them separate.

Option 1: transfer only Exchange-attribute SOA

This is the IsExchangeCloudManaged model. The user continues to be synchronized from on-premises Active Directory. Identity attributes — name, department, UPN, and the other AD-managed properties — remain under the authority of Active Directory. Only the Exchange-specific properties become cloud-managed.

This is the more interesting model for organizations that want to remove Exchange without removing Active Directory. Microsoft specifically describes it as a supported intermediate state: transfer Exchange-attribute SOA, decommission Exchange, and continue using Active Directory for identity management.

Option 2: transfer the entire object SOA

Microsoft also supports object-level Source of Authority transfer for users, groups, and contacts. With User SOA transfer, the object itself becomes cloud-managed rather than merely its Exchange attributes. For a transferred user, the synchronized relationship changes and the object behaves as a cloud-managed identity — Microsoft documents onPremisesSyncEnabled becoming null after the transfer.

That is a much broader identity-modernization decision. If your users still depend on LDAP, Kerberos, legacy applications, AD-based authentication, AD FS, HR-to-AD provisioning, or traditional device dependencies, moving the entire user's authority should be evaluated as an identity project — not slipped into an Exchange cleanup window. Microsoft notes additional considerations for exactly those dependencies.

What about Exchange attribute writeback?

This is an area where older articles are already outdated. As of Microsoft's August 2026 documentation, Exchange attribute writeback through Microsoft Entra Cloud Sync is generally available, with support documented for up to 600,000 cloud-managed mailboxes per tenant.

Writeback matters if something on-premises still needs to read Exchange attributes from Active Directory. Change proxyAddresses in Exchange Online, and without writeback the authoritative value is in the cloud while an old application querying Active Directory still expects the AD copy to be current. Cloud Sync can write supported Exchange properties back into Active Directory.

This does not mean every Exchange property is written back. Microsoft maintains a specific supported-attribute matrix: the Exchange extension attributes and the mail property support writeback, while many other Exchange attributes are cloud-editable but not written back. So the design question isn't "does writeback work?" It's: which applications still read these attributes from AD, and which attributes do they actually depend on? That is what needs to be discovered before you remove anything.

Your directory synchronization architecture matters

Version requirements, as of this writing:

• Entra Connect Sync 2.5.190.0 or later for Exchange-attribute SOA support when using Connect Sync.
• Microsoft Entra Cloud Sync if you want Exchange attribute writeback, with provisioning agent 1.1.1107.0 or later.

That does not necessarily mean ripping out Entra Connect Sync. Microsoft supports the two running side by side for this scenario: Connect Sync continues handling your existing AD-to-Entra synchronization while Cloud Sync handles Exchange attribute writeback. This is one of the reasons an SOA project should start with architecture discovery rather than a PowerShell script.

Before you remove Exchange, find everything that still depends on it

The actual Exchange Server may be doing more than anybody remembers. The biggest example is SMTP relay. Printers. Scanners. ERP applications. Monitoring systems. Applications written before half your IT team was hired. Some forgotten multifunction printer sitting in Accounting.

If those systems submit mail through an Exchange Receive Connector and you uninstall Exchange, that relay disappears with it. Microsoft explicitly warns that uninstalling Exchange removes the Receive Connectors, and applications relying on them stop sending mail. Before decommissioning, enumerate the connectors and the IP ranges allowed to relay:

Get-ReceiveConnector |
    Where-Object {$_.PermissionGroups -match 'AnonymousUsers'} |
    Format-Table Name,Bindings,RemoteIPRanges -AutoSize

Then determine what those IP addresses actually belong to. That second step is where the fun usually begins.

You also need to check mail flow

Before Exchange disappears, Microsoft expects mail flow to be moved away from the on-premises server. That includes checking:

• MX records
• External and internal Autodiscover, and the Autodiscover Service Connection Point
• Hybrid mail connectors
• Centralized Mail Transport
• Remaining migration endpoints

Centralized Mail Transport deserves particular attention. If Exchange Online is still configured to route outbound internet mail through the on-premises Exchange organization, removing that Exchange Server is not "cleanup." It is an outage. Microsoft requires that dependency to be removed before proceeding with the Last Exchange Server decommissioning path.

Groups and contacts are easy to overlook

IsExchangeCloudManaged applies to mailboxes. It does not magically convert every synchronized mail-enabled object. You also need to inventory distribution groups, mail-enabled security groups, and mail contacts.

Microsoft now supports Source of Authority transfer for groups and contacts as well. After a mail-enabled group's SOA is transferred, it can be managed through Exchange Online rather than remaining anchored to on-premises Exchange. One detail worth writing down: mail-enabled security groups remain Exchange-managed objects even after becoming cloud-managed — Microsoft notes they are read-only in Entra and must be administered through Exchange Online or Exchange PowerShell.

That is exactly the type of detail that gets missed when an organization treats this as "let's uninstall Exchange on Friday."

Don't enable tenant-wide SOA too early

Microsoft also provides a tenant-wide setting that makes newly provisioned mailboxes cloud-managed by default:

Set-OrganizationConfig -ExchangeAttributesCloudManagedByDefault

That sounds convenient. It is also something Microsoft explicitly warns you not to enable until all on-premises mailboxes have been migrated and you no longer create Exchange mailboxes, MailUsers, or remote mailboxes on-premises. Microsoft calls enabling it earlier unsupported.

Worse: an on-premises recipient synchronized after that setting is enabled can arrive in Entra as a regular user without the expected Exchange recipient representation, which can prevent normal Exchange Online onboarding. Microsoft's documented recovery guidance for affected users includes disabling the tenant-wide setting and contacting Microsoft Support. That is a fairly good argument for testing before flipping tenant-wide switches.

Pilot before you scale

Another detail worth highlighting: if you recently changed a synchronized mailbox's Exchange attributes on-premises, Microsoft says to allow the normal synchronization period plus an additional 24 hours before switching that mailbox's Exchange attributes to cloud management.

So pick a small representative group. Document the current state. Transfer SOA. Modify cloud-managed properties. Verify expected behavior. Test downstream applications. Test writeback if you're using it. Then expand.

A technically valid command is not the same thing as a validated migration.

A practical Last Exchange Server removal project

We think about this as six separate problems:

1. Establish the current state. Inventory the Exchange servers and versions, hybrid configuration, recipient counts, remaining on-premises mailboxes, public folders, remote mailboxes, groups and contacts, Receive and Send Connectors, migration endpoints, Autodiscover, DNS, Centralized Mail Transport, sync tool versions, and every application that queries Exchange attributes from AD. You should be able to explain why the Exchange Server still exists before attempting to remove it.
2. Decide the target source of authority. Which objects should remain AD identities with cloud-managed Exchange attributes, and which should eventually become fully cloud-managed identities? Those are not necessarily the same population.
3. Pilot Exchange SOA transfer. Representative synchronized mailboxes first. Validate attribute management, alias changes, custom attributes, GAL behavior, provisioning workflows, downstream integrations, and writeback where required.
4. Deal with non-mailbox recipients. Plan the target management model for distribution groups, mail-enabled security groups, and contacts. Do not discover after Exchange is gone that nobody can update a business-critical distribution list.
5. Remove Exchange dependencies. Move or eliminate SMTP relay, hybrid mail flow, Centralized Mail Transport, on-premises Autodiscover, public folders, legacy applications, and any remaining recipient-management processes.
6. Remove hybrid configuration and Exchange. Microsoft's current procedure includes cleanup of hybrid objects, hybrid connectors, organization relationships, federation components where applicable, Modern Hybrid Agent components where applicable, and then Exchange Setup uninstallation. Afterward, review cloud-side objects such as migration endpoints and the OnPremisesOrganization object, and check whether accepted domains need to change from InternalRelay to Authoritative.

What actually remains in Active Directory afterward?

Another common misconception: uninstalling the last Exchange Server does not reverse the Exchange schema extensions. Microsoft states the msExch* schema extensions remain in Active Directory for the lifetime of the schema, and existing Exchange-related values stored on user objects also remain. The uninstall removes the Exchange organizational configuration, Exchange security groups, server objects, and system mailboxes.

So this isn't pretending Exchange was never installed. It is removing the operational Exchange organization after its responsibilities have been moved elsewhere.

When should you NOT remove the last Exchange Server?

Keeping Exchange may still be the correct answer if you have a legitimate dependency on it:

• You still have on-premises mailboxes. Stop.
• You still have public folders that must remain on-premises. Stop.
• Exchange is still your SMTP relay and you have no replacement. Stop.
• You use Centralized Mail Transport and haven't redesigned mail flow. Stop.
• You rely on the Exchange Management Tools model and haven't transferred SOA. Do not uninstall the server. Microsoft explicitly warns against it.
• Nobody knows which applications query AD for Exchange attributes. Find out first.

There is no prize for becoming "cloud-only" three weeks earlier if the result is an ERP system that suddenly cannot send invoices. If you are still weighing the larger question of whether mail belongs on-premises at all, the Exchange SE versus Exchange Online decision is its own article — and the downtime math is what an unplanned outage actually bills.

So, should you do an Exchange SOA transfer?

For the right hybrid environment, the answer is increasingly yes. Not because "cloud good, server bad" — because infrastructure should have a reason to exist.

If Exchange is providing mailbox services, transport, relay, public folders, or another required workload, keep it and operate it properly. But if all production Exchange workloads have already moved to Microsoft 365 and the remaining server exists solely because recipient authority never followed the mailboxes into the cloud, Microsoft's SOA capabilities finally give organizations a supported way to address that architectural debt.

The important word is supported. Not ADSI Edit. Not custom scripts stamping arbitrary msExch values. Not "we shut the VM off two years ago and nothing has complained yet." A documented transition of authority — and under our ADAPTO delivery framework, it starts by proving what still depends on Exchange, then removing the dependencies in an order that doesn't turn infrastructure cleanup into a very educational Monday morning.