DEV Community: Kumar

From Domain-Joined to Microsoft Entra Joined: A Practical Framework for Low-Disruption Windows Migration

Kumar — Tue, 22 Sep 2026 13:44:35 +0000

How the right in-place migration approach can preserve eligible user profiles, establish Intune management, and accelerate the move away from on-premises Active Directory.

Cloud-native endpoint management is relatively straightforward when a Windows device is new. The harder problem is the installed base: hundreds or thousands of working laptops and desktops that already contain user profiles, local files, applications, certificates, security controls, and years of configuration.

Resetting and re-provisioning those devices is a valid route, but it can introduce significant coordination, user downtime, application rebuilding, and service-desk demand. This often creates a practical gap between an organisation's cloud strategy and its ability to move the existing fleet.

Can an existing domain-joined or hybrid Microsoft Entra joined Windows device move to Microsoft Entra join without being wiped or re-imaged?

For eligible devices, the technical answer can be yes, when specialized migration tooling, careful preparation, and a controlled recovery model are used. However, an important support distinction must be made at the outset.

The Microsoft support boundary matters
Microsoft recommends Microsoft Entra joined, cloud-managed endpoints as the strategic direction for organisations that are ready to reduce their reliance on on-premises infrastructure. Microsoft also states that its supported path for converting an existing Active Directory-joined or hybrid Microsoft Entra joined device to Microsoft Entra join requires a Windows reset; it does not provide a Microsoft-supported, no-reset conversion path for that scenario. See Microsoft's guidance on Microsoft Entra join and hybrid join.

A no-reset migration is therefore not a hidden Microsoft feature. It is a vendor-supported, tool-assisted workflow that orchestrates Windows, Microsoft Entra ID, Microsoft Intune, and Microsoft Graph capabilities and adds the missing profile-continuity and recovery layers. Microsoft may support the underlying platform components, but not the end-to-end no-reset conversion.

That distinction does not put the approach in conflict with Microsoft's direction. The destination, Microsoft Entra joined devices managed by Intune, is aligned with Microsoft's cloud-native endpoint strategy. The bridge used to move the existing fleet is specialized and must be validated through a representative proof of concept, with clear ownership for support and recovery.

The strategic destination can be Microsoft-native even when the migration bridge is specialized.

What “seamless” should mean in practice

“Seamless” should not mean that nothing changes. A credible low-disruption migration may still require a user sign-out, controlled restarts, a first sign-in with Microsoft Entra credentials, Windows Hello re-provisioning, and re-authentication to some applications.

Instead, a successful in-place migration should aim to achieve the following:

Retain the same physical device and Windows installation.
Keep the eligible local Windows profile, local files, installed applications, and compatible settings in place.
Re-associate that profile with the correct Microsoft Entra identity.
Establish or re-establish Intune management in a controlled manner.
Restore the intended application and policy targeting.
Protect BitLocker and local-administrator recovery throughout the transition.
Limit the interactive cutover to a predictable maintenance window.
Produce verifiable evidence that identity, management, security, and user productivity are working after the change.

The join operation is a milestone; it is not the entire migration. A device is truly migrated only when the user can work and the required security controls are demonstrably active.

A step-by-step framework for an in-place migration

Step 1: Define the complete target state
Do not define success simply as “Microsoft Entra joined.” The target state should cover four connected layers:
Device trust

The endpoint is Microsoft Entra joined in the correct tenant and is no longer joined to the on-premises domain where that is the intended outcome. Management
The endpoint is enrolled in Intune, has the correct corporate/personal ownership classification and primary user, has the required Microsoft Entra registered owner where applicable, and receives the required applications and configurations. User continuity
The correct user can sign in to the existing eligible profile and access the files, applications, and services needed for work. Security and recovery
Compliance is evaluated, Conditional Access behaves as designed, and BitLocker, Windows LAPS, Defender, certificates, and recovery access are validated.

For new designs, a supported Windows 11 edition capable of Microsoft Entra join should be the forward-looking baseline; Windows Home editions cannot be Microsoft Entra joined. Windows 10 reached end of support on 14 October 2025; ESU, LTSC, or other exceptional servicing scenarios should be assessed separately against Microsoft's lifecycle information.

Step 2: Discover dependencies and segment the estate
An accurate inventory determines which devices are suitable for an in-place path. At a minimum, collect:

Current join and management state.
Windows version, edition, servicing status, disk health, free space, and pending restarts.
Primary and additional local profiles, including profile health and size.
Source account, target user principal name, and any identity-mapping exceptions.
BitLocker status, recovery-key location, and local-administrator or LAPS recovery route.
Applications that use AD computer authentication, legacy protocols, device certificates, or domain service accounts.
GPO-delivered settings, mapped drives, printers, folder redirection, logon scripts, Wi-Fi, VPN, and certificate delivery.
Windows Hello, Credential Manager, EFS, private keys, and other identity-bound data.
Network location, proxy behavior, endpoint security controls, and remote-worker constraints.

Use the findings to classify devices into practical groups:

Ready for a tool-assisted in-place migration.
Ready after remediation.
Better suited to reset and Windows Autopilot.
Better suited to hardware replacement.
Temporarily retained as a managed hybrid exception because a dependency remains.

This segmentation prevents a small number of unsuitable devices from setting the risk profile for the entire project.

Step 3: Replace the policy dependencies, not merely the join state

Once a device leaves Active Directory, Group Policy no longer refreshes. Existing registry-based settings may remain on the device, while mapped drives, printers, folder redirection, scripts, certificates, Wi-Fi, and VPN configuration may require a cloud-management replacement.

Microsoft's Group Policy analytics in Intune can help identify which GPO settings have a cloud-management equivalent. The goal should not be to copy every historical setting. It should be to rebuild the controls the organisation still requires through Intune, rationalizing old policies along the way.

Applications that rely on an AD computer account or machine authentication deserve particular attention. Device migration cannot make an application cloud-ready; application and infrastructure modernization remain separate work streams.

Step 4: Prepare Microsoft Entra ID and Intune before touching a device
The destination must be ready before the source trust is removed. Confirm:

Target user identities exist, are enabled, and use the intended sign-in names.
Required Microsoft Entra ID and Intune licences are active.
Device-join permissions, device limits, MDM authority, enrollment restrictions, and ownership rules are correct.
The correct users are included in the Intune MDM user scope.
Required applications, configuration profiles, security baselines, certificates, Wi-Fi, VPN, and update policies are assigned.
Compliance policies and Conditional Access rules include a safe enrollment and bootstrap path.
Access to required on-premises resources has been tested from a Microsoft Entra joined device.

Microsoft documents that eligible corporate devices can automatically enroll in Intune when they join Microsoft Entra ID, provided licensing and MDM scope are configured correctly.

Conditional Access deserves careful sequencing. A device may need time to enroll, receive policy, and report compliance. Temporary exceptions, if required, should be narrow, documented, monitored, time-bound, and removed as soon as the migration wave is complete. Compliance does not migrate from the old device record; it must be evaluated again in the target state.

Step 5: Secure the migration control plane
A mature migration design should use a customer-controlled Microsoft Entra application with only the Microsoft Graph permissions required for the enabled functions. Application credentials should be protected, rotated, audited, and revoked when no longer required. Microsoft recommends applying the principle of least privilege to Microsoft Graph permissions.

Where the selected workflow requires credentials to update, disable, or delete source AD computer objects, use a dedicated identity with narrowly delegated permissions rather than broad domain administration.

If the workflow uses a Windows Configuration Designer provisioning package, treat it as a privileged credential. Microsoft's bulk enrollment documentation notes that the embedded bulk token can be valid for up to 180 days and that MFA is not supported in that particular token flow. Microsoft documents bulk provisioning for new devices, not as a native in-place profile-migration method, so any orchestration around it remains part of the specialized workflow. Protect the package, scope any necessary policy exception tightly, test it on a non-production device, and revoke it after use.

Endpoint security controls also need advance preparation. Any approved migration executable and the system actions it performs must be tested against EDR, antivirus, WDAC, AppLocker, hardening policies, and proxy controls. A good architecture should not require a persistent endpoint agent after the migration is complete.

Step 6: Build recovery into the design
Changing device trust crosses several systems and is not one atomic transaction. A credible plan therefore starts with recovery, not optimism.

Before migration:

Confirm that critical user data is backed up or successfully synchronized to an approved location. Keeping files on the same disk is not a substitute for backup.
Confirm that a working BitLocker recovery password is available through an approved location.
Confirm a tested local-administrator or Windows LAPS break-glass route.
Keep source recovery information available until target escrow is verified.
Record the source join state, device identifiers, user-to-profile mapping, primary user, group assignments, and management state.
Define stop points and avoid irreversible source cleanup until the target state has been validated, where the workflow permits.
Document who owns endpoint recovery, identity recovery, and user support.

Microsoft recommends storing BitLocker recovery information for Microsoft Entra joined devices in Microsoft Entra ID; see the BitLocker recovery overview. Windows LAPS can back up managed local-administrator passwords to Microsoft Entra ID on Microsoft Entra joined devices.

Do not accept a vague “rollback” promise. Look for phase-aware, checkpoint-based recovery that can identify the failure stage, preserve administrative access, and safely resume or repair the workflow. Reset or re-image should remain the documented last-resort recovery path.

Step 7: Run a representative proof of concept
A pilot built only from clean IT laptops proves very little. Include representative devices and users, such as:

AD-joined and hybrid Microsoft Entra joined endpoints.
Office-based and fully remote users.
Different hardware models and supported Windows builds.
BitLocker-protected devices.
Large or multiple eligible local profiles.
Certificate-based Wi-Fi or VPN.
Business-critical and internally developed applications.
Users who still require on-premises file, print, or application access.

Define success before the pilot begins. Measure device join, Intune enrollment, policy receipt, compliance evaluation, BitLocker escrow, pre-cutover local-administrator or LAPS recovery, post-migration Windows LAPS policy and backup operation, application access, profile continuity, user downtime, failure rate, and recovery effort.

The purpose of the pilot is not merely to prove that a device can join Microsoft Entra ID. It is to prove that a real user can remain productive afterward.

Step 8: Apply a strict per-device readiness gate
Immediately before cutover, an automated preflight should verify:

Supported source and target states.
A healthy, supported Windows installation and local profile.
A valid source-user-to-target-user mapping.
Intune enrollment eligibility and available device capacity.
Stable power, internet, DNS, and non-interactive system connectivity.
Sufficient privileges for the required system operations.
Accessible BitLocker and local-administrator recovery.
No blocking restart, disk, encryption, proxy, or security-software condition.
An unloaded profile during the identity-re association stage.
Valid target-join material and required API access.

Unsafe devices should be blocked and routed to remediation rather than allowed to fail halfway through the trust transition.

Step 9: Capture the state that must be reconstructed
Before changing identity, a capable workflow should record the data required to rebuild the intended management relationship, including:

Source user, target user, profile path, and security identifiers used for correlation.
Existing Microsoft Entra, Intune, and Autopilot device identifiers where relevant.
Intune primary user and ownership information where applicable.
Assigned device-group memberships and any groups that must not be recreated.
Device attributes or tags used for policy and application targeting.
BitLocker recovery-key identifiers and administrative recovery status.
Local execution logs and a central audit record.

In a cross-tenant migration, group object IDs and device records are different. Memberships cannot simply be copied; source intent must be mapped to equivalent target groups, while dynamic membership must recalculate from target-tenant attributes.

Step 10: Execute a protected identity transition
The exact order varies by tool and environment. The following three phases are an illustrative orchestration model, not a universal sequence for every tool.

1. Prepare and detach
The workflow confirms readiness, protects the starting state, prevents sign-in during sensitive operations, and removes or transitions the former domain, registration, or management relationship in the planned sequence.

2. Establish the target identity
The selected tooling establishes the target Microsoft Entra join using Windows join or provisioning interfaces. Use of documented platform interfaces does not make the overall no-reset conversion a Microsoft-supported migration path. Controlled restarts and state checks confirm that the target trust was created before the workflow continues.

3. Re-associate and finalize
While the old user profile is fully unloaded, specialized tooling associates the existing eligible local profile with the correct target Microsoft Entra identity and aligns the necessary permissions. The local files do not need to be copied to an intermediate location simply to maintain the profile. After the protected stage, the user signs in with the Microsoft Entra account and final management, recovery, and cleanup tasks complete.

This is the specialized part of the process. Microsoft does not provide a native supported AD-to-Entra profile-conversion utility, and its documentation states that, USMT does not support moving profiles from AD-joined devices to Microsoft Entra joined devices. The capability, support, and recovery obligations therefore belong to the chosen migration method.

Profile continuity must also be described honestly. Windows Hello, passkeys, cached authentication tokens, Credential Manager entries, user-bound certificates and private keys, EFS-encrypted files, application licences, and some Outlook, OneDrive, or browser state may require re-authentication, re-provisioning, or separate recovery. Installed software can remain on the device without every identity-bound secret remaining usable. Endpoint migration does not migrate Exchange mailboxes, OneDrive or SharePoint content, Teams data, or other Microsoft 365 workloads; cross-tenant data migration requires a separate plan.

Step 11: Re-establish management and policy intent
Following the identity transition, the workflow should ensure that the endpoint:

Enrolls in the correct Intune tenant and obtains valid management certificates.
Has the correct primary user and ownership classification where applicable.
Receives the intended device-group assignments, attributes, applications, and configuration.
Re-onboards to Microsoft Defender for Endpoint where required.
Escrows BitLocker recovery information to the intended target record.
Receives the target Windows LAPS policy and proves administrative recoverability.
Registers with Windows Autopilot for future reset, re-purpose, or replacement workflows where that is part of the lifecycle design.
Removes obsolete source objects or management components only after the target state is proven. Be precise with the language: the same physical Windows installation may be retained, but new Microsoft Entra and Intune objects can be created. Intune enrollment is re-established, not magically “preserved,” and compliance must be recalculated after check-in.

Step 12: Validate, observe, and scale in waves
Validation should cover four dimensions.
Identity

Correct Microsoft Entra tenant and device record.
AzureAdJoined : YES, DomainJoined : NO where intended, and successful device authentication in dsregcmd /status.
A Primary Refresh Token for the signed-in user where expected. Microsoft documents these checks in its dsregcmd troubleshooting guidance.

Management and security

Intune check-in, correct primary user, policy delivery, Defender status, and compliance evaluation.
Expected Conditional Access behaviour.
Verified BitLocker recovery escrow and Windows LAPS operation.
Required security baselines, certificates, updates, Wi-Fi, and VPN profiles.

User continuity

Desktop, documents, permitted local data, and compatible application settings.
Microsoft 365, OneDrive, browser, Outlook, printers, mapped resources, and line-of-business applications.
Expected reauthentication and Windows Hello provisioning.

Business productivity

SaaS access, required on-premises access, collaboration tools, and help-desk acceptance tests.

Scale only after results are visible per device. A capable platform should provide central status, phase-level telemetry, error details, local Windows event logging, retry or recovery controls, and auditable outcomes. Migration can then proceed through technical validation, representative pilot, early adopters, departmental or location-based waves, broad rollout, and an exception queue. Depending on the operating model, deployment may use Intune, Group Policy, another endpoint-management platform, or a controlled manual process. Suitable endpoint-local architectures can also avoid a dedicated on-premises migration server.

Define pause thresholds for first-pass failures, Intune enrollment delays, compliance delays, application incidents, and manual-recovery volume.

Both centrally scheduled and guided self-service execution can be useful, depending on the user population and support model.
Remote migration may be possible over the internet, but “no VPN required” should never be treated as universal. The answer depends on the domain-leave method, deployment channel, proxy, certificates, Wi-Fi, applications, and source-cleanup requirements. Remote scenarios need stable power, reliable connectivity, clear user communication, and a tested break-glass channel.

What capable migration tooling should provide
Automated readiness assessment

Stops unsuitable devices before they enter a sensitive transition. Explicit identity mapping
Connects the correct existing profile to the correct target user. In-place profile reassociation
Preserves eligible local user state without rebuilding or copying the entire profile. Eligible multi-user profile handling
Supports shared devices only when every profile and identity mapping is explicitly supported and proven in the pilot. Controlled sign-in and restart handling
Prevents a user or background process from loading the profile during reassociation. Join and enrollment orchestration
Coordinates domain departure, Microsoft Entra join, and Intune enrollment in the correct order. Primary-user, group, and attribute handling
Reconstructs policy and application targeting without claiming that compliance state transfers. BitLocker and administrative recovery controls
Maintains a usable recovery path throughout the identity gap. Source and target object hygiene
Reduces duplicate, orphaned, or stale identity and management records. Remote and wave-based deployment
Supports distributed workforces, schedules, rings, pauses, and exceptions. IT-driven and guided user modes
Allows the operating model to match different user groups and support capacity. Central telemetry and local logs
Gives IT evidence of each phase rather than relying on user reports. Checkpoint-based recovery
Resumes or repairs partial transitions without promising an unrealistic one-click rollback. Least-privilege and transparent data handling
Limits tenant access and makes it clear what device, identity, recovery, and diagnostic data is processed. No persistent endpoint agent after completion
Avoids adding a permanent management dependency solely for a one-time transition.

The right question is not, “Can the tool run a join command?” It is, “Can it safely coordinate identity, profile, management, recovery, and validation at enterprise scale?”

How this complements Windows Autopilot
Windows Autopilot and in-place migration solve different lifecycle problems. Microsoft describes Autopilot as a set of technologies for setting up and pre-configuring new devices and for resetting, re-purposing, and recovering existing devices. It should remain a core part of the future device lifecycle; see the Windows Autopilot overview.

Device situation - Sensible approach
New, replacement, or intentionally reset device - Use Microsoft Entra join through Windows Autopilot.

Healthy existing device where eligible working state must remain substantially intact - Evaluate a vendor-supported, tool-assisted in-place migration through a representative proof of concept.
Unhealthy, unsupported, or end-of-life device - Reset, rebuild, or replace it.

Device with an unresolved legacy dependency - Remediate the dependency first or retain the device temporarily as a controlled hybrid exception.

Windows Autopilot Reset should also be described accurately. On supported Microsoft Entra joined devices it removes personal files, apps, and settings while maintaining the Microsoft Entra and Intune connections; it does not support hybrid Microsoft Entra joined devices. Microsoft's Autopilot Reset documentation explains that use case.

In-place migration does not replace Autopilot. It can help modernize the installed fleet, after which Autopilot can support the device's future reset, repurpose, recovery, and replacement lifecycle.

When an in-place path may not be the right choice
Reset or replacement may be safer when a device has:
An unhealthy Windows installation, damaged disk, or corrupted profile.

An unsupported edition or servicing state.
A roaming, mandatory, temporary, VDI, FSLogix, or other containerized profile that the selected method does not explicitly support.
EFS-encrypted content or critical private keys without a verified recovery plan.
Business applications that require the AD computer account or cannot operate from a Microsoft Entra joined device.
Kiosk, shared, laboratory, privileged-access, or other specialized configurations that require a separate design.
So much historical configuration debt that a clean baseline is more valuable than preserving the current state. Low disruption is an eligibility-based design choice, not a guarantee for every endpoint.

The practical way forward
Reducing dependency on on-premises Active Directory does not have to be a big-bang rebuild of every Windows device. With the right discovery, target preparation, specialized migration tooling, security controls, and phased validation, eligible devices can move to a Microsoft Entra joined and Intune-managed state while keeping much of the user's familiar working environment in place.
The most successful programs treat the change as more than a device join. They coordinate device trust, endpoint management, user continuity, and recovery as one controlled process. They use Windows Autopilot for new and reset devices, a vendor-supported in-place path where preserving the existing working state has clear business value and reset or replacement where it is technically safer. please refer Opsole Migrate for more insights.

That is the practical path to faster endpoint modernization: align the destination with Microsoft's cloud-native strategy, choose the migration route according to device condition and business need, and declare success only after both security and user productivity have been verified.

Resources Reference:
Cloud-native Windows endpoints overview
Microsoft Entra joined versus hybrid Microsoft Entra joined endpoints
High-level planning guide for cloud-native endpoints
Plan a Microsoft Entra device deployment
Set up automatic enrollment for Windows devices
What USMT migrates—and does not migrate
Windows Autopilot overview
BitLocker recovery overview
Windows LAPS overview
Opsole Migrate

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.