AD FS to Entra ID: Retiring Federation with Staged Rollout, Without a Big-Bang Cutover
If your Microsoft 365 sign-in still bounces users to an AD FS farm, you are running four servers, two certificates and a public endpoint for something Entra ID does natively. Microsoft's staged rollout lets you move users to cloud authentication group by group, keep AD FS for the SAML apps that still need it, and roll a user back with one group change. This is the sequence we use for 20–500-seat organizations: PHS or PTA, the rollout groups and their limits, what replaces claim rules, the apps that stay federated for a while, and the decommission order.
Why federation is now a liability
Microsoft's own comparison of the three sign-in methods (April 2025) puts it plainly. Password hash synchronization needs nothing on-premises beyond Entra Connect. Pass-through authentication needs one server per authentication agent. Federation needs two or more AD FS servers plus two or more Web Application Proxy servers in the perimeter network. Microsoft describes ransomware cases where organizations with password hash sync enabled were back online in hours, while those without it took weeks.
Then there are the certificates: a missed token-signing rollover or an expired SSL certificate takes Microsoft 365 down. Monitoring the farm with Entra Connect Health requires Entra ID P1 or P2, one license for the first agent and 25 more for each additional agent (Microsoft, May 2026). Windows Server 2025 deprecates the Windows Internal Database that AD FS uses by default (Microsoft, September 2025), and if your farm runs on Windows Server 2016, support ends on 12 January 2027.
Microsoft still lists reasons to keep federation: third-party MFA, certificate and smart-card authentication, sign-in with DOMAIN\username instead of a UPN, multisite low-latency authentication. In a 20–500-seat tenant they rarely apply.
PHS or PTA: the choice that comes first
Password hash synchronization (PHS): Entra Connect synchronizes a hash of the password hash, Entra ID authenticates in the cloud, and sign-in keeps working when the domain controllers are unreachable. Entra ID Protection's leaked-credential detection depends on it (with Entra ID P2). Microsoft's guidance is to enable PHS as a backup whichever primary method you choose.
Pass-through authentication (PTA): lightweight agents validate the password against your domain controllers at each sign-in, so password policies apply in real time and no hash leaves the building. Microsoft recommends at least three agents in production, allows 40 per tenant, and supports them on Windows Server 2016 or later with outbound port 443 (September 2025). If the agents or the domain controllers are down, sign-in fails.
Our default is PHS with seamless SSO. We use PTA only where a written policy forbids storing password hashes in the cloud, and then still with PHS turned on as the disaster-recovery fallback. Either way, the desktop experience on hybrid joined Windows devices does not change.
Staged rollout, step by step
From Microsoft's staged rollout documentation, updated September 2026:
Prerequisites. A federated domain; PHS or PTA configured in Entra Connect while the domain stays federated; seamless SSO enabled; Conditional Access and tenant branding in place; synchronizeUpnForManagedUsersEnabled set to true; the Hybrid Identity Administrator role; Windows 10 version 1903 or later on hybrid joined devices.
Limits. Up to 10 groups per feature (PHS, PTA and seamless SSO each). A group has to be added to staged rollout before it holds more than 200 members. Nested groups and dynamic groups are not supported. Seamless SSO applies only to users who are in the seamless SSO group and in a PHS or PTA group.
What stays federated during rollout. Legacy authentication such as POP3 and SMTP, applications that send the domain_hint parameter, Windows Hello for Business hybrid certificate trust and smart-card users, nonpersistent VDI, and Windows older than version 1903. Fix these before wave 0.
Waves. Wave 0 is IT, five to ten people, for a week. Wave 1 is one department for two weeks. Wave 2 is everyone else, in batches. For each wave, confirm in the sign-in logs that authentication shows as managed rather than federated, that Outlook and Teams re-authenticated cleanly, and that MFA prompts arrive where Conditional Access says they should.
Rollback. Remove the user from the group. Microsoft's documentation says the user continues on managed authentication until one more interactive sign-in, after which Entra ID switches them back to federated.
Conversion. When the last wave has been stable for a week, convert the domain from federated to managed through Entra Connect or Microsoft Graph, then remove the staged rollout groups. AD FS is now out of the Microsoft 365 sign-in path.
MFA and Conditional Access replace claim rules
Issuance authorization rules, client access policies and MFA adapters do not migrate; Conditional Access replaces them, which is an upgrade. The equivalents: require MFA for all users, block legacy authentication, require a compliant or hybrid joined device for desktop apps, named locations for the office and the data center, and sign-in risk policies if you hold Entra ID P2. Build them in report-only mode during wave 0 and enforce them wave by wave. Our Conditional Access design patterns article shows the policy set we deploy.
Licensing. Conditional Access is an Entra ID P1 feature: Microsoft Entra ID P1 is $84.00 per user per year, a $7.00 per month equivalent, and is included in Microsoft 365 Business Premium and Microsoft 365 E3; Microsoft Entra ID P2 is $120.00 per year, $10.00 per month, and adds Identity Protection and Privileged Identity Management (Microsoft list prices, September 2026 price list). See Entra ID P1 vs P2.
Smart cards and phishing-resistant MFA. Entra certificate-based authentication takes over smart-card sign-in, and Windows Hello for Business, FIDO2 keys and Authenticator passkeys replace third-party MFA adapters; the rollout order is in passkeys and phishing-resistant MFA in Microsoft 365.
The apps that still federate: SAML relying parties
Microsoft 365 moves with the domain conversion. Every other relying party trust needs its own migration to an Entra enterprise application, which is where the elapsed time goes.
Microsoft's AD FS application migration wizard in the Entra admin center (June 2025) reads sign-in activity per relying party so you can see what is still used, flags migration blockers, and configures a new Entra application with the SAML URLs, claims mapping and user assignments in one step. It requires Entra ID P1 or P2 and the Entra Connect Health agents on the AD FS servers. It does not handle claim rules that use regular expressions, external attribute stores, OpenID Connect, OAuth or WS-Federation configurations, and it does not migrate the signing certificate; those are reconfigured by hand.
Each app cutover is also a change on the vendor's side: new metadata, new certificate, sometimes a support ticket. Batch them, three or four a week, with a test user per app. An application that cannot move yet keeps its relying party trust, and AD FS keeps running for it after Microsoft 365 has left; that is the order Microsoft's decommission guide expects. Our Azure Single Sign-On with a Third-Party Application service is $350 per application.
The decommission order
Microsoft's AD FS decommission guide (April 2025) sets the prerequisites: Entra Connect Health installed and run for at least a week to see who still uses the farm, user authentication moved to PHS, PTA or certificate-based authentication, and every application migrated. Then it checks the AD FS event logs and Connect Health for any remaining sign-ins; if there are any, you go back to migrating.
The steps, in the order the guide gives them: test cloud authentication for a week; take a final backup; remove the AD FS entries from the internal and external load balancers; delete the DNS records; run Get-ADFSProperties and note the CertificateSharingContainer distinguished name; delete the SQL Server database if used; uninstall the Web Application Proxy servers; uninstall the AD FS servers, secondary nodes first; delete the SSL certificates; reimage the servers; delete the AD FS service account; remove the CertificateSharingContainer contents with ADSI Edit.
Our own addition: power the proxies off for two weeks before uninstalling, so anything that still points at them fails while the farm can still be turned back on. The Active Directory Security Assessment and Hardening that follows usually finds the service accounts and delegations the farm left behind. Retiring the domain itself is covered in retiring on-premises Active Directory.
Frequently asked questions
Is AD FS deprecated?
Not as a product; it ships in Windows Server 2025. Microsoft recommends migrating and has deprecated the Windows Internal Database that AD FS uses by default.
Can I keep AD FS for some apps and move Microsoft 365 to cloud authentication?
Yes. Staged rollout moves users to cloud authentication while the domain stays federated, and after the domain is converted to managed, AD FS can keep serving relying party trusts for other applications until they move.
What happens to passwords with password hash sync?
Entra Connect synchronizes a hashed form of the password hash, not the password. Users keep the same password and change it in the same place, and sign-in keeps working when the domain controllers are unreachable.
How long does an AD FS to Entra ID migration take?
Four weeks for user authentication in three waves, plus a week for every three or four SAML applications, because each cutover waits on a vendor.
Do I need Entra ID P1 to migrate from AD FS?
Conditional Access, Entra Connect Health and the application migration wizard all require P1, and Microsoft 365 Business Premium and E3 include it. Tenants on Business Standard or Office 365 E3 add P1 per user.
Sources
- Microsoft Learn source files on GitHub (MicrosoftDocs/entra-docs), opened: "Microsoft Entra Connect: Cloud authentication via Staged Rollout", ms.date 09/15/2026; "Authentication for Microsoft Entra hybrid identity solutions", ms.date 04/09/2025; "Microsoft Entra pass-through authentication: Quickstart", ms.date 09/09/2025; "AD FS application migration to move AD FS apps to Microsoft Entra ID", ms.date 06/20/2025; "Microsoft Entra Connect Health FAQ", ms.date 05/15/2026
- Microsoft Learn source files on GitHub (MicrosoftDocs/windowsserverdocs), opened: "AD FS decommission guide", ms.date 04/08/2025; "AD FS to Microsoft Entra FAQ", ms.date 02/13/2024; "Features removed or no longer developed in Windows Server" (Windows Internal Database entry), ms.date 09/24/2025
- IT Partner blog: content/blog/new/microsoft-entra-id-conditional-access-design-patterns.json; passkeys-phishing-resistant-mfa-microsoft-365-rollout-order.json; entra-id-p1-vs-p2-conditional-access-pim-identity-protection-compliance.json; windows-server-2016-end-of-support-january-2027.json
- IT Partner pages: content/services/ITPWW820MIGOT, ITPWW380SECOT and ITPWW490IMPOT; Microsoft Entra ID P1 (CFQ7TTC0LFLS) and P2 (CFQ7TTC0LFK5)
- IT Partner engineering notes from AD FS retirements, September 2026
| Question | Password hash sync | Pass-through authentication | Keep AD FS |
|---|---|---|---|
| On-premises footprint | Entra Connect only | Entra Connect plus three or more agent servers | Two or more AD FS and two or more proxy servers |
| Sign-in when the office or VPN is down | Works | Fails | Fails |
| Leaked-credential detection (Entra ID P2) | Yes | Only with PHS also enabled | Only with PHS also enabled |
| Password policy and lockout | At password change | At every sign-in | At every sign-in |
| Smart cards and third-party MFA | Entra certificate-based authentication and Entra MFA | Same | Native |
| Certificates to babysit | None | None | Token-signing and SSL |
| Our recommendation | Default for 20–500 seats | Only where policy forbids cloud hashes | Only for apps that cannot move yet |
Key takeaways
- Federation needs four servers, fails when the site is down and carries certificate deadlines; Microsoft's guidance is cloud authentication with password hash sync enabled as a fallback in every case.
- Staged rollout moves users group by group, up to 10 groups per feature with no nested or dynamic groups, and rollback is removing the user from the group.
- Legacy authentication, domain_hint apps and Windows Hello for Business certificate trust stay federated during rollout; fix them before wave 0.
- Claim rules do not migrate. Conditional Access (Entra ID P1, included in Business Premium and E3) replaces them, and Entra certificate-based authentication takes over smart cards.
- Microsoft 365 moves with the domain conversion; every SAML relying party is its own cutover, and AD FS can keep serving the stragglers until the logs are quiet.
If you want the whole sequence run as one project, AD FS to Microsoft Entra ID Migration and Decommissioning is $4,950 per project over 4 weeks, fixed price, paid after approval. Pair it with the Active Directory Security Assessment and Hardening ($3,950 per project, 2 weeks) to clean up what the farm leaves behind, and use Azure Single Sign-On with a Third-Party Application ($350, 2 days) for each app that needs its own SAML cutover. Book a call with your relying party count and we will map the waves.
Questions this article didn’t answer?
Thirty minutes with Mike — our CEO, not a sales rep. Bring the hard version of the question.