DEV Community: Kumar

Moving Existing Windows Devices to Entra ID: Why the Endpoint Is Often the Hardest Part

Kumar — Sat, 15 Aug 2026 04:34:26 +0000

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?

AD Minimization: How ready are organizations for the journey?

Kumar — Wed, 12 Aug 2026 13:23:16 +0000

Microsoft's direction around Active Directory minimization is an interesting and important part of the broader cloud transformation journey.

Moving more identity and device management toward Microsoft Entra ID can help organizations gradually reduce their dependency on traditional on-premises Active Directory and move towards a more cloud-first environment.

What I particularly like about Microsoft's approach is that this is positioned as a journey rather than something that needs to happen overnight.

For many organizations, Active Directory has been part of the environment for 20+ years. Over that time, a lot of dependencies may have been built around it, such as legacy applications, Group Policies, domain-joined Windows devices, LDAP, Kerberos or NTLM dependencies, file servers and other infrastructure, as well as scripts and operational processes linked to AD.

Moving new users, applications and devices towards a cloud-first approach is one part of the journey.

The more interesting challenge is how organizations modernize the existing environment while minimizing disruption to users and day-to-day operations.

Existing Windows devices are a good example. Many organizations may already have hundreds or thousands of devices that are AD joined or Hybrid Entra joined. Replacing or reimaging all of those devices purely to move towards a cloud-native model may not always be practical.

This is also where solutions designed specifically for existing endpoint transformation can play a role. Opsole Migrate, for example, is designed to help organizations transition existing Windows devices from AD-joined or Hybrid Entra joined environments to Microsoft Entra ID joined while preserving the existing Windows user profile and avoiding the need to wipe or reimage the device.

Tools addressing this part of the journey can complement Microsoft's broader cloud-first strategy by helping organizations deal with the existing device estate while continuing to adopt Microsoft Entra ID and modern endpoint management.

This is where I think Microsoft's phased approach makes a lot of sense. Organizations can gradually identify and reduce AD dependencies while continuing to modernize identity, endpoint management and applications at a pace that works for their environment.

AD minimization therefore may not necessarily mean switching everything off at once. For many organizations, it could be a gradual process of identifying where Active Directory is still required, removing those dependencies where practical, and moving more workloads, identities and endpoints towards cloud-native management over time.

I would be interested to hear from others who are already working towards AD minimization.

Where is your organization in this journey today?

Are you already actively reducing your dependency on on-premises AD?

And what has been the biggest area to address so far, legacy applications, Group Policy, existing Windows devices, authentication dependencies, or something else?

It would also be interesting to hear which Microsoft technologies or approaches have helped you most during this transition.

AD to Entra ID Without Starting Over: The Real Challenge Is the Endpoint

Kumar — Fri, 07 Aug 2026 11:31:27 +0000

Many organizations are gradually moving toward a cloud-first identity model. Microsoft Entra ID is becoming the primary identity platform, Microsoft Intune is increasingly being used for device management, and the dependency on traditional on-premises Active Directory is steadily decreasing.

For new Windows devices, this transition is relatively straightforward. Organizations can use Windows Autopilot and other modern provisioning methods to prepare a new device and join it directly to Microsoft Entra ID.

Existing Windows devices, however, present a different challenge.
A device that has been used for several years is not simply a Windows installation connected to Active Directory. It may contain years of user configuration, business applications, antivirus and security software, certificates, VPN settings, browser profiles, local files, cached information, application preferences, and many other dependencies.

Because of this, moving an existing Windows device from Active Directory or Hybrid Entra ID Join to Entra ID is more than simply changing the device join state.

The real challenge is completing the transition while keeping the device usable and minimizing disruption to the person who depends on it every day.

The Device Join Is Only One Part of the Migration
From an IT perspective, it is easy to focus primarily on whether the device can successfully join Microsoft Entra ID.

But a technically successful join does not necessarily mean that the migration has been successful from the user's perspective.

IT teams should also consider questions such as:
What happens to the existing Windows user profile?
Will the user's applications continue to work?
Will browser settings and application preferences remain available?
Will Microsoft Intune enrolment complete successfully?
Will security policies and configuration profiles be applied correctly?
What happens to VPN, certificates, and other connectivity requirements?
How will remote users be supported if something goes wrong? These questions become increasingly important when the organization has hundreds or thousands of existing endpoints.

Existing Devices Need a Different Strategy
For new devices, organizations can design a clean cloud-native deployment process from the beginning.
Existing devices already have a history.
They have users, applications, settings, business data, security controls, and dependencies that cannot always be recreated easily.

This is why organizations moving away from traditional Active Directory should consider the migration of their existing endpoint estate as a separate workstream rather than assuming the same approach used for new devices will work for everything.
The migration strategy should consider both the technical transition and the user experience.

Remote Users Add Another Layer of Complexity
Remote and hybrid working have made this even more important.
In a traditional office environment, an IT engineer may be able to physically access a device if something unexpected happens during migration.

For a remote employee, that may not be possible.
The migration process therefore needs to consider what happens if network connectivity is interrupted, the user cannot authenticate after the transition, Intune enrolment does not complete, or a business critical application behaves differently.
The ability to identify problems remotely and recover from failures becomes an important part of the overall migration design.

Pilot Before Moving to Production
Regardless of the migration approach, one of the most important steps is running a representative pilot.
A pilot should not simply consist of several identical laptops from the same department.
It is more useful to include different scenarios such as:

Office based and remote users
Different Windows versions or patch levels
Devices with business critical applications
VPN-dependent devices
Different security policies
Users with heavily customized profiles
Devices from different departments or locations The purpose of the pilot is not only to prove that migration works. It is also an opportunity to identify unexpected dependencies before hundreds or thousands of production users are affected.

In-Place Migration Is One Option
Organizations that want to avoid wiping or reimaging existing devices can also evaluate in-place migration approaches.
For example, Opsole Migrate is one of the solutions focused on helping organizations transition existing Windows endpoints from Active Directory or Hybrid Entra ID environments to Microsoft Entra ID while retaining the existing device and user environment.

More information is available at: https://www.opsole.com/
The objective here is not necessarily to recommend one particular tool. Different organizations will have different technical requirements, security policies, endpoint configurations, and migration strategies.
Whichever approach or product is selected, it is important to test it properly in the organization's own environment before beginning a large scale rollout.

A successful proof of concept should validate more than simply whether the device reaches the desired Entra ID join state.
It should also verify user-profile continuity, application compatibility, Intune enrolment, security configuration, remote-user scenarios, and recovery procedures.

Scale Changes the Migration Requirement
A process that works well for 10 or 20 devices may not necessarily be suitable for 2,000 or 5,000 devices.
At larger scale, repeatability and automation become increasingly important.

If an engineer has to spend a significant amount of time manually working on every endpoint, the operational effort can quickly become very high.

A scalable migration process should therefore aim to reduce repetitive manual work while still giving IT teams sufficient visibility and control when exceptions occur.

Think Beyond the Join State
Moving from Active Directory or Hybrid Entra ID Join toward a cloud-native Windows environment should not be viewed purely as a device join exercise.

The endpoint sits at the intersection of identity, device management, applications, security, network access, and user experience.

A successful migration strategy needs to consider all of these areas together.

For organizations planning the transition, the most useful approach is often to start small, test different real world scenarios, understand the dependencies, document what happens when something fails, and only then expand the rollout.

The technology involved in moving toward Microsoft Entra ID continues to improve, but the success of an endpoint transformation still depends heavily on how carefully the migration of existing devices is planned and tested.