Retiring ADFS: A Practical Migration Playbook

Active Directory Federation Services (ADFS) solved a real problem when single sign-on to cloud apps first arrived. But in most environments today, the ADFS farm is an aging, internet-exposed dependency that adds attack surface, operational toil, and a single point of failure for authentication. Moving its relying parties to Microsoft Entra ID and retiring it is one of the highest-value identity projects you can take on.

Here is the playbook I use.

Why retire ADFS at all?

• Attack surface. ADFS endpoints are internet-facing and a known target. Token-signing certificate theft and "Golden SAML" attacks let adversaries forge authentication for any application.
• Operational burden. Certificates expire, servers need patching, and the WAP/proxy layer is one more thing to keep highly available.
• Lost capability. Authentication that flows through ADFS often bypasses the modern protections — risk-based Conditional Access, real-time sign-in risk, leaked-credential detection — that you get when Entra ID handles authentication directly.

Step 1: Inventory every relying party

You cannot retire what you have not mapped. Enumerate every relying-party trust in ADFS and, for each, capture:

• The application and its owner.
• The protocol it uses (WS-Fed, SAML 2.0, or OAuth/OIDC).
• The claims/attributes it depends on and any custom claim rules.
• Whether a modern Entra ID equivalent or gallery app exists.

# Export relying party trusts for analysis
Get-AdfsRelyingPartyTrust |
    Select-Object Name, Identifier, Enabled, @{
        Name = "Endpoints"
        Expression = { ($_.SamlEndpoints | ForEach-Object { $_.Location }) -join "; " }
    } |
    Export-Csv ./adfs-relying-parties.csv -NoTypeInformation

Step 2: Categorize and sequence

Sort applications into waves by risk and effort:

1. Gallery apps with a pre-built Entra ID integration — fastest wins.
2. Standards-based custom apps (SAML/OIDC) — straightforward but need claim mapping.
3. Complex or legacy apps with unusual claim rules or WS-Trust — handle last, with the most testing.

Start with a low-risk, well-understood application to validate your process end to end before touching anything business-critical.

Step 3: Migrate, app by app

For each relying party:

• Create the corresponding enterprise application in Entra ID.
• Reproduce the claims mapping (Entra ID claims customization covers the vast majority of cases).
• Configure Conditional Access for the app — this is the moment you gain security you did not have under ADFS.
• Test with a pilot group, validate the full sign-in and SSO flow, then switch the app's trust from ADFS to Entra ID.

Migrate one application at a time and validate before moving on. A per-app cutover keeps the blast radius tiny and makes rollback trivial.

Step 4: Decommission deliberately

Once every relying party is moved and validated:

• Monitor ADFS sign-in logs to confirm zero remaining traffic for a sustained period.
• Disable relying-party trusts before removing servers, so you can re-enable quickly if something was missed.
• Decommission the WAP/proxy layer, then the ADFS farm, then remove the now-unused certificates and DNS records.

What you gain

When the dust settles, every application authenticates through Entra ID — which means uniform Conditional Access, MFA, sign-in risk evaluation, and a dramatically smaller internet-facing footprint. You also delete a whole class of operational chores.

This is methodical work, not a weekend project. But done in disciplined waves, it is low-risk and high-reward — and it is one of the most common engagements I run.

Sitting on an ADFS farm you would rather not own? Book a discovery call and we will map your path off it.