Migrate Active Directory to Microsoft Entra ID

Plan a phased Active Directory-to-Entra ID migration covering identity sync, application dependencies, devices, security policy, and rollback.

On this page

Link to Introduction: What Migrating from Active Directory to Entra ID Really MeansIntroduction: What Migrating from Active Directory to Entra ID Really Means

Migrating from on-premises Active Directory (AD) to Microsoft Entra ID (formerly Azure AD) is not a matter of replacing one directory with another. Instead, it is a complex transformation that requires you to rethink identity management, security, device management, and authentication models in a cloud-native context. Microsoft Entra ID is architected for the cloud—it does not provide feature or protocol parity with AD and is not a “drop-in” substitute. Key differences include the lack of native support for legacy protocols (LDAP, NTLM, Kerberos), fundamentally different policy application mechanisms, and a cloud-first security posture. While both serve as identity platforms, expectation management is critical: policy translation, authentication rewiring, and application compatibility must all be addressed as deliberate migrations, not automatic conversions.

Link to Phased Migration: The Modern Best PracticePhased Migration: The Modern Best Practice

Microsoft’s recommended migration workflow splits the journey into four distinct phases—discover, pilot, scale, and cut-over. Each phase targets specific workstreams and validation steps to minimize risk and enable iterative troubleshooting:

  • Discover: Inventory users, groups, devices, applications, policies, and dependencies. Assess what must move, what changes, and what can be retired.
  • Pilot: Select a representative subset of users and systems to validate migration tools, hybrid access, synchronization, and policy mapping in a low-risk domain.
  • Scale: Expand migration to additional users and groups, actively monitoring error logs, user experience, and integration with critical applications.
  • Cut-over: Transition all remaining identities, devices, and services, decommission on-premises dependencies, and enforce cloud-native management and security.

This phased approach creates clear gates for testing and rollback, and often exposes previously undocumented dependencies or niche scenarios (such as legacy on-premises-only applications) that require remediation before advancing.

Link to Prerequisites and Architectural DecisionsPrerequisites and Architectural Decisions

Before migration, several foundational decisions must be made:

  • Hybrid vs. Cloud-Only: Many organizations select a hybrid model temporarily, synchronizing identities between on-prem AD and Entra ID to enable staged migration. Full cloud-only operation (with no on-prem AD) is feasible, but legacy app compatibility must be assessed.
  • Azure AD Domain Services (Azure AD DS): For legacy applications requiring LDAP or NTLM/Kerberos, Azure AD DS can be layered on top of Entra ID to provide some on-prem-like protocol support in the cloud. However, not all directory features are replicated.
  • Inventory & Mapping: All account, group, device, GPO, application, and authentication dependencies should be cataloged. Determine which applications rely on legacy protocols or direct AD integration—these will not “just work” against Entra ID.
  • Authentication Planning: Decide at the outset which cloud authentication approaches are required (Password Hash Sync, Pass-Through Authentication, or Federation) and which toolchains (such as Microsoft Entra Connect or Cloud Sync) are suited to your environment.

A careful inventory builds the foundation for a migration plan that recognizes limits and required workarounds up front.

Link to Identity Synchronization: Users, Groups, and DevicesIdentity Synchronization: Users, Groups, and Devices

The pivotal task during migration is synchronizing the core directory objects between on-premises AD and Entra ID. The main tools for this are:

  • Microsoft Entra Connect Sync: The traditional, feature-rich synchronization engine supporting hybrid deployments, with broad options for filtering, attribute mapping, and write-back features. Organizations are encouraged to plan for eventual migration to Cloud Sync as parity improves.
  • Microsoft Entra Cloud Sync: A more lightweight, cloud-managed sync model. Currently, some advanced features (such as device write-back) may not be supported; verify requirements before selection.

Users, groups, and (for hybrid join) devices are synchronized via scheduled and event-driven cycles. Synchronization includes selected attributes and can be filtered for scope. Devices must be joined to Entra ID or hybrid joined to retain management and conditional access capability.

Link to Limitations and GotchasLimitations and Gotchas

  • Not every AD attribute can be synced or consumed in Entra ID—custom or application-specific attributes may require redesign.
  • Nested group structures and complex group types from AD may not map directly.
  • Object conflicts (such as UPN duplication or attribute mismatch) can block synchronization and must be resolved manually.
  • Device objects require specific provisioning steps to appear as managed in Entra ID.

Understanding what each sync engine supports, and limits on object or attribute handling, is vital to avoid migration blockers.

Link to Group Policy Migration: Intune as the New Policy EngineGroup Policy Migration: Intune as the New Policy Engine

On-premises Group Policy Objects (GPOs) are not automatically transferable to Microsoft Entra ID. Cloud management, including device and user policy, is now performed through Microsoft Intune.

Link to Analyzing and Mapping GPOs to IntuneAnalyzing and Mapping GPOs to Intune

  • Group Policy Analytics in Intune: Export on-prem GPOs as XML and import them into Intune’s Group Policy Analytics. This highlights which GPO settings are supported for direct mapping to Intune policies, and where gaps exist.
  • Manual Policy Remapping: Many GPO settings (especially legacy, device-specific, or local script policies) have no direct equivalent in Intune and must be identified for manual re-design or are unsupported in cloud management.

Link to Example: GPO to Intune MappingExample: GPO to Intune Mapping

  1. Export GPOs as XML from Active Directory.
  2. Import GPO XMLs into Intune’s Group Policy Analytics portal.
  3. Review the analytics output to see which policies are:
    • Supported natively by Intune policy templates
    • Supported via Settings Catalog or Custom OMA-URI policies
    • Not supported at all and require alternative approaches or deprecation

Key Limitation: GPO settings deeply tied to Windows domains, local computer configuration, or legacy networking/authentication (such as login scripts or custom ADMX files) will generally not translate.

Link to Authentication and Security TransformationAuthentication and Security Transformation

Authentication in Entra ID departs significantly from traditional AD models. Entra ID operates cloud-natively, using modern authentication standards (OAuth2, OpenID Connect, SAML) and conditional access policies.

Link to Authentication MethodsAuthentication Methods

  • Password Hash Sync (PHS): Cloud authentication where password hashes sync to Entra ID, enabling direct authentication in the cloud, independent of on-prem AD.
  • Pass-Through Authentication (PTA): Authenticates users through on-prem AD, with Entra ID acting as a proxy. Useful during staged migration phases.
  • Federation: On-prem ADFS or third-party federation serves as the authentication authority. This can be phased out after cloud migration.
  • Modern SSO and MFA: Entra ID supports conditional access and Multi-Factor Authentication by default.

Link to Impact on Legacy ApplicationsImpact on Legacy Applications

  • Legacy Protocols: Entra ID does not natively support LDAP, Kerberos, or NTLM authentication for applications or infrastructure. Applications relying on these must be replatformed to consume modern protocols or leverage Azure AD Domain Services to maintain compatibility at a cost of complexity and partial feature fidelity.
  • Device Join: Devices must be joined to Entra ID or hybrid joined for SSO and management; classic domain join flows do not apply.

Plan early for how authentication hand-offs impact key applications—legacy systems will not automatically gain access via Entra ID.

Link to Troubleshooting Migration and Sync IssuesTroubleshooting Migration and Sync Issues

Migration projects are most frequently slowed by synchronization and attribute conflicts, especially during hybrid overlap phases. Common errors include:

  • Synchronization Failures: Caused by UPN mismatches, object filtering mistakes, or attribute conflicts. Official troubleshooting guides detail step-by-step diagnosis: check for domain suffix consistency, duplicate objects, and invalid attribute values.
  • Object Mismatches: Conflicting or duplicate user/group names across AD and Entra ID will halt synchronization. Manual clean-up is often required.
  • Attribute Limitations: Unsupported or misconfigured custom attributes may silently fail to sync; cross-reference the attribute lists of both platforms before migration.

Review synchronization logs and use the built-in Entra Connect or Cloud Sync tools to trace and resolve errors before advancing to scalable migration.

Link to Post-migration: Validation and DecommissionPost-migration: Validation and Decommission

The final stage is to validate that all migrated identities, devices, and policies are functioning in the cloud context, and that no critical dependency on on-premises AD remains.

Checklist for Cut-over:

  • All users, groups, and devices are present and correctly attributed in Entra ID.
  • Critical applications are successfully authenticating using cloud-native protocols.
  • Required GPOs have been recreated, mapped, or replaced in Intune, and tested on enrolled devices.
  • Post-migration synchronization reports are error-free; object conflicts and sync warnings have been resolved.
  • Legacy protocols, scripts, and device join flows have been audited for cloud-compatibility or replaced.
  • Users and support teams are trained on new login and policy processes.

Only after all validation steps have successfully passed should the on-premises AD domain controllers be retired. Ongoing monitoring, especially for edge or legacy use cases, is recommended for several weeks after cut-over.


Sources:

  • Road to the cloud - Move identity and access management to Microsoft Entra ID
  • Introduction to Microsoft Entra Connect V2
  • Understand Microsoft Entra Connect Sync
  • Use Microsoft Intune to import and analyze group policies
  • Migration guide: Set up or move to Microsoft Intune
  • Microsoft Entra Connect: Troubleshoot object synchronization
  • Troubleshoot errors during synchronization

Link to SourcesSources