How to migrate Active Directory to Azure

Moving your on-premises Active Directory (AD) environment to Microsoft Entra ID (previously Azure AD) is a big project. It touches authentication, group policies, application access, and security controls all at once. This guide walks you through planning, execution, and post-migration validation so you can handle the transition without losing visibility or control.

Why organizations move AD to the cloud

Most teams aren't migrating for the sake of it. The usual drivers are practical:

• Running domain controllers on-premises means hardware, patching, and physical security overhead that cloud identity services absorb.
• Cloud-based identity lets users authenticate from anywhere without VPN dependencies.
• Organizations running both on-premises AD and cloud apps often end up with duplicate accounts, inconsistent policies, and sync headaches. A single identity platform simplifies this.
• Microsoft Entra ID offers conditional access, risk-based sign-in policies, and MFA as native features rather than bolt-on additions.

None of this means migration is simple. It means there's usually a clear reason behind the decision.

Before you start: assess your current AD environment

Skipping the assessment phase is how migrations go sideways. You need a clear inventory of what exists before you can plan what moves and what changes.

What to document

Start with your domain structure. How many forests and domains do you have? Are there trust relationships between them?

Multi-forest environments add real complexity.

Count your user accounts, service accounts, security groups, and distribution groups. Flag accounts with non-standard configurations, nested group memberships, or stale objects that should be cleaned up before migration.

Then there's Group Policy. On-premises AD leans heavily on GPOs for device configuration, security baselines, and user restrictions. Microsoft Entra ID does not support GPOs, so every policy needs to be mapped to an equivalent Microsoft Intune configuration profile or identified as no longer needed.

Go through your applications and authentication dependencies. Which apps use LDAP authentication? Which ones rely on Kerberos or NTLM?

Cloud identity handles modern protocols like SAML, OAuth 2.0, and OpenID Connect natively, but legacy protocols need workarounds or application updates.

Finally, document your internal DNS zones, conditional forwarders, and any split-brain DNS setups. These will need adjustment during migration.

Common problems found during assessment

Stale computer accounts that haven't authenticated in months. Service accounts with passwords that haven't been rotated in years. Groups nested six layers deep that nobody fully understands.

Orphaned GPOs linked to OUs that no longer serve their original purpose. Clean these up before migration. Migrating a messy environment just gives you a messy cloud environment.

Choosing your migration approach

There's no single migration path. Your approach depends on your environment's complexity, your timeline, and how much disruption you can tolerate.

Hybrid coexistence (most common)

This is what most organizations do. You keep on-premises AD running and sync identities to Microsoft Entra ID using Microsoft Entra Connect (previously Azure AD Connect). Users get a single identity that works in both environments.

This approach lets you migrate workloads gradually. Email moves to Exchange Online. File shares move to SharePoint or OneDrive.

Apps get updated to use modern authentication one at a time. On-premises domain controllers stay in place until everything has moved.

The downside is that you're running two identity systems simultaneously, sometimes for years. That means maintaining sync, monitoring both environments, and managing the inevitable edge cases where something works differently in cloud versus on-premises.

Staged migration

You move groups of users and workloads in planned waves rather than all at once. Wave one might be a pilot group of IT staff. Wave two covers a specific department.

Wave three handles the rest.

This reduces blast radius if something goes wrong. It also lets you learn from each wave and adjust the process before the next one.

Full cutover

Rare for organizations with significant on-premises infrastructure, but possible for smaller environments. You move everything at once over a maintenance window, then decommission on-premises domain controllers.

This only works if your application inventory is small, you've already moved most workloads to cloud services, and your users can tolerate a weekend of potential disruption.

Step-by-step migration process

Step 1: set up your Microsoft Entra ID tenant

If you don't already have one, create a Microsoft Entra ID tenant and configure the basics: custom domain name, admin accounts with MFA enabled, and emergency access accounts.

Emergency access accounts are break-glass accounts that bypass conditional access policies. Set up at least two, store their credentials securely offline, and monitor them for any sign-in activity. You do not want to get locked out of your own tenant during migration.

Step 2: install and configure Microsoft Entra Connect

Microsoft Entra Connect syncs user accounts, groups, and other objects from on-premises AD to Microsoft Entra ID.

During installation, you'll choose a sign-in method:

• Password hash synchronization (PHS). Syncs a hash of the on-premises password hash to the cloud. Users sign in with the same password in both environments. This is the simplest option and the one Microsoft recommends as a baseline.
• Pass-through authentication (PTA). Authentication requests to Microsoft Entra ID get forwarded to on-premises agents that validate the password against local AD. The password never leaves your environment. Requires on-premises agents to be available at all times.
• Federation with AD FS. Routes authentication through Active Directory Federation Services. Gives you the most control over the authentication flow but adds significant infrastructure complexity. Most organizations that used to require AD FS are moving away from it.

Start with password hash synchronization unless you have a specific compliance requirement that prevents password hashes from existing in the cloud.

Step 3: configure sync filtering

You probably don't want to sync everything. Microsoft Entra Connect lets you filter by domain, OU, group, or attribute.

At minimum, exclude your test and development OUs, service accounts that only need local access, and any objects you identified as stale during assessment. Syncing unnecessary objects creates clutter and potential security exposure in your cloud directory.

Step 4: migrate Group Policy to Intune

This is the part that takes longer than anyone estimates.

Export your existing GPOs and map each setting to its Intune equivalent. Some map directly. Others require workarounds.

Some have no cloud equivalent at all, and you'll need to decide whether the policy is still necessary or whether a different approach achieves the same goal.

Focus on security-critical policies first: password policies, device encryption requirements, software restriction policies, and firewall configurations. Cosmetic policies like desktop wallpaper settings can wait.

Step 5: update application authentication

Work through your application inventory and update each app's authentication method.

Applications that already support SAML or OAuth 2.0 are straightforward; register them in Microsoft Entra ID as enterprise applications and configure single sign-on.

Legacy applications that rely on LDAP or Kerberos need more work. Your options include:

• Microsoft Entra application proxy. Publishes on-premises web applications externally and handles pre-authentication through Microsoft Entra ID.
• Microsoft Entra Domain Services. A managed domain service that provides LDAP, Kerberos, and NTLM compatibility in the cloud. Useful for applications that can't be updated but need domain services.
• Application refactoring. Updating the application to use modern authentication. Often the best long-term option but not always feasible in the short term.

Step 6: pilot and validate

Before migrating production users, run a pilot with a small group. Give them at least two weeks to use the new setup in their daily work. Collect feedback on anything that broke, felt different, or required a workaround.

Common pilot findings include apps that weren't in the inventory, conditional access policies that block legitimate workflows, and MFA enrollment confusion. Better to find these with 20 users than 2,000.

Step 7: migrate users in waves

Move users in planned groups, starting with less critical departments and building toward more sensitive ones. For each wave, verify that sign-in works, MFA is enrolled, applications are accessible, and device compliance policies apply correctly.

Keep the on-premises accounts active during migration so you can roll back individual users if needed.

Step 8: decommission on-premises infrastructure

Once all users, devices, and applications have been migrated and validated, you can begin decommissioning on-premises domain controllers. This isn't a single action; it's a process.

Demote domain controllers one at a time, starting with the least critical. Verify DNS resolution, DHCP (if domain controllers were handling it), and any remaining LDAP queries after each decommission. Keep at least one domain controller running until you're fully confident nothing still depends on it.

Monitoring your migration with ADAudit Plus

Migration is exactly the kind of high-risk period where you need the most visibility into what's happening in your AD environment. ADAudit Plus provides real-time auditing and change monitoring that covers both your on-premises AD and cloud sync activities.

During migration

Track every change being made to your directory as objects get moved, modified, or deleted. The User Logon Reports in ADAudit Plus show you whether users are authenticating through the new cloud path or still falling back to on-premises. Logon failure reports help you catch authentication problems before users report them.

The Recently Modified Users report flags unexpected changes during migration windows. If an account gets modified outside your planned change window, you want to know immediately.

After migration

Once migration is complete, ADAudit Plus continues monitoring your environment for security-relevant events. The Account Lockout Analyzer helps you troubleshoot lockout issues that commonly spike after authentication changes. GPO settings changes reports verify that no one has modified your remaining policies without approval.

For ongoing threat detection, ADAudit Plus monitors for attacks that target Active Directory infrastructure specifically, including pass-the-hash attacks, Golden Ticket attacks, Kerberoasting, and DCSync attacks. These threats don't disappear during migration. If anything, the transition period creates additional exposure because security teams are focused on the move rather than on monitoring.

The Unusual Activities Summary by User report uses behavior analytics to flag accounts acting outside their normal patterns. That's particularly valuable during migration, when legitimate activity patterns are changing and malicious activity could hide in the noise.

Common migration mistakes

Skipping the GPO audit. Teams move users to cloud identity and then discover that half their security policies were enforced through GPOs that no longer apply. Audit and migrate policies before moving users.

Ignoring service accounts. Service accounts often have hardcoded credentials and legacy authentication dependencies. Identify every service account, document what it connects to, and plan its migration separately from user accounts.

Underestimating the timeline. A mid-sized organization with 500 users, 50 applications, and a moderate GPO footprint should expect the full migration to take six to 12 months. Larger or more complex environments take longer.

Not monitoring during the transition. The migration period is when your environment is most vulnerable to both misconfiguration and attack. Run ADAudit Plus throughout the process so you have full visibility into changes, logons, and potential threats.

Cutting over too fast. Parallel operation feels wasteful, but it's your safety net. Keep on-premises infrastructure running until you've validated every workload in the cloud.

Post-migration checklist

After completing migration, verify the following:

• All users can sign in through Microsoft Entra ID without falling back to on-premises authentication.
• MFA is enrolled and enforced for all user accounts.
• Conditional access policies are applied and functioning as designed.
• All business applications are accessible and authenticating through cloud identity.
• Device compliance policies are enforced through Intune.
• ADAudit Plus is monitoring the cloud-synced environment and generating alerts on security-relevant events.
• Emergency access accounts are documented, secured, and monitored.
• On-premises domain controllers have been safely decommissioned, or a decommission timeline is in place.
• DNS has been updated to remove references to decommissioned servers.
• A rollback plan exists and has been tested, in case post-migration issues surface weeks later.

Moving forward

Migrating Active Directory to the cloud is less a single project and more a series of interconnected decisions about identity, policy, application architecture, and security monitoring. The technical steps are well-documented. The difficulty is in the details specific to your environment: the legacy app nobody remembers setting up, the GPO that silently enforces a security baseline, the service account that three different systems depend on.

Take the time to assess thoroughly, pilot honestly, and monitor continuously. ADAudit Plus gives you the auditing layer you need to keep visibility into your AD environment throughout the transition and after it's complete.