Forum Discussion
Device Migration from On-prem AD to Azure AD
Hello All,
We want to migrate our On-Prem AD devices to Azure AD and enroll into intune. We have Azure AD sync and all but needs to convert machine to Azure AD join only not Hybrid AD. So we would like to create new user profile on machine.
We have used two methods so far.
1) Reset the machine and use join to Azure AD from OOBE. ( Issue - This will make user a Administrator for that machine and we dont want that )
2) Unbind from on-prem AD, join to Azure AD manually but the same issue like number 1.
3) Using Hardware Hash, register devices to Autopilot and then reset all the machines. ( Issue - This will take too long to migrate 250 machines and helping remote workers are quite difficult )
Has anyone tried any different method or is there any expert suggestion ?
Thanks!
42 Replies
Amit_Trivedi112214
The behavior you’re seeing (user becoming local administrator) is expected.When a device is Azure AD Joined, the account performing the join is automatically added to the local Administrators group by design.
However, this can be controlled.
In Microsoft Entra ID:
Entra ID → Devices → Device settings
You can configure:
• “Additional local administrators on Azure AD joined devices”
• “Users may join devices to Azure AD”
Best practice is to:
Restrict device join rights to a controlled group
Assign a dedicated security group as local administrators
Remove the default “joining user becomes admin” scenario from operational workflows
Now, regarding migration strategy from On-Prem AD to Azure AD Join (not Hybrid):
Option 1 (Reset + OOBE Join) works but is disruptive.
Option 2 (Manual unjoin + join) works but still creates new profiles.
Option 3 (Autopilot) is the cleanest long-term model but operationally heavy for 250 existing devices.
A more scalable technical approach would be:
• Unjoin device from domain
• Reboot into workgroup
• Use Provisioning Package (PPKG) to automate Azure AD Join
• Enable automatic MDM enrollment via Entra ID
• Migrate user profile using a profile migration tool (e.g., ForensiT)
This avoids full reset and reduces user disruption.
Architecturally, you should also consider:
• Deploying Windows LAPS (cloud-based) for local admin password management
• Using Intune Endpoint Security policies to enforce least privilege
• Reviewing RBAC assignments in Entra ID
• Ensuring Conditional Access policies apply to compliant devices
Important question:
Are these devices currently domain-dependent for GPO, file shares, or legacy authentication?
If yes, removing Hybrid Join without modern management baselines (Intune configuration profiles + security baselines) may introduce gaps.
If your long-term goal is fully cloud-managed devices, standardizing with:
Azure AD Join + Intune + Autopilot (even for existing hardware)
will provide better lifecycle governance than manual migration paths.
Hey,
We faced the same challenge and could not adopt a disruptive approach due to the 6–8 hours of productivity loss per device.
As a result, we selected https://opsole.com/, which fully automates the approach commonly described as “Option 2 (manual unjoin + join that creates new profiles)”, but without the usual drawbacks. The solution re-ACLs the existing user profile, ensuring there is no user impact. Applications, Outlook profiles and signatures, local files, and application-specific settings remain exactly as they were.
Another major issue we encountered with manual joins was that joining devices using a PPKG removes all cloud device group memberships, since the device is treated as new. This broke security policies, Conditional Access, and Defender configurations. Opsole Migrate addresses this by automatically restoring device group memberships, ensuring policies remain intact.
The biggest factor, however, was productivity downtime:
- Autopilot: 6–8 hours per device (IT effort, user downtime, increased support tickets)
- Manual migration: 8–10 hours per device
- Opsole Migrate: completes the transformation in ~15 minutes
We also evaluated Quest, but our experience with Opsole Migrate was significantly better, both technically and operationally.
Rds / JJGreat perspective — and the productivity impact is absolutely a valid concern at scale.
Preserving user profiles and restoring device group memberships can significantly reduce disruption, especially in large transformations.
That said, migrations like this usually raise a broader architectural question:
Are we optimizing for immediate operational continuity, or for long-term cloud governance?
When moving from on-prem AD to full Azure AD Join, it’s not just about device registration. It’s about redefining:
- Security baseline consistency
• Device identity lifecycle
• Conditional Access enforcement
• Configuration drift from legacy GPO
• Long-term Intune management maturity
Profile-preserving approaches reduce short-term friction.
Autopilot-style rebuilds strengthen long-term governance and clean-state assurance.There isn’t a universal right answer — it depends on risk tolerance, security posture, and operational constraints.
I’m curious:
For those who’ve done large-scale AD → Azure AD migrations, which trade-off did you prioritize — continuity or clean baseline? And why?
- Security baseline consistency
Surprised to see that even after all these years, a seamless path from domain joined to native Azure AD (now Entra ID) without wiping devices still seems challenging. The profile continuity and downtime aspects make it even trickier at scale. Recently came across solutions like Opsole Migrate that claim to handle in-place device migration with minimal disruption, curious if anyone here has tested it or similar tools. Would definitely be interested in exploring this further.
We used the same 2 method Approach.
1. for the new laptops we used Autopilot OOBE.
2. for the existing fleet we have used a 3rd party tool (https://www.opsole.com). This tool as the self service option (the reason to choose this tool) which helped us to migrate the devices without teh IT team's involvement.We took a similar path. We recently did a POC with Opsole Migrate and its good, especially the self-service flow. Now we’re using the trial license to test different scenarios for existing devices mix of Win10&11, however for the new laptops it's best to use Autopilot OOBE. So far, it looks fine. I'll update my feedback after completing the full test.
There are multiple tools available like Quest and https://www.opsole.com
This tools helps us to migrate without re-image and can migrate even there are no AD line of sight.
We used Opsole for one of our customer migration and it was a great successWe are very much happy with the tool "www.opsole.com".
It helps to move Windows devices from traditional Active Directory (AD / Hybrid join) to Microsoft Entra ID Join without doing a wipe-and-reimage. It’s designed to keep the user experience intact (same profile, apps, settings, and local files) while automating the join-state transition.
It supports both IT-driven rollouts and user self-service, works for remote devices, and provides centralized visibility with real-time status, step-level logs, and audit-friendly evidence. It also focuses on continuity items that often break during migrations, like policy targeting (cloud group memberships) and recovery controls (BitLocker keys, LAPS).
It completes the migration within 15 min.Its very interesting. But in real scenario, many companies have thousands of existing laptops already in use. How are people handling migrations where - the device needs to stay AS-IS, the same user profile must remain, apps and local data can’t be touched?
Is there any practical approaches being used at scale without wipe and reimage?
I strongly suggest to connect with http://www.opsole.com or http://www.quest.com team. We had a such migration requirement and finally for our specific use case, Opsole was the best tool.
We were very much happy with the tool Opsole Migrate (www.opsole.com).
It helps to move Windows devices from traditional Active Directory (AD / Hybrid join) to Microsoft Entra ID Join without doing a wipe-and-reimage. It’s designed to keep the user experience intact (same profile, apps, settings, and local files) while automating the join-state transition.
It supports both IT-driven rollouts and user self-service, works for remote devices, and provides centralized visibility with real-time status, step-level logs, and audit-friendly evidence.
It also focuses on continuity items that often break during migrations, like policy targeting (cloud group memberships) and recovery controls (BitLocker keys, LAPS).
I understand and from the first post I see ask is to migrate your endpoint windows devices from local AD join to Azure AD join and most of the response are around enrollment and hybrid etc. which I are kind of not correct. I know the solution and you will need to leverage third-party which is in my view is not very expensive considering the value it brings.
1. For your machine to be able to fully Azure AD join, it needs to be disjoined from local AD and then join to Azure AD. If it is kept connected to local AD and synced to cloud, then it is hybrid join.
2. For larger scale deployment, it is not feasible and possible for admins to reach out to every user and disjoin the machine and manually join to Azure AD
3. If you do it manually you will lose the user profile and this will not be nice user experience.
So how do you solve this
Well, there is a tool from ForensIT (Corporate Edition) that migrate your machine and its user profile residing on local machine from domain or local to Azure AD join. You will need to create a deployment package using the wizard it provides and at the end it will create .exe file. Deploy that exe file either through GPO or through SCCM whichever works for you. Now one of thing here is, if you create provisioning package (.ppkg) file that ForensIT tool ask at one point, this .pkgg file can be created using Windows Configuration designer tool (WCD). Basically, you will be able to automate the whole process of even joining the machine to Azure AD. So, download windows configuration design tool (its free from MS and available in Windows Store) and follow the wizard very easy. At the end you will have .ppkg file. Use this file in ForensIT tool when it ask you to provide this at somepoint in wizard. At the end, you will .exe and all good.
When this .exe is run.
it will migrate the domain profile to Azure AD user profile such that all the settings, apps, desktop data everything stay as-is
it will disjoin the machine from the local AD
it will auto join the machine to azure ad using the provisioning package you created using WCD
you will need to reboot machine twice
that's it and you will have your machine fully Azure AD joined and with user profile and data intact!
thank you.- I am doing the AD->AAD shuffle as well but for kiosk-type devices. I'm using the bulk enrollment method:
https://learn.microsoft.com/en-us/mem/intune/enrollment/windows-bulk-enroll
It's a real challenge to remotely get a device to safely leap from the top of one building to another without any wires or safety lines and not fall 1000 feet below to its death. I'm using a PowerShell script that connects to the remote machine, copies over the PPKG generated from the WCD above, uninstalls the SCCM agent, (waits 5 minutes because ccmsetup.exe /uninstall returns immediately but continues to uninstall in the background) Then I create a scheduled task that runs the PPKG on first login, then I disjoin the computer from the AD domain. I'm also experimenting with ways to install a Wi-Fi profile because our Wi-Fi profiles come from GPO so when you disjoin, you lose Wi-Fi. We connect them with EAP/TLS so I've had to do a lot of screwing around with our RADIUS server to build authn/authz rules that let the device on Wi-Fi before and after the transition. I've had to make a copy of the GPO-based Wi-Fi profile, export it with netsh then create another scheduled task that loads the wifi profile after domain disjoin on first boot. You can't pre-load the wifi profile when it's connected to AD because the GPO profile is in the way. I think I'm also going to need a step that enables RDP after disjoin because, again, we turn that on with GPO and once you disjoin, it goes back to default off.
I don't think this helps much for the person who is just trying to convert user devices from AD > AAD without messing with hybrid but figured it was worth mentioning.
- Copies
- Hello all,
Just worked through this thread and ill be taking over IT items for my company and during this time i will br migrating from on prem AD to AAD. Did not know if someone came up with a more simplified way or if Intune or the autojoin worked better.
LMKWhat we noticed from our experience, (I agree Autopilot and re-image is the Microsoft Approach) the re-image approach requires 1-2 hours from the IT Technical team per device, 2-3 hours of user productivity loss and 1-2 hours of support ticket as the end user is getting new laptop.
This means 5-6 hours per device and a 20K user company its cost millions of dollars. In this situation our management decided to invest on http://www.opsole.com and we have successfully migrated all the users with high user satisfactions.
Our experience was excellent with Opsole Migrate
- A lot late and sorry for bumping the thread. Has anyone found a solid solution yet?
I am in the same shoes, and tried a silent join using GPO. Everything went well and upon reboot, the system went through setting up bio metrics etc. (we use biometrics with intune only).
However, upon second reboot the device was unable to verify my PIN.
I reached out to MS, they were unable to help but suggested that as the machine is still joined to AD (GPO enrollment does not drop the AD) the system might be looking fro AD as the login authority and PIN is registered in AAD.
Other that this issue, everything works smooth and it's very silent join seamless for the user.Hey Aravind,
We have tried both http://quest.com and http://opsole.com. Both were successful.
Quest is agent based solution and Opsole is an agentless user self service solutionI understand and from the first post I see ask is to migrate your endpoint windows devices from local AD join to Azure AD join and most of the response are around enrollment and hybrid etc. which I are kind of not correct. I know the solution and you will need to leverage third-party which is in my view is not very expensive considering the value it brings.
1. For your machine to be able to fully Azure AD join, it needs to be disjoined from local AD and then join to Azure AD. If it is kept connected to local AD and synced to cloud, then it is hybrid join.
2. For larger scale deployment, it is not feasible and possible for admins to reach out to every user and disjoin the machine and manually join to Azure AD
3. If you do it manually you will lose the user profile and this will not be nice user experience.
So how do you solve this
Well, there is a tool from ForensIT that migrate your machine and its user profile residing on local machine from domain or local to Azure AD join. You will need to create a deployment package using the wizard it provides and at the end it will create .exe file. Deploy that exe file either through GPO or through SCCM whichever works for you. Now one of thing here is, if you create provisioning package (.pkgg) file that is ask at one point, this .pkgg file can be created using Windows Configuration designer tool. Basically you will be able to automate the whole process of even joining the machine to Azure AD. So download windows configuration design tool (its free from MS and available in Windows Store) and follow the wizard very easy. At the end you will have .pkgg file. Use this file in ForensIT tool when it ask you to provide this at somepoint in wizard. At the end, you will .exe and all good.
When this .exe is run.
it will migrate the domain profile to Azure AD user profile such that all the settings, apps, desktop data everything stay as-is
it will disjoin the machine from the local AD
it will auto join the machine to azure ad using the provisioning package you created using WCD
you will need to reboot machine twice
that's it and you will have your machine fully Azure AD joined and with user profile and data intact!
thank you.
Thanks for laying this out so clearly, completely agree that true Azure AD (now Entra ID) join requires disjoining from on-prem AD, and doing this manually at scale just isn’t practical. Preserving the user profile is the real differentiator for user experience. I was aware of tools like ForensIT, and recently came across Opsole Migrate as well, which seems to take a similar in-place approach with automation. Definitely feels like third-party tooling is becoming the realistic path for large migrations without disruption. Curious to see how these solutions compare in real world deployments.
Quick input as we are in the process of migrating on-prem to native Azure AD.
At this point we have been doing the migration as devices get replaced, but for the rest here is our process.
Log into device with DC admin.
Create local admin user, no password.
Log out and into local user. Remove DC and reboot.
Connect to Azure AD with future user desired (user needs to be in azure/365 and licensed, whichever user you register it with will have admin on the pc).Once joined, log out of local user and into future azure user (the one you registered with, or your Azure admin).
Remove local user.Log into the employees account that was using the pc if you aren't already.
We use free profwiz to copy the profile data unattended.
Its not the fastest option, but it drags the old profile data across to the Azure AD profile and no wipe is needed. Total hands on time is about 20-30 minutes on average, can often times do 5-10 units at once by one guy.
Thank you for the reply.
I was able to silently migrate the devices to MDM, only issue was with windows hello fro business.
We did not want to create a new profile/break the user connection, as that would change the profile ID and break things for the user. At the end, we decided to stagger the deployment and work slowly by sending replacement laptops.
- In regards to issue 1 and users getting local admin rights, are you using Intune? If so you can create a deployment profile in which you state that users don’t have admin rights. Target that to your devices and after the OOBE the user will have standard user rights.
As far as I know there aren’t any supported methods to migrate devices from AD to an native Azure-AD joined stated without resetting the device.- Hey John,
please see my comment to Avinash.DeyKilledKenny
This isn't the full awnser to the question. The question was how to get from an Domain joined setup to a native Azure AD joined setup for existing devices. The steps you described involve enrolling an Domain device to Azure AD. It doesn't remove the device from the on-prem domain.
