Many organizations are working toward a cloud-based identity and device-management model.
Users are authenticated through Microsoft Entra ID, devices are managed through Microsoft Intune, and dependence on on-premises Active Directory is gradually reduced.
On paper, the direction appears straightforward:
- Move identity to Microsoft Entra ID
- Move device management from Group Policy to Intune
- Entra-join Windows devices
- Gradually reduce the Active Directory footprint
In practice, however, one part of this journey is often more difficult than expected: migrating the existing Windows devices.
New devices are relatively straightforward
For a new Windows device, organizations can use Windows Autopilot to prepare the device and join it to Microsoft Entra ID during the initial setup process.
The user receives the device, signs in with an organizational account, and the required applications, policies, certificates, security settings, and configurations can be delivered through Intune.
This works well because the device does not already contain years of user data and configuration.
An existing device is different.
It may already contain:
- Locally stored user files
- Installed business applications
- Application-specific settings
- Outlook profiles and cached information
- Browser profiles, bookmarks, and extensions
- VPN and Wi-Fi configurations
- Security certificates
- Antivirus or endpoint security software
- Printers and mapped drives
- Locally stored credentials
- BitLocker encryption
- Settings that were previously applied through Group Policy
The challenge is therefore not simply to remove the device from Active Directory and join it to Entra ID. The real challenge is doing this without unnecessarily disrupting the user’s working environment.
Why changing the device join is not enough
An Active Directory user and an Entra ID user may represent the same person, but Windows can treat them as different security identities.
If an existing device is manually removed from the domain and joined to Entra ID, the user may sign in and receive a new Windows profile.
Their old profile may still exist on the device, but Windows may no longer associate it with the new Entra identity.
This can result in:
- An empty desktop
- Missing application settings
- Lost browser configuration
- Inaccessible local files
- Reconfiguration of Outlook and other applications
- Additional help-desk work
- A poor experience for the employee
The files may not technically be deleted, but from the user’s perspective, their familiar working environment has disappeared.
This is why an endpoint migration should be treated as an identity and profile transition, not merely as a device join operation.
Reimage or migrate in place?
One option is to wipe or reimage every device and provision it again.
Microsoft’s documented Autopilot deployment for existing devices uses a Configuration Manager task sequence to reimage and provision the device.
A clean deployment can provide a consistent starting point. It may also be suitable when devices need to be refreshed, repurposed, or brought back to a known configuration.
However, it can create additional work:
- User data must be backed up and restored
- Applications must be reinstalled
- User-specific settings may need to be recreated
- Remote users may require additional assistance
- Employees may experience longer periods of downtime
An alternative is an in-place migration.
The objective of an in-place approach is to move the existing Windows device from AD joined or hybrid Entra joined to Entra joined while retaining the current Windows installation and the user’s existing profile.
This does not mean that every dependency will automatically work after migration. It means the organization is attempting to preserve the device and user environment instead of rebuilding them from the beginning. If you're evaluating options, I'd search for "in-place AD to Entra device migration without wipe", there are a few vendors in that space with published case studies you can review independently.
What should an in-place migration process cover?
A reliable process needs to address more than the domain-unjoin and Entra-join commands.
- Readiness assessment Before migration, the organization should verify:
- The device is running a supported Windows edition
- The Entra identity exists and is correctly mapped
- Intune automatic enrollment is configured
- The user has the required licences
- Required applications support Entra-joined devices
- Group Policy settings have suitable Intune replacements
- VPN, Wi-Fi, certificate, and network-access dependencies are understood
- Recovery information such as BitLocker keys is available
- Microsoft’s Entra join planning guidance also recommends evaluating application, authentication, Group Policy, network, printing, and legacy protocol dependencies.
User identity mapping
The existing domain user must be correctly mapped to the intended Entra ID user.
This is particularly important when usernames, UPNs, email addresses, or tenant identities differ. An incorrect mapping could attach the local Windows profile to the wrong cloud identity.Profile preservation
The existing Windows profile should remain usable after the user signs in with Entra ID.
This may include preserving access to local files, desktop settings, application configuration, browser information, and other user-specific data.Device-state transition
The device must be safely removed from its current AD or hybrid state, joined to Microsoft Entra ID, and enrolled into Intune.
The order of these actions matters. If the device loses access to management, network connectivity, administrative credentials, or recovery information during the transition, remote remediation can become difficult.Post-migration validation
A successful Entra join does not necessarily mean the migration is complete.
The team should also confirm:
- The user can sign in successfully
- The expected Windows profile loads
- Intune enrollment is healthy
- Compliance and configuration policies apply
- Required applications remain operational
- BitLocker and recovery keys are correctly managed
- VPN, Wi-Fi, certificates, printers, and business resources still work
The device appears correctly in Entra ID and Intune
Start with a controlled pilot
Organizations should avoid starting with hundreds or thousands of devices.
Begin with a small group representing different scenarios: office-based users, remote employees, developers, executives, VPN-dependent users, and devices from different departments or locations.
The pilot should help identify dependencies and support requirements before a wider rollout.
Cloud identity migration is not only an identity project. For the end user, the Windows device is where the change becomes real.
Protecting the existing profile, validating dependencies, and reducing downtime can make the difference between a technically completed migration and a successful one.
How has your organization handled existing Windows devices when moving from AD or hybrid join to Entra join, reimage, manual migration, or an automated in-place process?
Top comments (1)
Really well put. People often underestimate these projects because the actual Entra join is straightforward, but the impact on the user is where things get difficult - profiles, apps, certificates, VPN, printers, and all the small settings people rely on every day.
Planning the migration around the user experience, with proper testing and a rollback option, makes a huge difference. This is definitely more than just moving devices to a new management platform.
I’m very impressed with the Opsole Migrate support team. They were available around the clock and supported us throughout the migration - not only with the migration itself, but also with end-device issues that came up along the way