How do you migrate AD FS applications to Microsoft Entra ID?

You migrate AD FS applications to Microsoft Entra ID by identifying each relying party, confirming its authentication method, and then moving it to a cloud sign-in model that matches the application’s capabilities. Test each app with a pilot group, validate claims and session behaviour, update dependencies that still expect federation, and decommission AD FS only after all apps are switched.

Start by classifying each relying party by how it authenticates today and what the application can actually support after federation is removed. Some apps can move to modern OAuth or OpenID Connect sign-in with minimal change, while others may need alternate sign-in patterns, app updates, or a longer coexistence period. The practical goal is to match the new trust model to the app, not force every application into the same target state.

The migration decision is easiest when you separate user sign-in, application capability, and downstream dependencies. If the app only works because it expects claims or WS-Federation behaviour from AD FS, the migration usually includes application refactoring or a parallel transition path rather than a simple tenant setting change.

When the application is already integrated through SAML, the migration often becomes a protocol and configuration exercise first, then a user-experience and session validation exercise second. For guidance on the SAML side of that transition, see the SAML Security Guide, which covers SAML to OIDC migration and the trust details that matter when federation is being retired.

What has to be tested before you cut over?

Test with a pilot group before you move broad user populations. The important checks are not just “does sign-in work,” but whether claims are issued as expected, whether the app still authorizes the right users, whether session lifetime behaves correctly, and whether any conditional access or MFA assumptions still hold after the move. A migration can appear successful while still breaking authorization, token validation, or session renewal in production.

You also need to validate any dependencies that remain federation-aware. Some applications, scripts, connectors, or middleware may still expect AD FS endpoints, old token formats, or claim rules that no longer exist once the app is moved. Treat those dependencies as part of the migration scope, not as a separate cleanup task to postpone until later.

For the identity platform side of the change, the Active Directory and Entra ID Hardening Guide is useful because it frames the migration inside broader hybrid identity hardening, and the Entra ID Applications and Consent Guide helps when the target app model depends on enterprise applications, permissions, and consent behaviour rather than legacy federation trust.

When can you retire AD FS, and what should still be checked first?

Do not decommission AD FS until every relying party has been switched and you have confirmed that no production workflow still depends on federation. The retirement step should come after you verify sign-in telemetry, application access, and user experience over a representative period. If you remove AD FS too early, the failure mode is usually not graceful, because the broken dependency only surfaces when a business process, partner integration, or rare application path is used.

It is also worth checking whether the old federation path has been used as a trust bridge for other systems. In hybrid environments, the migration can expose hidden coupling between on-premises AD, synchronization, and cloud access patterns. For teams that are still disentangling hybrid identity design, the Identity Recovery Guide is a useful companion because it reinforces how identity components, backups, and recovery assumptions should be treated as a system, not as isolated parts.

Risk and Threat Considerations

AD FS migrations carry a real exposure window because federation trusts, signing certificates, and legacy claims logic often persist longer than teams expect. The main risk is not the cutover itself, but the period where some applications trust the new cloud path while others still rely on the old federation path, creating inconsistent control points and overlooked dependencies.

Failure mechanism: Partial migration leaves old AD FS endpoints, certificates, or claim rules active long enough for misconfiguration, stale trust, or forgotten dependencies to break authentication or preserve an unwanted attack path.

Impact: Users can lose access, applications can authorize incorrectly, and in the worst case an attacker who already has some access to the legacy trust boundary can abuse it while the estate is only half-migrated.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	AD FS to Entra ID migration changes how users authenticate to applications.
	IA-5 — Authenticator Management	Cutover often requires validating credential, token, and session handling during the migration.
	AC-2 — Account Management	App migration depends on correct user assignment, access continuity, and deprovisioning.
Recommendation — Validate organizational-user sign-in against the new authentication path before retiring federation. Review authenticator lifecycle and session dependencies before decommissioning AD FS. Verify application access assignments and remove legacy federation access only after cutover.
ISO/IEC 27001:2022	A.5.15 — Access control	The migration is an access-control transition from federation to cloud sign-in.
Recommendation — Update access-control rules to reflect the new Entra ID sign-in model.

Practitioner Guidance

What to prioritise: Inventory every relying party first, then rank them by business criticality and by how much federation logic they depend on. The apps with the most custom claims, partner trust, or old protocol assumptions usually deserve the earliest pilot because they reveal the real migration effort.

What to verify: Confirm that the target Entra ID configuration reproduces the required claims, user assignment, session behaviour, and access decisions before you expand the pilot. If an app only “works” after a temporary exception, treat that as a migration blocker rather than a successful test.

Practitioner takeaway: The safe migration pattern is to prove app-by-app equivalence in authentication and authorization before you remove federation, because the hard part is usually hidden in trust dependencies rather than in the sign-in screen itself.