Forum Discussion
Device Migration from On-prem AD to Azure AD
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 / JJ
Great 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