VIVID TECHNICAL
Cloud Migration

How to Migrate from On-Prem Active Directory to Microsoft Entra ID: A Step-by-Step Guide

Every week we talk to SMBs running the same broken setup: an on-prem Active Directory domain controller that’s been humming along since 2015, synced to Microsoft 365 with Entra Connect, with half their users managed on-prem and the other half created directly in the cloud. Nobody remembers why it’s still there. Nobody wants to touch it.

Here’s the thing — that domain controller is probably the single biggest piece of technical debt in your environment. It’s a server you’re patching, backing up, and paying to host, and its only job is syncing passwords to a cloud platform that doesn’t need it anymore.

This guide walks through how to get rid of it.

A Quick Note on Naming

Microsoft renamed Azure Active Directory to Microsoft Entra ID in 2023. Same product, new name. Throughout this article we’ll use the current name, but if you’re searching for documentation, both “Azure AD” and “Entra ID” will get you where you need to go. Similarly, “Azure AD Connect” is now Microsoft Entra Connect, and “Azure AD Join” is Microsoft Entra Join.

The Azure AD Domain Services Misconception

This needs to be said clearly, because we see it constantly: Azure AD Domain Services (Entra Domain Services) is not a migration path to cloud-only identity.

Azure AD DS is a managed instance of traditional Active Directory running in Azure. It gives you LDAP, Kerberos, and NTLM authentication in the cloud — the exact things you’re trying to move away from. It exists for one reason: to support legacy applications that can’t authenticate against modern Entra ID.

If someone tells you to “just spin up Azure AD DS” as your migration strategy, they’re not moving you to the cloud. They’re moving your on-prem problem to a different data center and charging you monthly for the privilege.

A true cloud-only migration means your identities live in Entra ID, your devices are Entra-joined and managed by Intune, and there is no domain controller anywhere — on-prem or in Azure. That’s what this guide is about.

Prerequisites: What Needs to Be True Before You Start

Don’t start this migration until every one of these is in place:

  • All workloads are in Microsoft 365 or SaaS. Email is on Exchange Online. Files are in SharePoint/OneDrive. If you’re still running an on-prem Exchange server or file server, migrate those first.
  • All PCs are running Windows 10 or 11 Pro (or Enterprise). Home editions don’t support Entra Join.
  • You have M365 Business Premium or equivalent licensing. You need Intune for device management and Entra ID P1 for Conditional Access. Business Premium bundles both.
  • Group Policy has been mapped to Intune. Every GPO that matters needs an equivalent Intune configuration profile or compliance policy. Don’t assume you need all of them — most environments have years of accumulated GPO cruft that nobody uses.
  • No remaining on-prem dependencies. No RADIUS server authenticating against AD. No network shares with NTFS ACLs tied to domain SIDs. No print servers. No line-of-business apps doing LDAP binds. If any of these exist, they need to be migrated or replaced before you cut the cord.

The Migration: Step by Step

Step 1: Audit Your Environment

Before you touch anything, document what you have. You need a complete picture of:

  • Users and groups — Every security group, distribution list, and mail-enabled security group. Which ones are synced from on-prem? Which are cloud-only?
  • Devices — What’s domain-joined? What’s already Entra-joined? What’s hybrid?
  • Applications — Anything authenticating against on-prem AD. Check service accounts, LDAP connections, and Kerberos-dependent apps.
  • Group Policy — Export all GPOs and identify which ones are actively doing something useful.

The goal is to find every dependency on on-prem AD so nothing breaks when you remove it.

Step 2: Migrate Remaining Services to SaaS

If the audit uncovered anything still depending on on-prem infrastructure, migrate it now:

  • File shares go to SharePoint document libraries or OneDrive
  • Exchange goes to Exchange Online (if it hasn’t already)
  • DHCP and DNS move to your firewall or a dedicated appliance — these don’t need AD
  • Print servers get replaced with cloud printing or direct IP printing
  • Line-of-business apps get evaluated for SaaS alternatives or Entra ID authentication support

Step 3: Enroll Devices in Intune

This is where you replace Group Policy with modern management:

  • Create Intune configuration profiles that replicate your essential GPO settings
  • Create compliance policies (require BitLocker, require PIN, etc.)
  • Set up Conditional Access policies in Entra ID (require compliant device, block legacy auth)
  • For new devices, Entra Join them directly during Windows setup with Autopilot
  • For existing domain-joined devices, you’ll handle these during the profile migration step

Step 4: Migrate User Profiles

This is the step most guides skip, and it’s the one that will ruin your weekend if you get it wrong.

When a PC is domain-joined, the user profile is tied to the on-prem AD SID. When you Entra-join that same PC, Windows sees the Entra ID user as a completely different account. The user logs in and gets a blank desktop — no files, no settings, no Outlook profile.

The fix is ForensIT ProfWiz (or a similar profile migration tool). ProfWiz rebinds the existing user profile to the new Entra ID identity, preserving the desktop, documents, app settings, and cached credentials. The user logs in with their Microsoft 365 credentials and everything is where they left it.

The workflow per device:

  1. Disconnect the PC from the domain
  2. Join the PC to Entra ID
  3. Run ProfWiz to migrate the profile from the old domain account to the new Entra ID account
  4. User logs in with their M365 credentials and validates

For small environments, this is a desk-by-desk operation. For larger rollouts, ProfWiz has a Corporate Edition that can be scripted.

Step 5: Verify UPN Matching

This is the silent killer of directory sync cutoffs. Before you break sync, make sure every user’s on-prem UPN matches their cloud UPN exactly.

If your on-prem domain is something like company.local, your users’ UPNs might be user@company.local — which doesn’t match user@company.com in the cloud. You need to:

  • Add your public domain as a UPN suffix in Active Directory Domains and Trusts
  • Change each user’s UPN to match their cloud identity
  • Verify that ProxyAddresses (SMTP aliases) are populated in on-prem AD — if they’re empty, breaking sync can wipe the user’s email aliases in Entra ID

Step 6: Recreate Groups in the Cloud

This is the step people forget, and it costs them.

When you break directory sync, synced security groups and distribution lists can lose their cloud functionality. Before disabling sync:

  • Create cloud-only equivalents of every security group and distribution list you need
  • Populate membership in the cloud groups
  • Update any references to the old groups (Conditional Access policies, SharePoint permissions, Teams membership, etc.)
  • Verify mail flow for distribution lists

Do this before you disable sync. Doing it after is a scramble.

Step 7: Disable Directory Sync

This is the point of no return. Once you’re confident everything is migrated and verified:

# Connect to Microsoft Online
Connect-MsolService

# Disable directory sync
Set-MsolDirSyncEnabled -EnableDirSync $false

When sync is disabled, all synced user accounts convert to cloud-managed accounts. Microsoft says this can take up to 72 hours, but in practice it usually completes within minutes.

This is a one-way operation. Re-enabling sync after this point is technically possible but painful — it requires a support ticket and can take 72 hours. Plan accordingly.

Step 8: Decommission On-Prem Servers

Once you’ve verified that:

  • All users can log in with cloud credentials
  • Email flow is working
  • Security groups and distribution lists are intact
  • Intune policies are applying correctly
  • No application or service is throwing authentication errors

Then you can demote and decommission your domain controllers. Remove the AD DS role, then repurpose or decommission the server.

Gotchas from the Field

These are the things that don’t show up in Microsoft’s documentation but will absolutely bite you in production:

Passwords after sync breaks. When directory sync is active, the on-prem password is the source of truth and syncs to the cloud. After you break sync, the password that was last synced becomes the cloud password. Some admins force a password reset for all users after the cutover to establish a clean baseline. Others leave it alone. Either way, communicate to your users what’s happening.

The ImmutableID question. Some practitioners recommend clearing the ImmutableID attribute on cloud accounts after breaking sync. Microsoft’s documentation says breaking sync is sufficient and the ImmutableID becomes irrelevant. We’ve seen it both ways — clearing it is belt-and-suspenders but not strictly necessary.

Distribution lists and aliases. If you don’t recreate distribution lists in the cloud before breaking sync, they can disappear. Similarly, if the ProxyAddresses attribute isn’t populated on the on-prem user object, breaking sync can strip email aliases. Audit these before you flip the switch.

The two-password problem. If any users still need to access on-prem resources after migration (e.g., a VPN that hasn’t been migrated yet), they’ll have two separate identities with two separate passwords. This creates confusion and support tickets. Eliminate on-prem dependencies first.

Phased vs. hard cutover. Some admins prefer moving users one at a time: move the user to a non-synced OU, let sync run (which deletes and recreates the cloud account), then restore the cloud account from the recycle bin. This works but is slower and more complex. For most SMBs under 100 users, a hard cutover over a weekend is simpler and cleaner.

When You Still Need On-Prem AD

Cloud-only isn’t the right answer for everyone. You still need an on-prem domain controller (or at minimum a hybrid setup) if:

  • You run a RADIUS server for network authentication (802.1x, VPN) that requires AD
  • You have on-prem file shares with complex NTFS ACLs that can’t be replicated in SharePoint
  • You rely on legacy applications that require LDAP binds or Kerberos tickets
  • You use Remote Desktop Services with AD-joined session hosts

If any of these apply, look at Entra Connect Cloud Sync with Cloud Kerberos Trust instead. It gives you a lighter-weight hybrid that can serve as a stepping stone while you modernize the remaining dependencies.

Get It Done Right

Migration from on-prem AD to cloud-only Entra ID isn’t technically difficult, but it has a lot of moving parts that need to happen in the right order. Skip a step or miss a dependency and you’re spending your weekend on the phone with users who can’t log in.

If you’d rather have someone who’s done this dozens of times handle it, reach out for a migration assessment. We’ll audit your environment, identify blockers, and build a migration plan that doesn’t break anything.