I'm looking for a sanity check before finalizing our plan to make Microsoft Entra ID the authoritative identity source and eventually decommission our on-premises domain controllers. The immediate goal is to transfer user identity authority to Entra ID; shutting down the domain controllers will come later.
Our environment currently has three Windows Server 2012 R2 domain controllers, a file/print server, an Exchange 2013 server, and a Microsoft Entra Connect server. Mail routing already goes through Microsoft 365, and distribution lists and groups have been moved there, although Exchange and on-premises Active Directory still manage some identity attributes and mailbox information. Directory synchronization is currently one-way, and password writeback is disabled.
All user computers are off the local domain, fully enrolled in Intune, and not hybrid joined. No applications depend on Active Directory. Users have moved from the file server to OneDrive and SharePoint, and printers have been redeployed through Intune. DHCP and DNS still run on the domain controllers for now, although those services are planned to move to a UniFi firewall later.
What should the sequence be? Should we first change or remove Exchange-related attributes, then transfer user source of authority to Entra ID, disable directory synchronization, and only afterward retire Exchange and the domain controllers? I'd appreciate practical guidance on dependencies, validation steps, and anything that should not be done abruptly.
3 Answers
A cautious order would be to power down genuinely unused file and print services first, leave them off for several days, then handle the Exchange retirement using Microsoft’s documentation. After that, complete the supported Entra Connect shutdown and source-of-authority transition. Keep the domain controllers online while DNS and DHCP still rely on them.
Once identity and mail are fully cloud-managed, migrate DNS and DHCP independently, verify clients can resolve internal and external names, and only then retire the domain controllers. If you still need internal RFC1918 name resolution, public DNS alone won’t replace your internal DNS; you’ll need another DNS platform or service.
You appear to have completed most of the difficult migration work, but don’t treat this as simply turning off the domain controllers. First inventory anything that still depends on AD, including DNS names, service accounts, scripts, scheduled tasks, certificates, management tools, and applications that may not be obvious.
For the identity portion, follow Microsoft’s current guidance for changing the source of authority for users and groups. Validate that the cloud objects, sign-in names, licenses, groups, and mailbox-related attributes are correct before disabling Entra Connect. Don’t manually delete or change Exchange attributes based on AI-generated advice; use Microsoft’s supported Exchange decommissioning procedure, particularly because Exchange 2013 is long out of support.
After each major change, monitor sign-ins, mail flow, provisioning, and administrative operations before moving on. Keep recoverable backups and a rollback plan rather than shutting everything down at once.
Don’t uninstall or abruptly shut down Exchange just because mail routing already uses Microsoft 365. Exchange can still own on-premises recipient attributes, so first determine whether any recipients or management tasks remain tied to the local server. Follow Microsoft’s documented process for retiring an on-premises Exchange server and confirm that all mailboxes, connectors, accepted domains, relay scenarios, groups, and management requirements are covered.
Likewise, disabling synchronization is a separate supported procedure. Make sure the intended cloud objects are ready to become authoritative and understand what happens to matching users and groups before making the change.
The DNS requirement is easy to overlook. Before removing AD DNS, list every internal hostname clients need and decide where those records will live. Also confirm what will provide DHCP and whether losing the firewall would leave you without DHCP failover.