Many organizations built their hybrid identity strategy around Active Directory Federation Services (AD FS) for single sign-on (SSO). Today, Microsoft Entra ID (formerly Azure AD) can deliver the same sign-in experience for most apps—often with less infrastructure, lower operational overhead, and better native controls like Conditional Access.
This guide walks you through a practical, low-risk migration from AD FS to Entra ID SSO, including assessment, pilot, cutover, and decommissioning.
What “migrating off AD FS” actually means
In most environments, “AD FS to Entra SSO” means moving from federated authentication (AD FS issuing tokens) to one of these Entra-backed models:
- Password Hash Synchronization (PHS) + Seamless SSO: Entra validates a synced password hash. Simple, resilient, lowest operational complexity.
- Pass-through Authentication (PTA) + Seamless SSO: Entra forwards auth to on-prem agents that validate against AD DS. Useful when you can’t/won’t sync password hashes.
- Federation kept only for edge cases: Some legacy requirements may keep AD FS temporarily while most apps move to Entra.
If you want a quick refresher on how Entra SSO works conceptually before you design the migration, read: Microsoft Entra Single Sign-On: Explained.
Why organizations move away from AD FS
- Lower infrastructure and patching burden (no federation farm/WAP dependency for most scenarios)
- Better cloud-native access control (Conditional Access, identity protection, session controls)
- More consistent user experience across Microsoft 365 and SaaS apps
- Improved resiliency (especially with PHS) if on-prem connectivity is disrupted
Prerequisites and readiness checklist
- Verified custom domains in Entra ID (do not cut over sign-in domains until verified)
- Azure AD Connect / Entra Connect in place (or a plan to install) to support PHS/PTA and Seamless SSO
- Inventory of relying party trusts / apps currently federated through AD FS
- MFA approach decided (Entra MFA / Conditional Access vs. AD FS MFA adapters)
- Certificate and claims mapping review for apps that depend on custom claims or signing certs
- Communications plan for users, helpdesk, and app owners
If you need to align your hybrid identity foundation first, this deep dive helps you choose and operate the right sync + auth model: Azure AD Connect: What it is, how it works; best practices.
Phase 1: Discover and classify AD FS dependencies
1) Build the application inventory
Document every application currently relying on AD FS. For each app, capture:
- Protocol: SAML, WS-Fed, OAuth/OIDC
- Sign-in URL, entity ID (SAML), reply URLs, identifiers
- Claims required (UPN/email/ImmutableID/group claims/custom)
- Who owns it (app team/vendor), user population, criticality, support contacts
- Current MFA behavior and exceptions
2) Categorize apps by migration path
- Easy: SaaS apps with Entra gallery support (SAML/OIDC supported natively)
- Moderate: Custom line-of-business apps that can be updated to OIDC/SAML with Entra
- Hard: Legacy WS-Fed or apps tightly coupled to AD FS claims rules/certs
Phase 2: Choose your target sign-in model (PHS vs PTA)
Recommendation for most orgs: PHS + Seamless SSO
- Resilient: users can authenticate even if on-prem is down
- Simpler operations: fewer moving parts than PTA
- Works well with Conditional Access and modern auth patterns
When PTA is still a fit
- Strict policy prevents password hash sync (even though hashes are not reversible)
- Requirement to validate passwords only against on-prem AD at sign-in time
Phase 3: Prepare Entra ID for production SSO
1) Establish your access control baseline
- Define Conditional Access policies (MFA, device compliance, locations, risk-based controls)
- Plan break-glass accounts (cloud-only, excluded from CA, strong protection)
- Decide how you will handle legacy authentication (block where possible)
2) Ensure your federation and app protocol posture is clean
During migration you’ll likely touch SAML and/or OpenID Connect configuration in Entra. Use these references when you’re mapping apps off AD FS:
- For SAML apps: How to configure Azure AD Federation with SAML
- For modern apps using OIDC: How to configure Azure AD Federation with OpenID Connect
Phase 4: Pilot (do not “big bang”)
1) Start with a controlled pilot group
- Select 1–3 low-risk apps and a small user cohort (IT + a friendly business team)
- Move those apps to Entra SSO while keeping the rest on AD FS
- Run a parallel validation window (sign-in tests, MFA prompts, device flows)
2) Validate the “gotchas” that usually break pilots
- Identifier mismatch: app expects UPN vs email vs immutable ID
- Group claims: token size issues or different group formats
- MFA behavior: Conditional Access prompts differ from AD FS rules
- Legacy clients: older apps may not support modern auth well
Phase 5: Migrate applications in waves
Move applications in “waves” based on the inventory you built:
- Wave 1 (easy): Entra gallery SaaS apps (SAML/OIDC), minimal claims customization
- Wave 2 (moderate): custom apps with manageable claims and tested token flows
- Wave 3 (hard): legacy apps—upgrade, re-platform, or isolate with temporary federation
For each app cutover:
- Configure the app in Entra (SAML/OIDC settings, certificates, reply URLs, claims)
- Assign pilot users and test end-to-end
- Expand assignment to the full population
- Switch the app’s trust from AD FS to Entra (vendor/admin setting) and monitor
Phase 6: Cut over the tenant from “federated” to “managed” (if applicable)
If your primary sign-in domain in Entra is currently set to federated with AD FS, the final step is switching it to managed (PHS/PTA). This is a high-impact change—do it only after you’ve proven that apps and authentication flows are ready.
Cutover principles
- Do it during a planned change window with helpdesk coverage
- Have a rollback plan (and test the rollback steps in advance)
- Communicate clearly what users may see (re-login prompts, MFA prompts, new consent screens)
Phase 7: Monitor and stabilize
- Track sign-in success/failure rates and Conditional Access impact
- Look for spikes in password resets, lockouts, and MFA challenges
- Confirm Seamless SSO behavior on domain-joined devices
- Validate critical apps again after the domain auth cutover (if performed)
If you want a health-first approach to diagnosing hybrid authentication issues during the migration, use this troubleshooting reference: Azure AD Connect Health – Troubleshooting Hybrid identity scenarios.
Phase 8: Decommission AD FS safely
Only decommission AD FS when:
- All relying party trusts have been migrated or retired
- No sign-in traffic depends on AD FS (confirm via logs over a meaningful period)
- All external dependencies are accounted for (partners, extranet, legacy endpoints)
Decommission checklist
- Freeze AD FS configuration changes
- Export and archive AD FS configuration and certificates (for audit/forensics)
- Remove DNS dependencies and load balancer configs gradually
- Decommission WAP first (if used), then federation servers
- Update documentation, runbooks, and incident procedures
Common pitfalls (and how to avoid them)
- Underestimating custom claims rules: Map every claim used by apps and replicate in Entra (or change the app to accept standard claims).
- MFA surprises: Conditional Access is policy-driven and can behave differently than AD FS MFA adapters. Pilot MFA-heavy apps early.
- Token bloat: Group claims and nested groups can create large tokens. Prefer app roles or scoped group assignment where possible.
- Legacy authentication: Some older clients will fail when you tighten controls. Identify and modernize them before wave cutovers.
- Rushing domain cutover: Migrating apps first usually reduces blast radius. Flip the domain from federated to managed only after proven readiness.
Quick “ideal” migration plan (copy/paste for your change proposal)
- Week 1–2: Inventory AD FS apps, classify by protocol and complexity
- Week 2–3: Configure Entra baseline (CA, MFA approach, break-glass, logging)
- Week 3–4: Pilot 2–3 apps + pilot user group; validate Seamless SSO
- Month 2: Migrate Wave 1 SaaS apps; stabilize
- Month 3: Migrate Wave 2 custom apps; stabilize
- Month 4+: Handle Wave 3 legacy apps; retire/upgrade as needed
- Final: Convert federated domain to managed (if needed), then decommission AD FS
FAQ
Will users notice the change?
If you plan well, most users only see a one-time sign-in prompt or updated MFA prompt behavior. The biggest “felt” changes usually come from Conditional Access rollout and legacy client remediation.
Do we still need AD FS for Microsoft 365?
In most cases, no. Entra ID can handle Microsoft 365 authentication directly using PHS or PTA. AD FS is typically retained only for specific legacy app requirements.
Can we migrate gradually?
Yes—and you usually should. Migrate applications in waves first, then perform any tenant/domain authentication cutover only after stability.
