When I joined Reveleer, one of the first large-scale initiatives on my plate was sunsetting the legacy on-premises Active Directory Domain Services (AD DS) infrastructure and completing a full migration to cloud-native Microsoft Entra join. The fleet at the time was over 800 Windows endpoints, spread across a globally distributed workforce, all hybrid-joined via Entra Connect. The goal was clear: get every device fully cloud-native without re-imaging a single machine, without a meaningful productivity impact, and without a weekend outage window.

Here's how we did it, what broke, and what I'd do differently.

Why Entra Join? Why Now?

Hybrid Entra join — where devices are simultaneously joined to AD DS and registered in Entra ID via Entra Connect — served its purpose during the transition era. But it carries real overhead: you're maintaining two identity planes, synchronisation lag creates edge cases, and GPOs still require line-of-sight to a domain controller. For a cloud-first company like Reveleer, running a full AD DS forest purely to support hybrid join felt like keeping a diesel generator running in the server room just in case.

The business case was straightforward:

  • Operational simplification — one identity plane, one management surface (Intune), no DC dependencies
  • Security posture — eliminate lateral movement paths through AD, enable Conditional Access policies that require compliant Entra-joined state
  • Cost — decommission on-prem DC infrastructure and associated licensing
  • User experience — Platform SSO on macOS, Windows Hello for Business, and seamless SSO without AD reliance

The Migration Strategy: Leave-Join, Not Wipe-Reload

The key architectural decision was to use an in-place leave-join approach rather than re-imaging. This means:

  1. Remove the device from the AD domain (Remove-Computer / disjoin via Intune)
  2. Reboot into a local account context
  3. Join the device directly to Entra ID and enrol into Intune
  4. Apply configuration profiles, compliance policies, and app deployments via Intune
  5. Migrate the user profile in-place using User State Migration Tool (USMT) or local profile reassignment

For this to work cleanly, a large amount of pre-work was required before touching a single device.

Pre-Migration Prerequisites

1. Intune Policy Parity

Every GPO setting that was being enforced needed an Intune equivalent — either a Settings Catalog policy, a custom OMA-URI, or an endpoint security profile. I exported the entire GPO set and audited each policy for Intune equivalence. Anything without a direct mapping needed a decision: recreate via custom profile, accept the gap, or re-engineer the control entirely.

💡 Tip Microsoft's Group Policy Analytics tool in Intune (Devices → Group Policy Analytics) can ingest your GPO XML exports and report on MDM support coverage. It's not perfect but it's a solid starting point for the audit.

2. Application Readiness

Any application that relied on Kerberos authentication to on-prem resources, mapped network drives, or AD-based licensing needed remediating before the device lost its domain membership. We went through the full application inventory and categorised each one:

  • Cloud-native / SaaS — no change needed
  • Kerberos-dependent on-prem apps — migrated to Azure App Proxy or SAML/OIDC equivalents first
  • Mapped drives — replaced with SharePoint / OneDrive sync or Azure Files with Entra-based auth
  • Legacy apps with AD auth — AD DS retained in a minimal state temporarily for these; targeted last

3. Conditional Access Staging

Before migration began, Conditional Access policies were updated to use report-only mode for Entra-joined device compliance requirements. This let us validate policy behaviour against the migrated devices before enforcing, preventing accidental lockouts.

The Migration Wave Approach

We didn't migrate 800 devices at once. We used a phased wave model:

  • Wave 0 — IT team devices only. Deliberately break things and learn. Ran for two weeks.
  • Wave 1 — 50 volunteers from non-critical teams. Monitor for a week.
  • Wave 2–N — Progressively larger cohorts, prioritising teams with the simplest app stacks first.
  • Final wave — Remaining AD-dependent application users, migrated once those apps were fully remediated.

Each wave had a defined rollback plan — a documented procedure to re-join a device to the domain if a critical blocker was hit. In practice, we only needed to rollback three devices across the entire migration.

Automating the Leave-Join Process

For Wave 2 onwards, we automated as much of the migration process as possible. The core workflow was triggered from a FreshService ITSM change ticket and executed via an Azure Automation runbook:


# Simplified example — domain disjoin via Intune Device Action
# Triggered from Azure Automation Runbook via Graph API

$deviceId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
$graphUri  = "https://graph.microsoft.com/v1.0/deviceManagement/managedDevices/$deviceId/retire"

$headers = @{
    Authorization = "Bearer $accessToken"
    "Content-Type" = "application/json"
}

Invoke-RestMethod -Uri $graphUri -Method Post -Headers $headers

The runbook also handled: notifying the end user via email, scheduling the reboot window, and creating the Intune Autopilot pre-provisioning package for the re-enrolment step. Total hands-on IT time per device dropped from approximately 45 minutes to under 5 minutes of oversight.

Profile Migration — The Awkward Part

The trickiest part of a leave-join migration is user profile continuity. When a device leaves the domain, the domain user profile is no longer automatically loaded after Entra join — the device needs a local or Entra-linked profile that maps to the same data.

Our approach was to pre-provision the new Entra user profile before the disjoin by having the user sign in once via a temporary local admin account, trigger OneDrive Known Folder Move, and let the sync complete. Once the profile data was in the cloud, the disjoin/rejoin was just a shell — the data came back down automatically on first sign-in to the Entra-joined state.

⚠️ Watch Out Known Folder Move will fail silently if the user has files in their Desktop, Documents, or Pictures folders that exceed path length limits (260 chars) or contain restricted characters. Run a pre-migration scan for these before starting.

Results

The migration completed across all 800+ devices over approximately 10 weeks:

  • Zero devices re-imaged
  • 3 devices rolled back (all re-migrated successfully in a later wave)
  • ~1,000 hours of productivity preserved — estimated based on a 1.5hr per device re-image baseline
  • AD DS decommissioned in full following the final wave
  • Conditional Access "require compliant device" now enforced across 100% of the fleet

What I'd Do Differently

If I were starting this again, I would invest more time upfront in the application dependency audit. The migration waves were occasionally gated by apps we hadn't fully assessed, which caused delays. A thorough dependency map — built before Wave 0 — would have compressed the overall timeline by 2–3 weeks.

I'd also run the Conditional Access policy simulation earlier. We hit one edge case where a shared device pool used a service account context that didn't satisfy the compliant device policy. Catching that in report-only mode before enforcement saved what could have been a significant incident.

If you're planning a similar migration and want to talk through the architecture, the Intune policy parity process, or the automation approach, feel free to get in touch or connect with me on LinkedIn.