ADFS to Microsoft Entra ID Migration: Complete Planning and Execution Guide

Microsoft is pushing hard to retire ADFS. The writing has been on the wall since 2023 when they started flagging ADFS deprecation in security advisories, and Windows Server 2025 makes it even clearer — ADFS is maintenance mode, no new features, and the migration tooling keeps getting better. If you’re still running ADFS in production, now is the time to plan your move.

This guide walks through the full migration from ADFS to Microsoft Entra ID (formerly Azure AD), covering assessment, claim rules translation, staged rollout, and final decommission.

Why ADFS Needs to Go

ADFS served its purpose for over a decade, but the operational cost is hard to justify in 2026:

• Infrastructure overhead: ADFS requires at minimum 2 servers (plus WAP proxies for external access), SSL certificates, and regular patching
• No modern auth features: ADFS doesn’t natively support risk-based conditional access, passwordless authentication, or continuous access evaluation
• Certificate management burden: Token signing and token decryption certificates need rotation, and getting it wrong means a 3 AM outage
• Limited MFA options: Native ADFS MFA is basic compared to Entra ID’s passwordless, FIDO2, and Authenticator app integration

The security argument alone is compelling. Entra ID conditional access policies can evaluate sign-in risk, device compliance, location, and application sensitivity — things that require third-party plugins or custom code in ADFS.

Phase 1: Assessment and Inventory

Before touching any configuration, you need a complete picture of what ADFS is doing today.

Run the AD FS Application Activity Report

In the Azure portal, navigate to Entra ID → Enterprise applications → AD FS application activity. This report analyzes your ADFS relying party trusts and tells you which apps are migration-ready and which need work.

For a more detailed inventory, run this PowerShell on your ADFS server:

# Export all relying party trusts with claim rules
Get-AdfsRelyingPartyTrust | ForEach-Object {
    [PSCustomObject]@{
        Name            = $_.Name
        Identifier      = $_.Identifier[0]
        Protocol        = if ($_.WSFedEndpoint) { "WS-Federation" } else { "SAML" }
        IssuanceRules   = $_.IssuanceTransformRules
        AuthzRules      = $_.IssuanceAuthorizationRules
        Enabled         = $_.Enabled
        LastAccessed    = $_.LastUpdateTime
    }
} | Export-Csv -Path "adfs-rp-inventory.csv" -NoTypeInformation

Categorize Your Apps

Sort relying party trusts into three buckets:

Check for Non-Obvious Dependencies

ADFS often handles things people forget about:

• Office 365 federated domains — These need to convert from federated to managed authentication
• Partner federation trusts — Any B2B federations using ADFS as the IdP
• Service accounts — Applications using ADFS OAuth (yes, ADFS 2016+ has OAuth) or token endpoints programmatically

Phase 2: Prepare Entra ID

Configure Entra Connect Sync

If you’re not already syncing identities, set up Entra Connect (or the newer Cloud Sync agent) to synchronize your on-premises Active Directory to Entra ID. This is a prerequisite — users must exist in Entra ID before they can authenticate there.

# Verify sync is healthy
Get-ADSyncScheduler
# Should show SyncCycleEnabled: True, SyncCycleInProgress: False

Set Up Staged Rollout

Staged rollout lets you migrate specific security groups to Entra ID authentication while keeping everyone else on ADFS. This is your safety net.

In the Azure portal: Entra ID → Hybrid management → Staged Rollout

Enable these features selectively:

• Password Hash Sync authentication — users authenticate against Entra ID directly
• Seamless SSO — transparent Kerberos SSO for domain-joined devices on the corporate network
• Passthrough Authentication — if you need on-premises password validation (avoid if possible)

Create a pilot group with 20-50 users across different departments. Expand gradually after validating each wave.

Phase 3: Migrate Applications

SAML Application Migration

For standard SAML apps, the process is straightforward:

1. Create an Enterprise Application in Entra ID (use the gallery if available, otherwise non-gallery SAML)
2. Configure the SAML settings:
   • Entity ID: Copy from ADFS relying party identifier
   • Reply URL (ACS): Copy from ADFS endpoints
   • Sign-on URL: If applicable
3. Configure claims mapping

Here’s where ADFS claim rules translation gets interesting.

Translating ADFS Claim Rules

Simple NameID mapping — ADFS rule:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
 => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
    Value = c.Value);

In Entra ID, this maps to setting the Name ID format to user.onpremisessamaccountname in the SAML token configuration.

Group-based role claims — ADFS rule:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
   Value =~ "S-1-5-21-.*-1234"]
 => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/role",
    Value = "AppAdmin");

In Entra ID, create App Roles on the Enterprise Application, then assign the appropriate Entra ID groups to those roles. The role claim emits automatically.

Custom attribute claims — If ADFS pulls from a SQL attribute store or LDAP lookup, you’ll need to either:

• Sync those attributes to Entra ID via Connect Sync custom rules
• Use Entra ID custom security attributes
• Implement a claims provider extension (less common)

WS-Federation Apps

WS-Fed apps work similarly to SAML in Entra ID. Create the Enterprise App, configure the WS-Federation reply URL, and map claims. The main gotcha: some legacy WS-Fed apps expect the old https://sts.yourdomain.com/adfs/ls/ endpoint format — you’ll need to update those to point to https://login.microsoftonline.com/{tenant-id}/wsfed.

Phase 4: Convert Federated Domains

This is the big switch. When you convert a domain from federated (ADFS) to managed (Entra ID), all users in that domain start authenticating against Entra ID instead of ADFS.

# Check current domain federation status
Get-MgDomain -DomainId "yourdomain.com" | Select-Object AuthenticationType

# Convert from federated to managed (Password Hash Sync)
Update-MgDomain -DomainId "yourdomain.com" -AuthenticationType "Managed"

Do this during a maintenance window. Even with staged rollout testing, the domain conversion affects all users simultaneously. Have a rollback plan — you can re-federate the domain if something goes wrong:

# Emergency rollback to ADFS
Set-MsolDomainAuthentication -DomainName "yourdomain.com" `
    -FederationBrandName "Your Org" `
    -Authentication Federated `
    -ActiveLogOnUri "https://sts.yourdomain.com/adfs/services/trust/2005/usernamemixed" `
    -PassiveLogOnUri "https://sts.yourdomain.com/adfs/ls/" `
    -IssuerUri "http://sts.yourdomain.com/adfs/services/trust"

Phase 5: Decommission ADFS

Don’t rush this. After domain conversion, keep ADFS running for 2-4 weeks to catch any missed dependencies.

Decommission Checklist

1. Verify no active ADFS traffic — Check ADFS event logs (Event ID 411 for token issuance) and confirm zero activity:

# Check for recent token issuance events
Get-WinEvent -FilterHashtable @{LogName='AD FS/Admin'; ID=411; StartTime=(Get-Date).AddDays(-7)} -ErrorAction SilentlyContinue | Measure-Object

2. Remove DNS records — Delete A/CNAME records for sts.yourdomain.com and WAP endpoints
3. Revoke SSL certificates — Revoke the token signing certificates from your CA
4. Decommission servers — Remove ADFS role from servers, then decommission the VMs
5. Clean up Entra Connect — Remove the ADFS federation configuration from Entra Connect if present
6. Update documentation — Update runbooks, incident response procedures, and architecture diagrams

Common Pitfalls

Certificate-based authentication (CBA): If you use smart cards or client certificates via ADFS, configure Entra ID CBA before migration. Entra ID supports CBA natively now, but the configuration is different from ADFS.

Token lifetime differences: ADFS default token lifetime is 60 minutes. Entra ID uses configurable token lifetime policies. Apps that relied on specific ADFS token lifetimes may behave differently.

Claims passthrough for on-premises apps: If ADFS was fronting on-premises web apps, you’ll need Azure AD Application Proxy to maintain SSO for those applications.

Conditional access gaps: Review your ADFS access control policies. Some may not have direct Entra ID conditional access equivalents — particularly policies based on network location ranges that don’t match your Entra ID named locations.

Timeline Template

The timeline compresses significantly for smaller organizations. A company with 10 relying party trusts and no complex claim rules can realistically finish in 4-6 weeks.

What’s Next

After ADFS is gone, take advantage of what Entra ID offers that ADFS never could: passwordless authentication with FIDO2 keys, risk-based conditional access, and continuous access evaluation. The migration is the hard part — once you’re on Entra ID, the security posture improvements come quickly.