Eliminate Your Domain Controller: A Practical Guide to Migrating to Microsoft Entra ID with Minimum Risk and Downtime

TL;DR

Retiring your last domain controller is not a project, it is a program. Done well it takes 9 to 18 months for a mid-sized organization, removes an entire class of attack surface (Kerberoasting, Golden Tickets, NTLM relay, AD CS abuse), and lets you collapse VPNs, jump boxes, and on-prem patching into a much smaller cloud-native footprint. Done poorly it locks users out of file shares, breaks line-of-business apps, and forces an emergency rebuild of a domain you just spent six months retiring.

This guide is the playbook I use with customers who want to actually finish the journey, not just talk about it. It assumes Microsoft Entra ID and Microsoft 365 as the destination, and it is honest about where Entra Domain Services has to stay as a temporary bridge.

Why Eliminate the Domain Controller

Active Directory has been the identity backbone of most enterprises for 25 years, and that longevity is precisely the problem. A typical on-prem AD environment in 2026 carries:

• Years of accumulated permissions debt: nested groups, orphaned ACLs, and service accounts no one will admit owning
• A flat, high-value attack surface: any domain-joined endpoint that gets compromised is one Kerberoast away from a tier-zero foothold
• A patching and availability tax: domain controllers, AD CS, ADFS, and the supporting Windows Server fleet all need OS patching, backups, DR, and monitoring
• A blocker to modern access: every laptop that has to "phone home" to a DC for logon forces you to keep VPN concentrators, MPLS circuits, or always-on tunnels alive
• Compliance friction: showing auditors evidence of least privilege in AD is dramatically harder than in Entra ID with PIM, Conditional Access, and access reviews

Going cloud-native with Entra ID does not just modernize identity. It removes whole categories of risk and operational toil:

• No more Kerberoasting, AS-REP roasting, NTLM relay, or DCSync (the protocols simply are not exposed)
• No more Golden Ticket or Silver Ticket attacks
• No more AD CS misconfiguration as a tier-zero attack path (ESC1 through ESC15)
• No more Pass-the-Hash on workstations using local NTLM
• No more emergency forest recovery drills

The trade-off is that you are exchanging a familiar but flawed model for a new one with its own pitfalls (Conditional Access misconfigurations, token theft, OAuth consent abuse). Those are real, but they are smaller, more visible, and far easier to monitor than what AD presents today.

When You Should Not Do This (Yet)

Be honest with yourself before committing. Reasons to delay or scope down:

1. You have a hard LDAP or Kerberos dependency in a vendor app that the vendor will not modernize, and you cannot replace the app within 18 months
2. You run an on-prem certificate authority that issues certificates to non-Microsoft systems (network gear, Linux servers, IoT) and have not yet stood up a cloud PKI replacement
3. You operate OT/ICS networks that are air-gapped and authenticate domain devices that will never see the internet
4. You have not yet deployed Intune at scale. Without Intune, "cloud-native" is aspirational, not operational. Fix this first.
5. You have unresolved hybrid Exchange that still requires on-prem AD for recipient management. Move to Exchange Online and decommission Exchange Server first.

If any of those apply, your end state may be a small, hardened AD island synced to Entra, with everything else cloud-native. That is a perfectly valid outcome and far better than the status quo.

The Pre-Flight Inventory

You cannot retire what you have not inventoried. This phase usually takes four to six weeks and is where most projects either succeed or quietly die. Build a single source of truth (a SharePoint list, a Notion database, or even a well-disciplined Excel sheet) and capture every dependency before you touch anything.

What to Inventory

A Useful Trick: Block-and-Watch in a Lab

For dependencies you cannot prove from documentation, build a representative lab that mirrors production, then block traffic to the lab DC and watch what breaks. The errors that surface in 48 hours are exactly the ones that will surface at production cutover. Better to find them now.

Target State Mapping

Every component of your AD environment has an Entra-side equivalent. Print this table and put it on the wall.

Target Architecture

Here is what the end state looks like for a typical cloud-native enterprise. Note that there is no domain controller in the diagram, and the only on-prem component is an optional Private Access connector for legacy app access.

The Phased Migration Playbook

Migrations fail when teams treat them as one big cutover. The reliable approach is five phases with explicit rollback gates between each. You can run several phases in parallel for different parts of the business once you have proven the pattern, but you should never start a downstream phase before the gate of the previous phase has been passed.

Phase 1: Hybrid Foundation (Weeks 1 to 6)

Goal: Establish Entra ID as the authoritative identity system and a clean sync from AD, with no behavior change for users yet.

Steps:

1. Stand up Entra Connect Cloud Sync (preferred) or upgrade legacy Entra Connect to the latest version. Cloud Sync has no on-prem server, scales horizontally, and has fewer failure modes than the legacy sync agent.
2. Configure Password Hash Sync as the default authentication method. Even if you keep ADFS or Pass-Through Authentication for now, PHS gives you a fallback that survives DC failure.
3. Enable Self-Service Password Reset with writeback. This single feature pays for the entire program in helpdesk savings.
4. Enable Security Defaults if you have nothing else, or deploy a baseline Conditional Access set:

• Require MFA for all admins
• Block legacy authentication (this alone prevents 99% of password-spray success)
• Require compliant or hybrid-joined device for sensitive apps
• Require MFA for guest users

1. Migrate licenses to group-based assignment (not individual). This is the foundation for license-driven access control later.
2. Stand up Entra ID PIM for all privileged roles. Eliminate standing Global Administrator membership in week one. Aim for zero standing Global Admins, with break-glass accounts excluded from Conditional Access and stored offline.

Rollback gate: All users can sign in with the same credentials they used yesterday. MFA is enforced for admins. Legacy auth is blocked. If any of these fail, fix before moving on.

Phase 2: Modernize Devices (Weeks 4 to 16, overlapping)

Goal: Stop creating new domain-joined devices. Migrate existing devices to cloud-only join. This is the single most important phase.

Steps:

1. Provision new devices via Autopilot, cloud-only joined to Entra ID and enrolled in Intune. From day one of this program, no new device is domain-joined. Make this an unbreakable policy.
2. Build a baseline Intune configuration that mirrors your most important GPOs:

• BitLocker (silent encryption, recovery key escrow to Entra)
• Microsoft Defender for Endpoint baseline
• Windows Update for Business rings
• Local admin password solution (Windows LAPS in Entra)
• Edge security baseline
• AppLocker or Application Control for Business

1. Deploy Windows Hello for Business in cloud trust mode. Cloud trust requires Windows 10 21H2+ and Windows Server 2016+ DCs (you still need them during phase 2), but it removes the certificate infrastructure burden of certificate trust.
2. Deploy Microsoft Defender for Endpoint through Intune. Make device compliance dependent on EDR signal so a compromised device loses Conditional Access without manual intervention.
3. Migrate existing devices in waves of 50 to 200 users:

• Pilot wave: IT and security teams (eat your own dog food)
• Early adopters: a friendly business unit
• General population: by department, with a 1 to 2 week soak before the next wave

1. Convert each migrated device using either:

• Wipe and reload via Autopilot (cleanest, best for older devices that need a refresh anyway)
• In-place "Hybrid to Cloud-Only" reconfiguration using OOBE reset with provisioning packages (faster, but more edge cases)

1. Replace GPO-based drive mappings with OneDrive Known Folder Move for personal drives, and Intune-deployed scripts that mount Azure Files for departmental shares.
2. Replace GPO-based printer deployment with Universal Print and the Intune Universal Print policy.

Rollback gate: A representative sample of users in each department is on a cloud-joined device, working normally for 30 days, with no escalations related to file access, printing, application launch, or VPN. Help desk ticket volume from the migrated cohort is at or below baseline.

Phase 3: Modernize File and Print (Weeks 8 to 24, overlapping)

Goal: Move every file share and every print queue off domain-joined Windows servers.

File Servers: Choose Per-Share

Not every share belongs in the same place. The decision tree:

For Azure Files with Entra Kerberos (the closest like-for-like SMB replacement):

1. Enable Entra Kerberos authentication on the storage account (one-time configuration per storage account)
2. Assign Storage File Data SMB Share roles in RBAC to map "who can mount the share"
3. Migrate NTFS ACLs as-is using the Storage Migration Service or AzCopy with /preserveSMBPermissions. Critically, NTFS ACLs are preserved; Entra users and groups simply replace the on-prem equivalents through SID mapping
4. Cut over by changing DFS Namespace targets or DNS CNAMEs to point at the Azure Files endpoint. Users see the same UNC path, but it now resolves to Azure
5. Run the old file server in read-only mode for two weeks before decommissioning, in case anyone has hardcoded paths

Hidden gotcha: applications that connect via SMB and run as a service account need the service account migrated too. If the app uses an on-prem domain account today, plan for a managed identity (if the app supports it) or a cloud-only Entra ID user with a long random password and Storage File Data SMB Share role. Test these before cutover.

Print Servers: Universal Print

Universal Print is the cloud replacement for Windows print servers. Modern printers from HP, Canon, Lexmark, Brother, and Xerox support it natively. For everything else, install the Universal Print connector on a small Windows VM (an exception that earns its keep). Push printer assignments through Intune Universal Print policy, scoped by group.

Rollback gate: A test cohort can read, write, and modify files on the new shares with their existing groups; printing works without GPO; no shadow IT file servers have been forgotten.

Phase 4: Legacy App Access (Weeks 12 to 32)

Goal: Provide secure access to apps that still need on-prem connectivity, without requiring devices to be domain-joined.

Three patterns, in order of preference:

1. Modernize the app to OIDC/SAML. If the vendor has a modern release, upgrade. If you wrote the app, modernize it. Every app you modernize is one less reason to keep AD alive.
2. Front the app with Entra Application Proxy or Entra Private Access:

• For HTTP/HTTPS apps with header-based or Kerberos backend auth, use Application Proxy with Kerberos Constrained Delegation (KCD)
• For non-HTTP apps (SSH, RDP, custom TCP/UDP), use Entra Private Access (part of Microsoft Global Secure Access)
• Both options publish the app through Entra ID, enforce Conditional Access, and remove the need for VPN

1. Bridge with Entra Domain Services for apps that absolutely require LDAP or Kerberos and cannot be fronted:

• Entra Domain Services provides a managed LDAP/Kerberos endpoint synced from Entra ID
• It is a true managed service: no DCs to patch, no replication to monitor
• Use it as a transitional bridge with a clear retirement plan, not a permanent crutch
• Costs add up, so scope it to the apps that need it and isolate them in a dedicated subnet

The VPN question: most VPN deployments exist because devices used to need to "see" a DC. Once devices are cloud-joined and apps are published through Application Proxy or Private Access, you can collapse the VPN to a tiny exception case (network admins doing CLI work on infrastructure) or eliminate it entirely. Plan to retire VPN as part of this phase, not as a separate project.

Rollback gate: every app on the inventory has a documented owner, a chosen pattern (modernize / publish / bridge), and a target date. Apps assigned to "bridge" have a Domain Services retirement criteria written down (for example, "retire when vendor releases SAML support, expected Q3").

Phase 5: Decommission (Weeks 24 to 52+)

Goal: Turn off the last domain controller without breaking anything.

This phase is largely a verification phase. If phases 1 to 4 were done well, decommissioning is anticlimactic. If they were not, this is where you find out.

Steps:

1. Read-only the AD environment: deny new account creation, GPO changes, and AD CS template changes. This forces every team to confirm they have what they need from cloud-native equivalents.
2. Reduce DC role: shut down all DCs except one in a single site. Watch for failures over a two to four week soak. Anything that fails is an undocumented dependency.
3. Disable AD CS: stop issuing certificates from AD CS. Renew everything from Cloud PKI or your chosen replacement. Run AD CS in suspend mode (CA service stopped but CRL still published) for the lifetime of the longest issued cert, then revoke and decommission.
4. Final DC down: gracefully demote the last DC. The clean path is Uninstall-ADDSDomainController followed by Uninstall-WindowsFeature AD-Domain-Services. Avoid forceremoval except as a last resort.
5. Decommission Entra Connect if you no longer need any sync (you will only get here if you have zero hybrid identities left). Most organizations keep some sync indefinitely for service accounts that authenticate to Domain Services.

Rollback gate: 30 days of clean operation with no DCs in production. Help desk volume normal. Compliance and audit signed off on the new evidence sources (Conditional Access reports, sign-in logs, Intune compliance, PIM access reviews).

Special Cases You Will Hit

Service Accounts

Service accounts are the silent killers of these migrations. Every one of them needs a target pattern:

Run a campaign in week one of phase 1: every service account gets an owner, a target pattern, and a migration date. Accounts without an owner go on a clearly visible list. After 30 days, accounts still without an owner get disabled (ideally in a non-production-impacting window). The pain forces ownership.

Backup Software

Veeam, Commvault, Rubrik, and similar products often use a domain account for VM and file server backups. After the migration:

• Backup of cloud workloads (M365, Azure Files, SharePoint) is best done with cloud-native backup (Microsoft 365 Backup, Azure Backup) or vendor cloud-native modules
• The backup software's own service account moves to a managed identity if the appliance runs in Azure, or to an Entra cloud-only user otherwise
• File restore patterns change: SharePoint and OneDrive have built-in version history and recycle bin, which handles 90% of "I deleted a file" tickets without invoking the backup tool

Plan this in parallel with file server migration. Do not migrate file servers and then realize backup is broken.

Wi-Fi and 802.1X

Most enterprises use NPS as a RADIUS server, authenticating Wi-Fi and switch ports against AD. Once devices are cloud-joined and AD is gone, NPS has nothing to authenticate against. Replacement options:

• Cert-based 802.1X with certificates issued by Cloud PKI / Intune SCEP. Devices present a machine cert, the RADIUS server validates the cert. This works with any cloud-friendly RADIUS (Cloud RADIUS, JumpCloud, Foxpass) or with Microsoft's NPS extension running in Azure.
• EAP-TLS with Entra ID via partners like Cloud RADIUS or SecureW2 that integrate Entra group membership into RADIUS responses (for VLAN assignment etc.)

Plan Wi-Fi migration alongside device migration. Devices that move to cloud-only join must immediately have a way to get on the network without AD.

Mailbox-Enabled User Accounts

If you still have mailboxes in on-prem Exchange Server, decommission Exchange Server before decommissioning AD. The order matters:

1. Move every mailbox to Exchange Online
2. Run Hybrid Configuration Wizard in modern hybrid topology mode (which removes the need for on-prem Exchange to manage attributes for cloud mailboxes)
3. Decommission the last Exchange Server
4. Manage cloud-mailbox attributes from Entra and Exchange Online directly

Linux and macOS Endpoints

Cloud-native is easier for Linux and macOS than for Windows.

• macOS: enroll in Intune via Apple Business Manager and Automated Device Enrollment. Use Platform SSO for Entra ID single sign-on. Mosyle and Jamf are excellent third-party alternatives if you are already invested.
• Linux: enroll endpoints with Intune Linux support (Ubuntu LTS, RHEL). For sign-in, use Entra ID with PAM modules (Microsoft's pam-aad). For sudo and SSH access patterns, federate to Entra ID via OIDC where the SSH provider supports it (Teleport, StrongDM, AWS SSM, Tailscale SSH).

Risk Register

These are the risks I track on every engagement. Each one has a mitigation; the discipline is to mitigate proactively, not after the incident.

Realistic Timeline

Treat this as the median for a 1,000 to 2,500 user organization with a typical Microsoft estate. Smaller is faster; heavily regulated or legacy-heavy is slower.

If you are smaller (under 500 users) or already have Intune at scale, you can compress this to two to three quarters. If you have Exchange Server on-prem, AD CS in heavy use, or a regulated industry (financial services, healthcare, public sector), expect 18 to 24 months.

Common Pitfalls

1. Trying to do this without Intune at scale first. Stop. Deploy Intune, get to 80%+ enrollment of existing devices, then start.
2. Skipping the inventory phase. Every project that skipped this came back to do it later, after a cutover failure.
3. Migrating to Entra Domain Services and calling it done. Domain Services is a bridge, not a destination. Without a retirement plan, you have just cloud-hosted your AD problem.
4. Letting GPO sprawl move to Intune sprawl. Use the migration as an opportunity to consolidate. If a GPO is not in active use, do not port it.
5. Underestimating service accounts. Inventory them in week one. Assign owners. Disable orphans aggressively.
6. Treating the VPN as out of scope. It is not. Most VPNs exist because of AD. Retire it as part of phase 4.
7. No break-glass strategy. Two cloud-only Global Administrator accounts, FIDO2 keys, excluded from all Conditional Access except the most basic, credentials in offline storage. Test sign-in quarterly.
8. Ignoring the audit team. Bring them in during phase 1. The new evidence model (sign-in logs, Intune compliance, PIM access reviews) needs their buy-in long before you switch off AD.
9. One-shot cutover thinking. Wave the migrations. Each wave teaches you something the next wave benefits from.
10. No success metrics. Define what "done" looks like in week one. Examples: zero domain controllers in production, zero standing Global Admins, 100% of devices Entra-joined, 100% of shares on cloud storage, zero ADFS dependencies.

Frequently Asked Questions

Can I run AD and Entra ID in parallel forever?

Technically yes. Practically no. Hybrid identity is a transitional state, and every quarter you stay in it you accumulate more attack surface, more cost, and more operational debt. The point of this program is to choose a destination and arrive there.

Do I have to retire ADFS?

Yes. ADFS is one of the highest-value targets for attackers (Solorigate showed why) and Entra ID's native federation, Conditional Access, and custom claims policies cover almost every legitimate ADFS use case. Plan ADFS retirement in phase 1.

What about my certificate authority?

If your AD CS issues only Microsoft device and user certs, replace it with Intune Cloud PKI or a third-party Intune-integrated PKI like SCEPman or Keytos. If it issues to Linux, network gear, or third-party endpoints, you will need a broader cloud PKI replacement (DigiCert ONE, GlobalSign Atlas, AWS Private CA). Do not assume AD CS retirement is automatic.

How do I handle apps that hardcode the old NETBIOS-style domain backslash username format?

Two options. First, modernize the app if the vendor has a release that supports UPN format. Second, if you must keep the legacy format, those apps go behind Entra Domain Services where the legacy NETBIOS-style authentication still works. Track them as candidates for retirement.

Will users notice the migration?

If you do it well, the moments they notice should be positive: SSPR works, MFA becomes consistent across apps, file access is faster, no more VPN clicks. The moments they should not notice are sign-in itself and file access. That is the standard you are aiming for.

What does the licensing actually cost?

A typical cloud-native target requires Microsoft 365 E3 or E5 per user, plus optionally Entra ID P2 (included in E5) for PIM and Identity Protection. If you currently run M365 E3 plus Defender, you are mostly there already. The additional costs are usually Cloud PKI (per user), Universal Print (per user), and Entra Domain Services (per environment). For most organizations, the total cost is roughly flat to existing spend once you remove on-prem server, AD CS, NPS, VPN, and ADFS infrastructure costs.

How do I prove to auditors that we are still compliant?

Map every AD-era control to its Entra equivalent in writing, before you start. Common mappings:

• "AD password policy" maps to Entra Password Protection plus Conditional Access
• "Privileged group membership review" maps to PIM access reviews
• "Domain Admin activity logging" maps to Entra audit logs and sign-in logs (with longer retention via Log Analytics or Sentinel)
• "Workstation hardening via GPO" maps to Intune compliance and configuration profiles
• "Network access control" maps to Conditional Access plus Intune compliance plus device certificate

Most modern auditors are familiar with these mappings; you mostly need to document them.

Can I do this without Microsoft consulting services?

Yes, and most organizations should. The information is all public, the official documentation is comprehensive, and the patterns in this guide are battle-tested across hundreds of migrations. What you do need is a senior architect who has done at least one of these end-to-end, plus a project manager who can hold the schedule. If you do not have either, hire the senior architect, not the consulting firm.

Decision Tree: Should You Really Go Fully Cloud-Native?

Final Word

The phrase "we are going cloud-native" gets used too lightly. Actually retiring your last domain controller is one of the highest-leverage security and operations programs an enterprise can run. It removes a 25-year-old attack surface, collapses an entire on-prem infrastructure tier, and turns identity from a thing you have to operate into a thing your cloud provider operates for you.

The work is real, and the timeline is honest: 9 to 18 months for most. But every step has a clear rollback gate, every component has a documented cloud equivalent, and every risk on the register has a known mitigation. If you commit to the inventory, treat the bridges as bridges (not destinations), and run the program in disciplined waves, you can finish what most organizations only talk about.

Start with the inventory this week. Make Intune enrollment the unmovable prerequisite. Set the no-new-domain-joined-devices rule from day one. Everything else follows.