Microsoft's documentation on migrating from on-premises Active Directory to Entra-only (cloud-only identity) is thorough but optimistic. It describes what happens when everything goes right. This post covers what actually happens.
After running several of these migrations — ranging from 50-user SMBs to multi-site organizations with 15 years of AD cruft — here's the sequence that works, and the traps that don't announce themselves until you're staring at a P1 incident on a Monday morning.
What "Entra-Only" Actually Means
Before anything: be precise about the end state. "Entra-only" means:
- ›No on-premises domain controllers in the authentication path
- ›Devices joined to Entra ID directly (not hybrid-joined)
- ›No password hash sync or AD FS in play (or it's been explicitly decommissioned)
- ›All application authentication running through Entra — no Kerberos, no NTLM
That last point is where most migrations quietly fail. Organizations assume they've completed the migration because they've moved users and devices, then discover six months later that three internal applications are still doing NTLM authentication against the now-decommissioned DCs.
⚠ Warning
Audit every application's authentication mechanism before you touch a single domain controller. NTLM and Kerberos dependencies are not always visible from the app side — check your DC event logs for authentication traffic.
The Sequence That Works
1. Hybrid First, Always
You cannot jump straight to Entra-only from a pure on-prem environment. Entra Connect (or Connect Cloud Sync) is your bridge. Get it running, get sync healthy, and verify that users can sign into Microsoft 365 with their cloud identities before you do anything else.
2. Audit Your Devices
Pull a full device inventory. Categorize everything:
- ›Domain-joined only — needs to be re-enrolled as Entra-joined (or hybrid-joined first as a stepping stone)
- ›Hybrid-joined — already has one foot in the cloud, simpler transition
- ›Personally owned / BYOD — already in Entra if they're enrolled in Intune
Devices that are only domain-joined cannot transition to Entra-joined without a re-enrollment. Plan for this. For Windows 10/11 devices, Autopilot reset is the cleanest path for managed hardware. For everything else, you're looking at a manual re-join workflow.
3. Set Up Conditional Access Before Touching Devices
This is the trap that hits hardest. Organizations move devices to Entra-joined, then turn on conditional access policies — and suddenly a subset of users can't authenticate because their device isn't yet marked compliant in Intune.
Deploy conditional access in report-only mode first. Run it for two weeks. Review the sign-in logs for what would have been blocked. Fix compliance gaps before you switch policies to enforced.
Conditional Access → Policies → [Policy] → Enable Policy: Report Only
Sign-in Logs → Filter by CA Policy Name → Review failures
4. MFA Rollout Before Passwordless
Don't attempt passwordless authentication (FIDO2, Windows Hello for Business) until MFA is fully rolled out and stable. Passwordless is the right end state — but users who haven't registered any MFA method yet will be locked out during the transition if your CA policies require phishing-resistant auth before they've registered anything.
Sequence: per-user MFA disabled → Security Defaults off → CA-enforced MFA on → Windows Hello for Business enrollment → phishing-resistant auth required.
5. Application Registration Audit
Every application authenticating against your old AD needs an Entra app registration — or a replacement. This includes:
- ›Internal web apps using Windows Authentication (IWA)
- ›Services running as domain service accounts
- ›SQL Server instances using Windows Authentication
- ›Legacy applications using LDAP queries against AD
✖ Danger
Service accounts are the most common migration-blocker nobody accounts for. Map every service account to the service it's running before decommissioning DCs. Managed Identities or Entra service principals should replace them.
6. Hybrid Cleanup
Once devices and users are cloud-native, clean up the hybrid artifacts before decommissioning DCs:
- ›Disable Entra Connect sync
- ›Remove the Entra Connect server (or demote it)
- ›Clean up stale computer objects in Entra that represent old domain-joined devices
- ›Verify no applications are still pointing at on-prem LDAP endpoints
7. Decommission DCs Last
Only after you have verified — not assumed — that nothing is authenticating against your DCs. Pull DC authentication logs and confirm they're silent. Then take one DC offline (don't delete it yet) and watch for 48-72 hours. If nothing breaks, proceed.
The Gotchas Nobody Warns You About
Group Policy. If your devices were relying on GPO for configuration — proxy settings, mapped drives, software deployment — you need Intune policies covering all of it before GPO goes away. Map GPO → Intune Settings Catalog item by item.
Printers. Printers shared via print server and connected via GPO-deployed printer connections will stop working. Universal Print or direct IP printing needs to be in place first.
Legacy MFA methods. If users have only SMS or voice call registered for MFA and you enforce phishing-resistant auth, they'll need to re-register. Give them a window and a help desk contact.
Named locations in CA. If you use IP-based named locations in conditional access (e.g., trusted office network = no MFA), verify those IPs are still current. Stale named locations cause unexpected MFA prompts that confuse users and generate tickets.
Timeline Reality
For a 100-200 user organization with moderate AD complexity, budget 8-12 weeks from start to DC decommission — not because the technical work is slow, but because device re-enrollment, application remediation, and user MFA registration take calendar time. Trying to compress this into a weekend will create incidents.
For larger or more complex environments, 3-6 months is realistic for a clean migration with no regressions.
The payoff is worth it: a cloud-native identity posture with conditional access, full audit logging, passwordless authentication paths, and no on-prem infrastructure to maintain or patch.