On-Premise IAM to Cloud Migration: Planning Framework and Execution Strategy

Moving identity infrastructure from on-premises to cloud is not a weekend project. It touches every application, every user, and every compliance control in your organization. Get it wrong and people can’t log in on Monday morning. Get it right and you eliminate a significant chunk of infrastructure cost while gaining capabilities that on-prem systems can’t match.

This framework is vendor-agnostic — whether you’re moving to Entra ID, Okta, Auth0, or Keycloak Cloud, the planning process is the same.

Why Organizations Migrate

The technical reasons are well-documented: eliminate hardware, reduce patching burden, gain modern auth features. But the real driver is usually one of these:

• End of support: Your on-prem IAM vendor is sunsetting the product (e.g., CA SiteMinder, Oracle Access Manager legacy versions)
• Acquisition: Your company got acquired and the parent uses a different IAM stack
• Cost pressure: The hardware refresh cycle for IAM servers + database licensing + WAM infrastructure is no longer justifiable
• Security mandate: Leadership wants conditional access, passwordless, or zero trust capabilities that the on-prem system doesn’t support

Whatever the driver, the migration follows the same pattern: assess, architect, coexist, migrate, decommission.

Phase 1: Identity Landscape Assessment

Inventory Everything

Most organizations underestimate how deeply IAM is embedded. Beyond the obvious applications:

• Service-to-service authentication: Machine identities, API keys, mutual TLS certificates tied to the on-prem IdP
• Batch jobs and scheduled tasks: ETL processes that use LDAP bind credentials or service account tokens
• Network infrastructure: VPN concentrators, firewalls, and switches using RADIUS or LDAP authentication
• Legacy applications: Mainframe apps, thick clients, and custom internal tools with hardcoded LDAP queries
• Partner federations: B2B SAML federations where your on-prem IdP is the anchor

Build the Dependency Map

For each application, document:

This inventory is the foundation for everything that follows. Spend the time to get it right.

Classify User Populations

Not all users migrate the same way:

• Employees with AD accounts: Sync via directory sync tools (Entra Connect, Okta AD Agent, etc.)
• Contractors in LDAP: May need a different sync strategy or manual provisioning
• External partners: Federated identities — they don’t migrate, the federation trust does
• Service accounts: Often the hardest — scattered across scripts, cron jobs, and application configs

Phase 2: Coexistence Architecture

The coexistence period is where migrations succeed or fail. You need both systems running simultaneously with identity federation between them.

Pattern A: Cloud-Primary with On-Prem Federation

Users → Cloud IdP (primary) → Applications
              ↓ (federated)
         On-Prem IdP → Legacy Apps

Users authenticate at the cloud IdP. Legacy applications that can’t be migrated yet trust the on-prem IdP, which is federated as a downstream provider. New apps register only with the cloud IdP.

Best for: Organizations with mostly cloud-ready apps and a few stubborn legacy systems.

Pattern B: On-Prem Primary with Cloud Delegated Auth

Users → On-Prem IdP (primary) → Legacy Apps
              ↓ (federated)
         Cloud IdP → Cloud/SaaS Apps

The on-prem IdP remains the authentication source. The cloud IdP trusts it via federation and handles cloud/SaaS apps. Over time, apps migrate from on-prem to cloud IdP, and eventually the on-prem IdP is decommissioned.

Best for: Large enterprises where the on-prem IdP handles hundreds of apps and can’t be displaced quickly.

Pattern C: Side-by-Side with Directory Sync

Active Directory → Sync → Cloud IdP
       ↓                      ↓
On-Prem Apps            Cloud/SaaS Apps

Both IdPs authenticate against the same directory (AD). No federation between them — each handles its own set of applications. Users have the same credentials in both.

Best for: Organizations where the on-prem IdP and cloud IdP don’t need to interact, and all apps can be cleanly partitioned.

Phase 3: Directory Synchronization

Whatever coexistence pattern you choose, user identities need to exist in both systems during migration.

Sync Strategy Comparison

Password Sync Considerations

This is the hardest part of identity migration. Options:

1. Hash sync: If moving to Entra ID from AD, Entra Connect syncs password hashes. Users don’t notice.
2. Force reset: Require all users to reset passwords after migration. Simple but disruptive.
3. Progressive rehash: Import users without passwords. On first login at the cloud IdP, authenticate against the old system, capture the password, and set it in the cloud IdP. Transparent to users but requires custom integration.
4. Federated authentication: Don’t migrate passwords at all. The cloud IdP federates back to the on-prem IdP for authentication. Passwords stay on-prem until decommission forces a reset.

Phase 4: Application Migration Waves

Wave Planning

Group applications into waves based on complexity, risk, and user impact:

Wave 0 — Pilot (Week 1-2):

• 2-3 low-risk internal apps with tech-savvy users
• Goal: validate the coexistence architecture and sync
• Rollback: point apps back to on-prem IdP

Wave 1 — Standard Apps (Week 3-6):

• SAML/OIDC apps with standard claims
• SaaS apps that support the cloud IdP out of the box
• Goal: move the bulk of easily-migrated applications

Wave 2 — Custom Integration Apps (Week 7-12):

• Apps with custom claim rules, attribute lookups, or non-standard protocols
• Apps requiring code changes for new IdP endpoints

Wave 3 — Legacy and Complex (Week 13-20):

• WS-Federation, Kerberos-constrained delegation
• Apps with hardcoded LDAP queries
• Thick clients and desktop applications
• May require application proxy or gateway solutions

Per-Application Migration Procedure

For each application:

1. Create the app registration in the cloud IdP
2. Configure protocol settings (SAML endpoint, OIDC client ID/secret, redirect URIs)
3. Map claims/attributes to match the on-prem IdP’s output
4. Test with a small user group
5. Update DNS or app configuration to point to cloud IdP
6. Monitor for authentication failures for 48 hours
7. Remove the app from the on-prem IdP

Phase 5: Decommission

Don’t rush this. The decommission phase starts 30+ days after the last application migrates.

Pre-Decommission Validation

# Check for remaining active sessions on the on-prem IdP
# (varies by product — example for ADFS)
Get-AdfsRelyingPartyTrust | Where-Object { $_.Enabled -eq $true } | Select Name

# Verify no token issuance in the last 30 days
Get-WinEvent -FilterHashtable @{LogName='AD FS/Admin'; ID=411; StartTime=(Get-Date).AddDays(-30)}

Decommission Sequence

1. Disable authentication on the on-prem IdP (don’t delete yet)
2. Wait 2 weeks for stragglers to surface
3. Remove DNS records pointing to the on-prem IdP
4. Revoke SSL certificates
5. Remove directory sync agents (if no longer needed)
6. Decommission servers
7. Archive configuration exports for compliance

Risk Mitigation

Rollback plan: For every wave, define how to roll back to the on-prem IdP within 30 minutes. Usually this means keeping the on-prem app registration active and switching DNS or app configuration back.

Break-glass accounts: Maintain emergency admin access to both systems throughout the migration. A misconfigured federation trust can lock everyone out of both systems simultaneously.

Communication: Users will see different login pages during migration. Prepare help desk with screenshots of both the old and new login flows. The #1 help desk call during IAM migration is “the login page looks different — is this a phishing attack?”

Compliance documentation: If you’re in a regulated industry, document the migration plan and get sign-off from security and compliance teams. Auditors will ask about the coexistence period and how access controls were maintained throughout.