Migrate Active Directory to the cloud in three stages: on-prem only, then hybrid, then cloud-only.
Users go first, because Entra Connect copies them across and nobody even notices. Devices go last, and that’s where people notice, because every PC gets wiped and comes back with a fresh Windows profile. Cue the help desk tickets.
Every step below to migrate Active Directory comes straight out of my lab, so you can follow along click for click. Nothing fancy:
A real company has a lot more junk in the trunk: email, file shares, that one finance app from 2009, printers that hate everyone.
I’m not covering those here, but the gotchas section points out where they’ll bite you in the ****. If you’re planning to migrate Active Directory for an actual business, treat this guide as the identity and device backbone and build the rest around it.
Most attempts to migrate Active Directory go tits up before the first click, thanks to dirty data or a missing license. Sort this lot out first.
Licenses. Password writeback, dynamic groups and Intune auto-enrolment all need Entra ID P1 or better. Microsoft 365 Business Premium and E3 include it. I only remembered this at the password reset step, then spent an evening convincing Azure my perfectly normal credit card was real. Raised a support case, it got fixed, nobody ever told me what was wrong. Classic Microsoft.
A verified domain. Add your real domain (mine is monrocloud.com) to the tenant and verify it with the TXT record Microsoft hands you.
Clean UPNs. The UPN (user principal name) is the sign-in name, like david@monrocloud.com. If your on-prem domain ends in .local or .lan, those users rock up in the cloud as david@yourtenant.onmicrosoft.com, which looks about as professional as a Hotmail address. Add your verified domain as an alternative UPN suffix in Active Directory Domains and Trusts, then switch each user over. Source
.local
.lan
david@yourtenant.onmicrosoft.com
Run IdFix. IdFix is Microsoft’s free tool that sniffs out duplicates and dodgy characters in AD before you sync. It can bulk-edit objects, so read what it wants to change before you let it loose. Source
A server for Entra Connect. I chucked it on the domain controller because it’s a lab and I’m lazy. Don’t do that in production. Give it its own member server and guard it like a domain controller, because it holds the keys to both directories.
Accounts you’ll need:
Connect Sync or Cloud Sync? Cloud Sync is Microsoft’s shiny new toy and where they’re heading long term. I’m using Entra Connect Sync (good old Azure AD Connect) because most organisations still run it and it handles hybrid device join, which this whole migration leans on.
This phase copies your AD users into Entra ID with the same username and password. Users won’t notice a thing, which makes it the safest place to start when you migrate Active Directory.
1. Download Connect Sync. In the Microsoft Entra admin center, type Microsoft Entra Connect into the search bar, open the Manage tab and grab the installer. The page might still call it Azure AD Connect, because Microsoft renames things faster than it updates them.
Common terminology is “Cloud Sync” (NEW) and “Connect Sync” (OLD).
2. Pick Customize, not Express. Express is for people who enjoy surprises. Customize lets you choose which OUs sync and which features switch on.
3. Choose the sign-in method. Select Password Hash Synchronization and tick Enable single sign-on. Password hash sync sends a hash of a hash of each password to the cloud, never the password itself, so users log in to Microsoft 365 with the password they already know (and probably have on a Post-it). Seamless SSO means a domain-joined PC on the office network signs them in without asking.
4. Sign in to Entra with a Global Administrator from the tenant. If the login box throws a JavaScript error or just stares at you blankly, jump to gotcha 3.
5. Connect your directory. Directory type is Active Directory forest. Click Add Directory, choose Create new AD account, and feed it your Enterprise Admin details. The wizard makes its own service account for syncing.
6. Check the UPN mapping. The wizard reads the AD schema, which is just the list of fields each user has (email, phone, employee ID and so on), and asks which one becomes the cloud sign-in name. Leave it on userPrincipalName if your UPNs are already clean.
7. Leave identity matching alone. Users are represented only once across all directories is right for a single forest. You’d only change it after a merger, when two on-prem accounts for the same poor bastard need to become one cloud account. The source anchor is the permanent ID that glues the on-prem user to the cloud user. I honestly can’t think why you’d change it, so don’t.
8. Filter by OU. Tick only the OUs you want to move. I ticked the Sydney OUs. If all your users are dumped in one big Users container (no judgement… ok, a little judgement), filter by a pilot group instead.
9. Turn on Password writeback. On Optional features, tick Password writeback. Without it, a password reset in the cloud never reaches on-prem AD, and self-service password reset is about as useful as a chocolate teapot.
Kick off a sync. Open PowerShell on the Entra Connect server and run this decades-old favourite:
Start-ADSyncSyncCycle -PolicyType Delta
Refresh Users in the Entra admin center. My three test users showed up, tagged as synced from on-premises. A bit bleak with so few attributes, but it proves the first part of your plan to migrate Active Directory actually works.
If a password changes in the cloud, it has to change on-prem too. Otherwise users end up with two passwords and you end up with a queue of angry people.
1. Assign a P1 licence to each test user.
2. Check writeback is on in both places: the Entra Connect wizard (done in Phase 1) and in Entra Admin Center > Password reset > On-premises integration. The second option un-ticked is correct for this lab, it is only used for “Cloud Sync” whereas we are using “Connect Sync”
3. Reset a test user’s password in the Entra Admin Center. Go to Users > select the user > Reset password (don’t use the Microsoft 365 admin center. I’m a dinosaur and went straight there out of habit, and it doesn’t work – see gotcha 4).
4. Log in on the domain-joined PC with the new password. If it works, you should asked to reset the password on next logon.
⚠️ Note: Group policy may require changing if you want to reset the password more than once during testing. I have set the Minimum password age to 0 so I can repeatedly test (see screenshot below). Do this at your own risk, there are obvious security implications to users being able to reset passwords as often as they like.
Users are syncing and passwords flow both ways, so the user half of your plan to migrate Active Directory is done. Pat yourself on the back… now get back to work. 🤨
Hybrid join means a PC stays married to on-prem AD while having a fling with Entra ID on the side. It’s the bridge that lets you migrate Active Directory devices, because Intune and Autopilot can now see machines built the old way.
1. Reopen the Entra Connect wizard and pick Configure device options. Identity sync pauses (not password replication) while the wizard is open. Don’t panic, it starts again when you close it.
2. Select Configure Hybrid Microsoft Entra ID join, then Windows 10 or later domain-joined devices. The other option is for Windows 7, 8.1 and Server 2012 R2. If you still need that one, we should talk.
3. Configure the SCP. The service connection point is a little record in AD that works like a signpost. A domain-joined PC has no clue the cloud exists, so when it talks to a domain controller, the SCP tells it which Azure tenant to register with. Pick your forest, choose Microsoft Entra ID as the authentication service and enter Enterprise Admin credentials.
4. Reopen the Entra Connect wizard.
5. Sync the computer objects. Back in Customize synchronization options > … > Domain and OU filtering, tick the OU holding your PCs (obviously in production you would do this one OU at a time).
6. Run a delta sync (same command as Phase 1, below for your convenience), then check Devices in the Entra Admin Center. The PC shows as Pending.
Once you migrate Active Directory devices, Intune is what manages them.
A group policy tells each hybrid-joined PC to enroll itself, so nobody has to wander around the office with a USB stick like it’s 2008.
1. Set the MDM user scope. In the Intune Admin Center go to Devices > Enrollment > Windows > Automatic Enrollment and set MDM user scope to All (or Some with a pilot group).
2. Move the PC into a synced OU. I dragged my test PC into the “Sydney” OU so it syncs and picks up the new policy.
3. Create a GPO (mine’s called “MDM”) linked to that OU. Edit it and go to:Computer Configuration > Policies > Administrative Templates > Windows Components > MDM.
4. Enable Enable automatic MDM enrollment using default Azure AD credentials and set the credential type to Device Credential. If the MDM folder isn’t there, load the latest Windows ADMX templates into your Central Store.
⚠️ Note: the MDM Application ID is only required if you use more than one MDM product.
5. Apply it. On the PC run gpupdate /force, then restart the PC.
gpupdate /force
6. Check the scheduled task. Open Task Scheduler and browse to Microsoft > Windows > EnterpriseMgmt. A task appears once enrolment starts and it’s a great way to see if something is happening. If the folder’s empty after a restart, something’s blocking it. For me it was DNS. It’s always bloody DNS.
7. Confirm in Intune. The PC turns up under Intune > Devices > Windows Devices, about 10 minutes after the scheduled task appeared.
Autopilot is how you migrate Active Directory PCs to cloud-only: it rebuilds each one after the wipe. This phase registers the existing PC with Autopilot and gives it a new profile.
3rd party tools exist to migrate the user profiles – however these were not tested during the lab. Microsoft support would be limited or not available with any 3rd party apps used to clone profiles.
In the Entra Admin Center go to Groups > New group, choose Assigned membership and add the hybrid-joined PC. Mine’s called “Windows 11 Autopilot”.
In Intune go to Devices > Enrollment > Windows > Deployment profiles > Create profile > Windows PC and use these settings:
Assign the profile to the Windows 11 Autopilot group.
Once the profile kicks in, Devices in Entra shows the PC twice. One is the hybrid-joined object with its normal name. The other is named after the PC’s serial number, a random-looking mess of letters and numbers. That’s the Autopilot record, the identity the PC will use once it’s cloud-only. Microsoft says the double-up is expected, thanks to some ancient database logic (which I’m sure someone in the comments will explain in excruciating detail).
Now you need a group that scoops up those Autopilot records on its own. Go to Groups > New group, set Membership type to Dynamic Device, click Add dynamic query, then Edit under Rule syntax, and paste:
(device.devicePhysicalIDs -any (_ -startsWith "[ZTDId]"))
In plain words: “add any device that has an Autopilot ID”. Every Autopilot-registered device carries a hidden ZTDId value, so this rule picks up each serial-number object as it appears. Mine’s called Windows 11 dynamic. Source
Only want a pilot batch? Give those PCs a group tag in Autopilot and filter on that instead:
(device.devicePhysicalIds -any (_ -eq "[OrderID]:Win11Pilot"))
Open the dynamic group’s Members and make sure it only caught the PCs you expect. If it’s hoovered up the CFO’s laptop and you’re not ready to wipe it, stop and narrow the rule. Then add the dynamic group to the deployment profile’s assignments.
The profile status goes from Not assigned to Pending to Assigned. Mine took about an hour. Pretty sure MS use homing pigeons as part of the profile status updates, it is NOT quick!
There’s no supported magic button that turns a hybrid-joined PC into an Entra-joined one in place. The PC has to be wiped and rebuilt by Autopilot, so this is the riskiest part of any plan to migrate Active Directory. Most of the work is making sure you don’t nuke anyone’s stuff.
The user gets a brand-new Windows profile. Whether that’s a non-event or a total s**tshow depends on what you do beforehand. Back in the XP to Windows 7 days we’d wipe machines overnight and leave printed instructions on the keyboard. It’s better now. Not perfect, but better.
C:\Temp
C:\Data
There are third-party tools that copy the old profile across. Microsoft doesn’t support any of them and it goes without saying you would need to do extensive testing before even considering this a viable option.
Intune says the wipe is Complete long before the PC is actually done. The PC restarts, shows a percentage screen and takes around 30 minutes.
1. The PC lands on the normal out-of-box screen. The user signs in with their cloud name, for example david@monrocloud.com.
2. They set up MFA if they haven’t already.
3. Windows Hello asks for a PIN.
Check it with dsregcmd /status. You want AzureAdJoined : YES and DomainJoined : NO. That PC doesn’t need your domain controller anymore. Free at last.
dsregcmd /status
These are the traps that cost me, and plenty of other engineer’s real time.
1. Old Entra Connect versions have already stopped syncing. Since 30 September 2026, any Entra Connect Sync server below version 2.5.79.0 stops syncing until you upgrade it. Auto-upgrade only works from 2.3.20.0 or later, and crusty old servers often need .NET Framework 4.7.2 and TLS 1.2 first. Install the latest build, not the bare minimum, because older builds hit their own end-of-support dates. (Microsoft, Everywan)
2. .local users sync to the wrong name. A user like holly@contoso.local becomes holly@contoso.onmicrosoft.com in the cloud. Add a routable UPN suffix and fix users before you migrate Active Directory accounts, because renaming them afterwards confuses the hell out of everyone. (Microsoft)
3. The Entra sign-in box shows a script error or goes blank. Blame Internet Explorer security on the server, the gift that keeps on giving. Run inetcpl.cpl, open Security > Custom level, set Active scripting to Enable, then close and reopen the Entra Connect wizard.
inetcpl.cpl
4. Resetting passwords in the Microsoft 365 admin does not writeback to on-prem AD. The user can log in to the cloud, but on-prem AD keeps the old password. Microsoft confirms the 365 admin center doesn’t use the writeback plumbing, so do resets in the Entra admin center. That’s half an hour of my life I’m not getting back. (Microsoft)
5. Repeated test resets fail the password policy. Writeback still obeys your on-prem password rules, and the default Minimum password age is 1 day. Reset twice in a day and you get a “does not meet policy” error. In a lab you can drop it in Default Domain Policy > Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policy. Don’t go loosening company policy just to make testing easier. That’s on your head, not mine.
6. No P1 license, no writeback. Password writeback and dynamic groups both need Entra ID P1. Sort the license and the payment method early. My card got knocked back for no reason anyone could explain.
7. Two objects per PC is normal. After Autopilot registration, Entra lists the hybrid object and a serial-number object. Don’t delete either one to tidy up. The serial-number one is exactly what the dynamic group needs.
8. “Convert all targeted devices” doesn’t convert the join. It only registers the PC with Autopilot. Microsoft says plainly that a hybrid-joined PC doesn’t become Entra-joined from this setting alone. The wipe does that. Microsoft’s own advice is to move existing PCs at a natural reset or hardware refresh where you can. (Microsoft, Tech Community)
9. Autopilot profile assignment is as slow as a wet week. Expect up to an hour between adding the dynamic group and seeing Assigned. Fiddling with settings during that wait just resets the clock.
10. An empty EnterpriseMgmt task folder means enrolment is stuck. Mine was DNS. Check the PC can resolve Microsoft endpoints and reach a domain controller before you go down a rabbit hole.
11. Smart quotes break the dynamic rule. Copy the rule out of a web page or Word and the " can turn into curly quotes, and Entra throws a tantrum. Paste it into Notepad first. (Peter van der Woude)
"
12. “Wipe complete” is a filthy lie. Intune reports success long before the reset finishes. Wait until the PC hits the out-of-box screen before you call the user.
13. Seamless SSO has a key to rotate. Turning on SSO creates a computer account called AZUREADSSOACC in AD. Microsoft recommends rolling its Kerberos key at least every 30 days with Update-AzureADSSOForest, and treating that account like the crown jewels. (Microsoft)
Update-AzureADSSOForest
14. Never migrate Active Directory in one big bang. Filter by OU or group, pilot with a handful of users and PCs, then go wider. One bad filter can shove hundreds of objects into the cloud in a single cycle.
After the six phases, your users sign in with cloud identities, and your pilot PC is Entra-joined, managed by Intune and doesn’t give a toss about your domain controller. Repeat Phases 3 to 6 one OU or one team at a time until every PC has moved.
To fully migrate Active Directory, a few jobs remain after the devices: move mail off on-prem Exchange, swap Group Policy settings for Intune profiles, shift file shares to SharePoint or OneDrive, and find a new home for anything still authenticating against AD, like printers, Wi-Fi and that one ancient app nobody will admit to owning. Once nothing points at AD anymore, switch off sync and retire the domain controllers. Maybe hold a small funeral.
