# Migrating from AD FS to Microsoft Entra ID

Source: https://startwithidentity.com/guides/implementation/adfs-to-entra-migration/
Last updated: 2026-06-17
License: content by Start with Identity. Cite the source URL.

---

## Why migrate off AD FS

Active Directory Federation Services did its job for a decade, but running your own federation servers now means patching, certificate management, capacity planning, and a single on-prem dependency in the critical login path. Moving federation to [Microsoft Entra ID](https://startwithidentity.com/vendors/iam/microsoft-entra/) removes that operational burden and enables modern controls: Conditional Access, Identity Protection risk signals, [passwordless](https://startwithidentity.com/guides/fundamentals/what-is-passwordless/) and [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/), and a cloud-scale federation endpoint you do not operate.

## Before you start

- Inventory every AD FS relying party (the applications federated through it) and how each authenticates ([SAML](https://startwithidentity.com/standards/saml-2-0/), [WS-Fed](https://startwithidentity.com/glossary/federation/), or [OIDC](https://startwithidentity.com/standards/openid-connect/)).
- Confirm Entra Connect is syncing identities and decide your authentication method: password hash sync (simplest and resilient), pass-through authentication, or federation. For most organizations, password hash sync plus Conditional Access is the target.
- Baseline current sign-in volume and any custom claim rules, which are the part that takes real work to reproduce.

## The migration sequence

1. **Stand up the foundation.** Entra Connect healthy, Conditional Access policies authored and tested in report-only mode, MFA registration campaign underway.
2. **Use the migration tooling.** Microsoft provides an AD FS application activity report and a migration experience that flags which relying parties are ready to move. Start with the simple, standards-based apps.
3. **Migrate app by app.** Re-point each relying party from AD FS to Entra, reproduce its claim mapping, and test with a pilot group before cutover. Keep AD FS authoritative until each app is verified.
4. **Move authentication off federation.** Convert the domain from federated to managed (password hash sync) so logins no longer depend on AD FS.
5. **Decommission AD FS.** Only after every relying party is migrated and sign-in logs confirm AD FS is idle. Keep it powered but unused for a grace period, then retire.

## Claim rules and the long tail

The hard part is rarely the common apps; it is the handful with custom AD FS claim rules. Translate these to Entra claims mapping policies, and be prepared to update a few apps that hardcoded AD FS endpoints. Budget time for this tail rather than assuming a clean lift.

## Common pitfalls

- Cutting over authentication before all relying parties are migrated, breaking logins.
- Forgetting certificate and endpoint references hardcoded in older applications.
- Not running Conditional Access in report-only mode first, then surprising users at cutover.
- Decommissioning AD FS before confirming, via sign-in logs, that nothing still uses it.

## Related

Guide: [IAM cloud migration](https://startwithidentity.com/guides/implementation/iam-cloud-migration-guide/), [conditional access policies](https://startwithidentity.com/guides/implementation/conditional-access-policies-guide/). Vendor: [Microsoft Entra ID](https://startwithidentity.com/vendors/iam/microsoft-entra/). Standards: [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/), [OpenID Connect](https://startwithidentity.com/standards/openid-connect/).