IAM Cloud Migration Guide: From On-Prem Active Directory to Cloud Identity

For two decades, on-premises Active Directory has been the gravitational center of enterprise identity. Every employee account, group policy, service principal, and trust relationship lives in AD. But as organizations move workloads to the cloud, the limitations of a data-center-bound directory become painfully apparent: remote workers VPN back to authenticate, cloud applications require clunky federation bridges, and every new SaaS vendor asks why you cannot just use OIDC.

Migrating identity from on-premises AD to cloud IAM is one of the most consequential infrastructure projects an organization will undertake. Get it right and you unlock modern authentication, eliminate hardware dependencies, and simplify operations. Get it wrong and you lock users out, break application integrations, and create a hybrid mess that is harder to manage than the original environment.

This guide provides a phased, risk-managed approach to IAM cloud migration that keeps the business running throughout the transition.

What You Will Learn

• How to assess your current AD environment and plan the migration
• Designing a hybrid identity architecture for the coexistence phase
• Migrating users, groups, policies, and applications in the right order
• Managing the parallel-run period without doubling operational overhead
• Executing the cutover and decommissioning on-premises AD
• Handling the hardest migration challenges: service accounts, legacy apps, and GPOs

Prerequisites

1. Current state documentation — You need a thorough inventory of your AD environment: domains, forests, trust relationships, domain controllers, sites, organizational units (OUs), Group Policy Objects (GPOs), and the applications that depend on AD for authentication or authorization.
2. Cloud IAM tenant — An established cloud identity platform tenant. This guide uses Microsoft Entra ID (Azure AD) as the primary example because it has the most mature AD migration path, but the principles apply to Okta, Google Workspace, or JumpCloud migrations as well.
3. Hybrid connectivity — Network connectivity between your on-premises environment and the cloud tenant. For Entra ID, this means Azure AD Connect (now Entra Connect) is deployed or can be deployed. For other platforms, equivalent directory sync agents.
4. Application inventory — A catalog of every application that authenticates against AD, including authentication protocol (Kerberos, NTLM, LDAP, SAML, OIDC), level of criticality, and the application owner.
5. Stakeholder alignment — Migration touches every department. IT operations, security, compliance, HR, and application owners all need to understand the timeline and their responsibilities.

Architecture Overview

IAM cloud migration is not a forklift move. It is a graduated transition through three architectural phases: on-premises, hybrid, and cloud-native. Most organizations will spend 12-24 months in the hybrid phase, and some will remain there permanently for specific workloads.

Phase 1: On-Premises (Current State)

Active Directory Domain Services (AD DS) running on domain controllers in your data center. All authentication flows through Kerberos or NTLM. Group Policy manages device configuration. LDAP provides directory lookups for applications. Federation services (ADFS) bridge to cloud applications.

Phase 2: Hybrid Identity (Transition State)

A cloud directory (Entra ID) synchronized with on-premises AD via a sync agent. Users have a single identity that works in both environments. Authentication can happen on-premises (for legacy apps) or in the cloud (for SaaS and modern apps). This is the coexistence phase where both directories are authoritative for different things.

Phase 3: Cloud-Native (Target State)

The cloud directory is the authoritative identity source. On-premises AD is either decommissioned entirely or reduced to a minimal footprint for legacy applications that cannot migrate. New users are created in the cloud directory. Policies are managed through cloud-native tools (Conditional Access, Intune) rather than GPOs. Authentication is passwordless, modern, and location-independent.

Key Decision: Migration Scope

Not every organization needs to reach Phase 3 for every workload. The right target state depends on your environment:

• Full cloud migration: All applications can authenticate via modern protocols (SAML, OIDC, SCIM). No Kerberos/NTLM/LDAP dependencies remain. On-premises AD is decommissioned completely.
• Hybrid permanent: Cloud IAM is primary for most users and applications, but a reduced on-premises AD remains for legacy applications, manufacturing systems, or air-gapped environments that cannot use cloud authentication.
• Staged migration: Different business units or regions migrate at different speeds based on their application portfolio and regulatory requirements.

Step-by-Step Implementation

Step 1: Assess the Current Environment

A thorough assessment prevents surprises during migration. Examine the following:

Domain and forest topology:

• How many forests and domains exist? Single-forest, single-domain is the simplest migration. Multi-forest environments require careful planning around which forest becomes the cloud sync source.
• Are there external trust relationships with partner organizations? These will need to be replaced with cloud federation.
• What is the domain functional level? Older functional levels may lack features needed for hybrid operation.

User and group analysis:

• Total user count (enabled and disabled). Cloud licensing is per-user, so this determines cost.
• Group count and nesting depth. Deeply nested groups (more than 3 levels) cause sync issues and should be flattened before migration.
• Distribution lists vs. security groups. Cloud platforms handle these differently.
• UPN (User Principal Name) format. Cloud authentication requires routable UPNs (e.g., user@company.com, not user@company.local). If your AD uses a non-routable UPN suffix, you need to add a routable suffix and update user accounts before sync.

Authentication protocol inventory:

Catalog every authentication protocol in use and the applications that depend on each:

• Kerberos: The default for domain-joined Windows applications. Cannot be used directly in the cloud. Applications using Kerberos need migration to modern protocols or need an on-premises presence (domain controller, application proxy) to continue functioning.
• NTLM: Legacy protocol used by older applications. Similar constraints to Kerberos but weaker security. Prioritize migrating NTLM-dependent applications.
• LDAP / LDAPS: Applications that query AD directly for user lookups, group membership checks, or authentication. Cloud alternatives include Entra ID Domain Services (managed LDAP) or application-level migration to Graph API / SCIM.
• SAML / OIDC: Already cloud-ready. These applications need minimal changes — just point them at the cloud IdP instead of ADFS.

Group Policy inventory:

Export all GPOs and categorize them:

• Device configuration: Mapped to Intune configuration profiles or compliance policies.
• Security settings: Mapped to Conditional Access policies and security baselines.
• Software deployment: Mapped to Intune application deployment or endpoint management tools.
• Login scripts: Need to be replaced with cloud-native equivalents (Intune scripts, Azure Automation).

Step 2: Prepare the Environment

Fix UPN suffixes: If your AD uses non-routable suffixes (.local, .internal), add a routable suffix matching your verified domain and update user accounts. This can be scripted for bulk updates but should be tested with a pilot group first.

# Add routable UPN suffix to AD forest
Set-ADForest -Identity "company.local" `
  -UPNSuffixes @{Add="company.com"}

# Update user UPN (pilot group)
Get-ADUser -Filter {Department -eq "IT"} |
  ForEach-Object {
    $newUPN = $_.SamAccountName + "@company.com"
    Set-ADUser $_ -UserPrincipalName $newUPN
  }

Clean up stale objects: Disable or delete user accounts that have not authenticated in 90+ days. Remove empty groups, orphaned computer accounts, and obsolete OUs. Every stale object you sync to the cloud is wasted licensing and noise.

Flatten group nesting: Reduce group nesting to a maximum of 2 levels. Cloud sync handles nesting but deep hierarchies cause performance issues and confusing authorization behavior.

Document service accounts: Identify every service account, what it is used for, what applications depend on it, and whether it can be migrated to a managed identity or cloud service principal. This is typically the most time-consuming preparation step.

Configure hybrid networking: Establish connectivity between your on-premises network and the cloud tenant. For Azure, this means Azure ExpressRoute or VPN Gateway. Verify that DNS resolution works in both directions.

Step 3: Deploy Hybrid Identity Synchronization

This step establishes the bridge between on-premises AD and the cloud directory.

For Microsoft Entra ID:

1. Deploy Entra Connect (formerly Azure AD Connect) on a dedicated, domain-joined server. Do not install it on a domain controller.
2. Configure sync scope: select the OUs containing users and groups to sync. Exclude service accounts, computer accounts, and OUs containing objects you cleaned up in Step 2.
3. Choose the authentication method:
   • Password Hash Sync (PHS): Syncs a hash of the password hash to Entra ID. Simplest, most resilient option. Users can authenticate to the cloud even if on-premises AD is down. Recommended as the baseline.
   • Pass-Through Authentication (PTA): Authentication requests are forwarded to on-premises AD in real time. No password data stored in the cloud. Requires on-premises agents to be available for every authentication.
   • Federation (ADFS): All authentication handled by on-premises ADFS. Most complex, least resilient. Only recommended if you have regulatory requirements that prevent any form of password sync.
4. Enable Password Hash Sync even if you choose PTA or ADFS as the primary method. PHS serves as a disaster recovery fallback.
5. Enable Seamless SSO so domain-joined devices authenticate to cloud resources without prompting for credentials.
6. Run an initial sync and verify: user accounts appear in Entra ID with correct UPN, display name, and group memberships.

For other platforms:

• Okta: Deploy the Okta AD Agent on a domain-joined server. Configure import rules and attribute mapping in the Okta admin console.
• Google Workspace: Deploy Google Cloud Directory Sync (GCDS) to synchronize users and groups.
• JumpCloud: Deploy the JumpCloud AD Bridge agent for bidirectional sync.

Step 4: Migrate Authentication Sources

With hybrid sync running, begin migrating applications from on-premises authentication to cloud authentication.

Priority order:

1. SaaS applications currently using ADFS federation. Redirect their federation trust from ADFS to Entra ID (or your cloud IdP). This is often a metadata swap — update the SP's IdP metadata URL. Test with a pilot group before switching all users.

2. Internal web applications using SAML/OIDC. Update the application's IdP configuration to point at the cloud IdP. If the application uses client libraries (MSAL, passport.js), update the authority URL.

3. Internal web applications using Windows Integrated Authentication (Kerberos). Deploy Entra Application Proxy (or equivalent reverse proxy) to broker Kerberos authentication. The proxy authenticates the user via the cloud IdP, then performs Kerberos constrained delegation to the backend application. The application does not change.

4. LDAP-dependent applications. Options include:

   • Migrate the application to use Graph API or SCIM for directory queries (best option if the application supports it).
   • Deploy Entra ID Domain Services, which provides managed LDAP and Kerberos endpoints backed by the cloud directory.
   • Maintain a minimal on-premises AD specifically for these applications (hybrid permanent).

5. Thick client and desktop applications using Kerberos/NTLM. These are the hardest to migrate. Options include application modernization, terminal server deployment with cloud authentication at the gateway, or maintaining on-premises AD for these specific applications.

Step 5: Migrate Device Management

Replace Group Policy with cloud-native device management:

1. Enable Entra ID Join for new devices. New devices are joined to Entra ID rather than on-premises AD. They are managed by Intune rather than Group Policy.
2. Migrate existing devices using Hybrid Entra ID Join as a transitional step. Devices remain joined to on-premises AD but are also registered in Entra ID, allowing Intune policies to be applied alongside GPOs.
3. Translate GPOs to Intune policies. Use the Group Policy Analytics tool in Intune to identify which GPOs have direct cloud equivalents. Manually translate custom GPOs.
4. Phase out GPO dependency. Once Intune policies cover all required configurations, begin removing GPO assignments. Keep GPOs in place but disabled for rollback during the transition.

Step 6: Implement Cloud-Native Security Controls

Replace on-premises security infrastructure with cloud-native equivalents:

Conditional Access replaces network-based security:

On-premises AD relied on the corporate network as a security boundary. Cloud IAM uses Conditional Access policies that evaluate device compliance, user risk, sign-in risk, location, and application sensitivity to make per-request access decisions.

Build a Conditional Access policy set that covers:

• Require MFA for all users (baseline policy)
• Block legacy authentication protocols (NTLM, basic auth over IMAP/POP)
• Require compliant devices for access to sensitive applications
• Block sign-ins from countries where you do not operate
• Require phishing-resistant MFA (passkeys, certificate-based auth) for administrative roles

Identity Protection replaces on-premises monitoring:

Enable risk-based policies that detect and respond to compromised credentials, impossible travel, anonymous network usage, and malware-linked IP addresses.

Privileged Identity Management (PIM) replaces static admin group membership:

Configure JIT activation for all privileged cloud roles. Administrators request time-bounded role activation instead of having permanent membership.

Step 7: Execute the Cutover

The cutover is the point where the cloud directory becomes authoritative and on-premises AD is decommissioned (or reduced to minimal footprint).

Cutover prerequisites:

• All user accounts are synced and authentication works via the cloud IdP
• All business-critical applications are migrated to cloud authentication
• All devices are managed via cloud device management (or hybrid joined with Intune coverage)
• Break-glass cloud admin accounts are configured and tested
• A rollback plan exists for each migration component

Cutover execution:

1. Switch Entra Connect to cloud-authoritative mode. New users are now created in the cloud and synced down to on-premises AD (reverse of the current flow).
2. Disable ADFS relying party trusts. All federation traffic now goes directly to the cloud IdP.
3. Decommission ADFS servers after a 30-day monitoring period confirms no traffic.
4. Begin domain controller decommission. Remove DCs from non-primary sites first. Keep at least two DCs in the primary site until all on-premises dependencies are eliminated.
5. After a 90-day stabilization period with no on-premises authentication activity, decommission the remaining domain controllers and the AD domain.

Rollback plan: At each cutover step, document the rollback procedure. The most critical rollback is re-enabling ADFS if cloud authentication fails. Keep ADFS servers in a stopped-but-recoverable state for 90 days after decommission.

Configuration Best Practices

Sync only what you need. Do not sync your entire AD to the cloud. Exclude service accounts, test accounts, computer accounts, and administrative OUs that should remain on-premises.

Use staged rollout for authentication changes. Entra ID supports staged rollout, which lets you migrate specific groups of users to cloud authentication while others remain on ADFS. Use this to migrate department by department rather than all-at-once.

Enable self-service password reset (SSPR) early. Cloud SSPR with password writeback to on-premises AD reduces help-desk burden during the transition and gives users a consistent password reset experience regardless of where they authenticate.

Monitor sync health religiously. Sync failures cause users to have stale attributes in the cloud, leading to authentication and authorization issues. Set up alerts for sync errors and treat them as high-priority incidents.

License planning. Cloud IAM platforms charge per user. Entra ID P1 or P2 licenses are required for Conditional Access, PIM, and Identity Protection. Budget for these licenses before migration.

Testing and Validation

1. Pilot group testing. Migrate a small, technically savvy group first (IT staff or willing volunteers). Run them in cloud-only authentication for 2-4 weeks and collect every issue.
2. Application testing. For each migrated application, verify: authentication works, attributes are correct, authorization (group-based access) is preserved, and logout/session management behaves correctly.
3. Device management testing. Verify that Intune policies produce the same device configuration as the GPOs they replace. Check BitLocker, firewall rules, update policies, and software deployment.
4. Disaster recovery testing. Simulate cloud IdP unavailability and verify break-glass procedures work. Simulate on-premises AD unavailability and verify cloud-authenticated users are unaffected.
5. Performance testing. Measure authentication latency from all major office locations and for remote users. Cloud authentication should be equal to or faster than on-premises for most users.

Common Pitfalls

Underestimating service account dependencies. Service accounts are the hidden iceberg of AD migration. They connect applications to databases, run scheduled tasks, and authenticate machine-to-machine communication. Each one needs individual analysis and a migration plan. Budget more time for this than you think.

Ignoring UPN cleanup. Syncing users with .local UPN suffixes causes authentication failures in the cloud. This should be the first preparation step, not an afterthought.

Trying to replicate AD exactly in the cloud. Cloud IAM platforms are not AD in the sky. Trying to replicate every OU structure, GPO, and delegation model leads to an overcomplicated cloud configuration. Take the migration as an opportunity to simplify.

Skipping the hybrid phase. Some organizations try to go directly from on-premises to cloud-native. This works only if you have a very small, modern application portfolio. For most enterprises, the hybrid phase is essential for managing risk.

Neglecting end-user communication. Users will notice changes: new login prompts, MFA enrollment, different password reset flows. Communicate each change before it happens, provide clear instructions, and staff the help desk for increased volume during transition weeks.

ADFS retirement procrastination. ADFS is a security liability (it has been the target of multiple high-profile attacks including Golden SAML). Once applications are migrated to cloud federation, decommission ADFS promptly rather than leaving it running "just in case."

Security Considerations

Protect the sync server. The Entra Connect server has access to both on-premises AD and the cloud tenant. A compromised sync server can manipulate identity data in both directions. Harden it as Tier 0 infrastructure: restrict access, monitor logs, and apply patches immediately.

Disable legacy authentication. Cloud migration is the ideal time to block legacy protocols (NTLM, basic auth) that are exploited in credential attacks. Use Conditional Access to block legacy auth and monitor sign-in logs for any remaining legacy traffic.

Implement phishing-resistant MFA. Moving to the cloud means your users authenticate over the internet. Password-only authentication is not acceptable. Deploy phishing-resistant MFA (FIDO2 keys, passkeys, certificate-based auth) for all users, with priority on administrators.

Monitor for hybrid identity attacks. During the coexistence phase, attacks can exploit the sync relationship. Monitor for suspicious changes to synced attributes, unexpected sync agent registrations, and attempts to modify the sync configuration.

Conclusion

Migrating IAM from on-premises Active Directory to cloud identity is a transformative project that touches every corner of the organization. The key to success is a phased approach: establish hybrid coexistence, migrate applications in priority order, replace GPOs with cloud-native policies, and execute the cutover only when you have validated every dependency.

The organizations that execute this migration well emerge with an identity infrastructure that is more secure, more scalable, and fundamentally better suited to modern work patterns. The organizations that rush it or skip steps end up with a fragile hybrid that combines the worst of both worlds.

Take the time to do it right. Your identity infrastructure is the foundation everything else rests on.

Frequently Asked Questions

How long does a typical AD-to-cloud migration take? For a mid-size enterprise (1,000-10,000 users), plan for 12-18 months from assessment to cutover. Large enterprises (10,000+ users) with complex application portfolios typically need 18-24 months. The hybrid coexistence phase accounts for most of this time.

Can I keep some applications on-premises AD permanently? Yes. Hybrid permanent is a valid end state for organizations with manufacturing systems, legacy applications, or regulatory requirements that prevent full cloud migration. The goal is to minimize the on-premises AD footprint, not necessarily eliminate it.

What happens to on-premises file server permissions? File server permissions based on AD groups continue to work during hybrid coexistence (sync keeps groups updated). For the cutover, either migrate file shares to cloud storage (SharePoint, OneDrive) or deploy Entra ID Domain Services to provide AD-compatible authorization for on-premises file servers.

How do I handle multi-forest environments? Entra Connect supports multi-forest sync using either a single sync server with multiple connectors or multiple sync servers (one per forest) syncing to a single Entra ID tenant. Consolidate forests where possible before migration to reduce complexity.

What is the cost of cloud IAM vs. on-premises AD? On-premises AD has hidden costs: domain controller hardware, Windows Server licensing, backup infrastructure, patching labor, and ADFS maintenance. Cloud IAM has explicit per-user licensing costs (Entra ID P2 is approximately $9/user/month). For most organizations, the total cost is comparable, but operational overhead is significantly lower with cloud IAM.

Should I migrate to Entra ID even if we do not use Azure for workloads? Entra ID works as a standalone identity platform regardless of where your workloads run. It integrates with AWS, GCP, SaaS applications, and on-premises resources. However, if your organization is heavily invested in Google Workspace or another ecosystem, evaluate their identity platform as the primary instead.