Migrate Active Directory to Azure AD [Step-by-Step]

Migrating from on-premises Active Directory (AD) to Azure Active Directory (now Microsoft Entra ID) is one of the most consequential infrastructure projects an organization undertakes. Identity is the foundation that every application, device, and security policy depends on. A clean migration unlocks cloud-native security features like conditional access and passwordless authentication. A botched migration locks users out of critical systems, breaks application integrations, and creates security gaps that can take months to remediate.

This guide walks through the migration step by step — from assessment and planning through hybrid identity configuration, conditional access deployment, and the eventual transition to cloud-only identity. Whether you are connecting your first Azure AD tenant or planning to decommission your last domain controller, the principles are the same: plan thoroughly, migrate incrementally, and validate at every stage.

For organizations that are also moving infrastructure workloads to Azure, our guide on common issues when migrating to Azure cloud services covers the broader migration context.

Understanding the Migration Landscape

On-Premises AD vs Azure AD

On-premises Active Directory and Azure AD are fundamentally different systems, despite sharing a name. Understanding these differences is critical to planning a successful migration.

Feature	On-Premises AD (AD DS)	Azure AD (Microsoft Entra ID)
Protocol	Kerberos, NTLM, LDAP	OAuth 2.0, SAML, OpenID Connect
Structure	Forests, domains, OUs, GPOs	Flat tenant, no OUs or GPOs
Device management	Group Policy	Intune / Endpoint Manager
Network dependency	Requires line-of-sight to domain controller	Cloud-based, works from anywhere
Authentication	On-premises domain controllers	Microsoft global authentication network
Application support	Legacy apps (LDAP bind, Kerberos)	Modern apps (SAML, OAuth), legacy via App Proxy

The key insight: Azure AD is not a cloud version of on-premises AD. It is a modern identity platform that uses different protocols, different management models, and different security paradigms. Migration is not a lift-and-shift — it is a transformation.

Migration Paths

There are three primary migration paths:

1. Hybrid identity (most common): Synchronize on-premises AD to Azure AD using Azure AD Connect. Both directories coexist. This is the starting point for most organizations.
2. Cloud-only identity: All identity management happens in Azure AD. No on-premises domain controllers. This is the end state for organizations that have fully migrated their workloads to the cloud.
3. Staged migration: Start with hybrid identity, gradually move workloads and applications to Azure AD, and decommission on-premises AD when all dependencies are eliminated.

Most organizations follow path 3 — start hybrid, end cloud-only — over a period of 12-24 months.

Phase 1: Assessment and Planning

Inventory Your Current Environment

Before touching any configuration, document everything in your current AD environment:

Domain structure:

• Number of forests and domains
• Trust relationships between domains
• Domain and forest functional levels
• Sites and subnets configuration

User and group inventory:

• Total user accounts (active and disabled)
• Group types (security groups, distribution lists, dynamic groups)
• Service accounts and their dependencies
• Administrative accounts and privilege levels

Application dependencies:

• Applications that authenticate via LDAP bind
• Applications that use Kerberos delegation
• Applications that rely on Group Policy for configuration
• Applications that query AD for user attributes (employee ID, department, manager)

Group Policy Objects (GPOs):

• Total number of GPOs and what each one configures
• GPOs that map to Intune policies (Wi-Fi profiles, certificate deployment, security settings)
• GPOs that have no Intune equivalent (legacy application settings, login scripts)

Identify Blockers

Common blockers that must be resolved before migration:

• Legacy authentication: Applications that only support NTLM or basic LDAP bind cannot authenticate directly against Azure AD. Options include Azure AD Application Proxy, Azure AD Domain Services (managed domain in the cloud), or application modernization.
• On-premises file shares: Windows file servers use Kerberos for authentication. Moving to Azure Files with Azure AD authentication or migrating to SharePoint Online are the primary paths.
• Print servers: On-premises print infrastructure depends on AD for authentication and GPO for printer deployment. Universal Print is the cloud-native replacement.
• Network dependencies: VPN solutions that authenticate against on-premises AD via RADIUS need to be reconfigured for Azure AD authentication (Azure MFA NPS Extension or migrate to Always On VPN with Azure AD).

Define Success Criteria

Before starting the migration, agree on measurable criteria:

• All users can authenticate to Microsoft 365 and business applications via Azure AD
• MFA is enforced for all users with phishing-resistant methods for administrators
• Conditional access policies replicate or exceed the security posture of existing GPOs
• Self-service password reset is enabled, reducing help desk ticket volume
• Zero unplanned user lockouts during the migration

Phase 2: Set Up Azure AD Connect

Azure AD Connect is the synchronization engine that bridges on-premises AD and Azure AD. It replicates user accounts, groups, and (optionally) password hashes to Azure AD, creating a hybrid identity that lets users authenticate to both on-premises and cloud resources.

Choose Your Authentication Method

Microsoft’s identity architecture guidance provides a comprehensive reference for how Azure AD tenant design and authentication methods interact. This is the most important decision in the Azure AD Connect setup:

Password Hash Synchronization (PHS) — Recommended

PHS synchronizes a hash of the on-premises password hash to Azure AD. Users sign in to cloud services with the same password they use on-premises, but authentication happens against Azure AD’s global network.

Benefits:

• Simplest to deploy and maintain
• Works even if on-premises AD is unavailable (cloud authentication is independent)
• Enables Azure AD Identity Protection (leaked credential detection)
• Supports seamless SSO for domain-joined devices on the corporate network

Pass-Through Authentication (PTA)

PTA validates passwords against on-premises AD in real-time. Authentication requests to Azure AD are forwarded to lightweight agents running on-premises, which validate the password against the local domain controller.

Benefits:

• Passwords are never stored in the cloud (only validated on-premises)
• Enforces on-premises password policies (expiration, complexity, account lockout) in real-time
• Complies with regulatory requirements that prohibit cloud password storage

Drawbacks:

• Requires on-premises infrastructure to be available for cloud authentication
• Additional agents to deploy and maintain
• Does not support Azure AD Identity Protection leaked credential detection

Active Directory Federation Services (ADFS)

ADFS routes all authentication to on-premises federation servers. This was the standard approach before PHS and PTA matured.

Benefits:

• Supports smart card and certificate-based authentication
• Provides the most control over the authentication flow

Drawbacks:

• Complex infrastructure (federation servers, WAP servers, load balancers, certificates)
• Single point of failure if not properly configured for high availability
• Significant operational overhead

Recommendation: Use PHS for most organizations. It provides the best balance of simplicity, resilience, and security. Enable PHS as a backup even if you choose PTA as the primary method — this ensures authentication continues working during on-premises outages.

Install and Configure Azure AD Connect

1. Prepare prerequisites:

   • A server running Windows Server 2016 or later (do not install on a domain controller)
   • Azure AD Global Administrator credentials
   • On-premises AD Enterprise Administrator credentials
   • TLS 1.2 enabled on the Azure AD Connect server

2. Download and install:

   # Download Azure AD Connect from the Microsoft Download Center
   # Run the installer and select Custom installation for full control

3. Configure synchronization scope:

   • Select which domains and OUs to synchronize
   • Exclude service accounts, test accounts, and disabled users
   • Configure attribute filtering if needed (for example, only sync users with a specific attribute value)

4. Configure authentication method:

   • Select Password Hash Synchronization
   • Enable Seamless SSO for domain-joined devices
   • Enable Password Writeback to allow cloud password changes to sync back to on-premises

5. Enable staging mode for initial testing: Azure AD Connect staging mode synchronizes data but does not export changes to Azure AD. This lets you validate the synchronization results before they affect your production Azure AD tenant.

   # After initial sync in staging mode, verify:
   # - Expected number of users appear in the staging connector space
   # - No synchronization errors in the Synchronization Service Manager
   # - Attribute mappings are correct (check UPN, email, display name)

6. Switch to active mode: Once validation is complete, disable staging mode. Azure AD Connect begins exporting synchronized identities to Azure AD.

Validate Synchronization

After enabling active synchronization:

• Verify user accounts appear in Azure AD with correct attributes
• Test SSO by signing in to Microsoft 365 with an on-premises credential
• Check the Azure AD Connect Health dashboard for synchronization errors
• Validate that password changes on-premises propagate to Azure AD (with PHS)
• Test password writeback by changing a password in the Azure AD portal

For troubleshooting identity synchronization issues, including common replication problems, see our guide on troubleshooting Active Directory replication.

Phase 3: Configure Conditional Access

Conditional access is Azure AD’s policy engine for controlling who can access what, from where, and under what conditions. Microsoft’s Zero Trust identity framework provides the strategic context for these policies. It replaces much of what organizations previously accomplished with GPOs, VPN restrictions, and network-based access controls.

Baseline Conditional Access Policies

Deploy these policies in report-only mode first, then switch to enforcement after validating impact:

Policy 1: Require MFA for all users

• Assignments: All users (exclude break-glass accounts)
• Target resources: All cloud apps
• Conditions: None (applies universally)
• Grant: Require multifactor authentication
• Session: Sign-in frequency of 24 hours

Policy 2: Block legacy authentication

• Assignments: All users
• Target resources: All cloud apps
• Conditions: Client apps = Exchange ActiveSync, Other clients
• Grant: Block access

Legacy authentication protocols (IMAP, POP3, SMTP, older Exchange ActiveSync) do not support MFA and are the primary vector for credential stuffing attacks. Block them.

Policy 3: Require compliant devices for sensitive applications

• Assignments: All users
• Target resources: SharePoint Online, Exchange Online, business-critical apps
• Conditions: None
• Grant: Require device to be marked as compliant (via Intune)

Policy 4: Restrict Azure management access

• Assignments: All users
• Target resources: Microsoft Azure Management
• Conditions: None
• Grant: Require MFA + require compliant device
• Session: Sign-in frequency of 1 hour

For more on MFA implementation, see our guide on securing your accounts with multi-factor authentication.

Named Locations

Define your corporate network ranges as named locations. This enables policies like “require MFA only when accessing from outside the corporate network” or “block access from countries where we have no employees.”

# Named locations are configured in the Azure portal:
# Azure AD > Security > Conditional Access > Named locations
# Add your corporate IP ranges and mark them as trusted

Report-Only Mode

Always deploy new conditional access policies in report-only mode before enforcing them. Report-only mode logs what the policy would have done without actually blocking or requiring MFA. Review the sign-in logs after 1-2 weeks to identify:

• Users who would be blocked (and whether that is intentional)
• Applications that would fail (and whether they need exemptions)
• Service accounts or automation that would break

Only switch to “On” after validating that the policy’s impact matches your expectations.

Phase 4: Migrate Device Management

On-premises AD uses Group Policy to manage devices. Azure AD uses Microsoft Intune (part of Microsoft Endpoint Manager). Migrating device management is a critical step because GPOs do not work for Azure AD-joined devices.

Device Join Options

Join Type	Best For	Identity Provider	Management
Azure AD Joined	Cloud-first devices, new deployments	Azure AD only	Intune only
Hybrid Azure AD Joined	Existing domain-joined devices during migration	Both AD and Azure AD	GPO + Intune (co-management)
Azure AD Registered	BYOD, personal devices	Personal account + Azure AD work account	Intune MAM (app-level)

Co-Management with SCCM and Intune

For organizations with existing SCCM (now Microsoft Endpoint Configuration Manager) deployments, co-management allows you to gradually shift workloads from SCCM to Intune:

1. Enable co-management in SCCM
2. Configure Azure AD hybrid join for existing devices
3. Shift workloads one at a time (compliance policies first, then resource access profiles, then device configuration, then Windows Update)
4. Once all workloads are managed by Intune, migrate devices to Azure AD join (removing the on-premises AD dependency)

For a deeper comparison of these management platforms, see our guide on Microsoft Intune vs SCCM.

Translate GPOs to Intune Policies

Microsoft provides the Group Policy analytics tool in Intune that imports GPOs and identifies which settings have Intune equivalents:

1. Export GPOs from on-premises using Get-GPOReport
2. Import the GPO XML files into Intune’s Group Policy analytics
3. Review the compatibility report
4. Create Intune configuration profiles for settings that have direct equivalents
5. Document settings that have no Intune equivalent and determine alternative approaches

Phase 5: Migrate Applications

Applications are usually the longest phase of an AD-to-Azure AD migration because every application has different authentication requirements.

Categorize Applications

Modern authentication (SAML, OAuth, OpenID Connect): These applications can authenticate directly against Azure AD. Add them as Enterprise Applications in Azure AD, configure SSO, and assign users. This is straightforward for SaaS applications (Salesforce, ServiceNow, Slack) and custom applications built on modern frameworks.

For troubleshooting SSO configuration, see our guide on troubleshooting Azure Single Sign-On.

Legacy authentication (LDAP, Kerberos, NTLM): These applications require additional components:

• Azure AD Application Proxy: Publishes on-premises web applications to external users via Azure AD, providing SSO and conditional access without VPN. Supports Kerberos Constrained Delegation for Windows Integrated Authentication.
• Azure AD Domain Services: Provides managed AD DS in Azure — domain join, Group Policy, LDAP, Kerberos — without deploying domain controllers. Useful for legacy applications that cannot be modernized.
• Application modernization: Updating the application to use modern authentication. This is the best long-term solution but requires development effort.

Migration Priority

Migrate applications in this order:

1. Microsoft 365 workloads — Already integrated with Azure AD. Ensure conditional access policies cover Exchange Online, SharePoint Online, and Teams.
2. SaaS applications with Azure AD gallery integration — Pre-built connectors make SSO configuration straightforward.
3. Custom web applications — Update authentication libraries to MSAL (Microsoft Authentication Library) and register the application in Azure AD.
4. On-premises applications via Application Proxy — Publish through Azure AD App Proxy for SSO and conditional access without application changes.
5. Legacy applications requiring AD DS — Use Azure AD Domain Services or plan application modernization.

Phase 6: Plan for Decommissioning On-Premises AD

The end goal for most organizations is to eliminate the dependency on on-premises domain controllers. This reduces infrastructure costs, simplifies management, and eliminates the attack surface associated with on-premises AD.

Decommission Prerequisites

Before decommissioning on-premises AD:

• All users authenticate via Azure AD (PHS or cloud-only accounts)
• All devices are Azure AD joined (not hybrid joined)
• All applications authenticate against Azure AD (no LDAP bind or Kerberos dependencies)
• All GPOs are replaced by Intune policies
• DNS is migrated to Azure DNS or another cloud DNS provider
• DHCP is migrated (if domain controllers were running DHCP)
• Certificates are issued by a cloud CA or public CA (not an on-premises AD CS)
• Azure AD Connect is uninstalled (no longer needed for synchronization)
• Break-glass procedures are tested with cloud-only admin accounts

Phased Decommission

1. Stop creating new objects in on-premises AD. All new users, groups, and devices are created directly in Azure AD.
2. Demote secondary domain controllers once they have no remaining dependencies.
3. Run in parallel with the last domain controller for 30-60 days while monitoring for authentication failures or application errors.
4. Demote the final domain controller and decommission the on-premises AD forest.

Common Pitfalls

UPN Mismatch

Azure AD uses the User Principal Name (UPN) for sign-in. If your on-premises UPN suffix does not match a verified custom domain in Azure AD, users will be assigned a user@tenant.onmicrosoft.com UPN, creating a confusing sign-in experience. Add and verify your custom domain in Azure AD before enabling synchronization.

Forgetting Service Accounts

Service accounts that authenticate via LDAP or Kerberos will break when on-premises AD is decommissioned. Inventory every service account, identify what it connects to, and either migrate it to a managed identity (for Azure resources) or create a cloud-only account with appropriate permissions.

Not Testing Conditional Access in Report-Only Mode

Deploying conditional access policies directly in enforcement mode without testing will lock users out. Always start in report-only mode, review sign-in logs, and confirm that the policy behaves as expected before switching to enforcement.

Skipping Password Hash Sync Backup

Even if you choose PTA as your primary authentication method, enable PHS as a backup. If your on-premises infrastructure goes down (network outage, domain controller failure), PHS ensures users can still authenticate to cloud services.

Ignoring Legacy Protocol Dependencies

Blocking legacy authentication via conditional access is critical for security but will break any application or device that uses IMAP, POP3, or older ActiveSync. Audit legacy authentication usage in the Azure AD sign-in logs before enabling the block policy.

Frequently Asked Questions

How long does an AD to Azure AD migration take?

A typical hybrid identity setup (Azure AD Connect + conditional access) takes 2-4 weeks. A full migration to cloud-only identity — including application migration, device management transition, and domain controller decommission — typically takes 12-24 months, depending on the number of legacy applications and devices.

Do I need Azure AD Premium for this migration?

Azure AD Free (included with Microsoft 365) supports basic synchronization and SSO. Azure AD Premium P1 is required for conditional access, Application Proxy, and dynamic groups. Azure AD Premium P2 adds Identity Protection and Privileged Identity Management. Most organizations need at least P1 for a production migration.

Can I migrate some users before others?

Yes. Azure AD Connect supports OU-based filtering, so you can synchronize specific organizational units and leave others for later. Conditional access policies can target specific groups, allowing you to enforce MFA and device compliance for migrated users while excluding users who are still in the planning phase.

What happens to Group Policy after migration?

GPOs have no effect on Azure AD-joined devices. All device management policies must be replicated in Intune. The Group Policy analytics tool in Intune helps identify which settings have direct equivalents. Settings without Intune equivalents require alternative approaches (custom OMA-URI profiles, PowerShell scripts deployed via Intune, or application-level configuration).

Is Azure AD Domain Services the same as on-premises AD?

No. Azure AD Domain Services (Azure AD DS) provides a managed subset of AD DS features — domain join, LDAP, Kerberos, Group Policy — without deploying domain controllers. However, it is a managed service with limitations: no schema extensions, no forest trusts, no direct access to domain controllers. It is intended as a bridge for legacy applications, not a permanent replacement for a full AD DS deployment.

What is the difference between Azure AD Connect and Azure AD Connect Cloud Sync?

Azure AD Connect is the full-featured synchronization engine installed on-premises. Azure AD Connect Cloud Sync is a lighter-weight alternative that uses provisioning agents and is managed from the cloud. Cloud Sync supports multi-forest scenarios more easily and requires less on-premises infrastructure, but it lacks some advanced features (device writeback, custom sync rules). For most new deployments, Cloud Sync is the recommended starting point.

Next Steps

Migrating Active Directory to Azure AD does not have to be overwhelming. Exodata’s cloud engineering team can help you plan and execute your identity migration — from initial assessment through hybrid identity configuration to full cloud-native identity. Talk to an engineer today — no sales pitch, just answers.