AD FS to Microsoft Entra ID Migration and Decommissioning
IT Partner retires your AD FS farm and moves everything it does into Microsoft Entra ID in four weeks for a fixed $4,950: an inventory of every relying-party trust using the Entra AD FS application migration wizard and the AD FS audit logs, Microsoft 365 converted from federated to managed authentication — password hash synchronization or pass-through authentication, with seamless SSO — through Microsoft's staged rollout so pilot groups move first and the domain converts last, SAML applications migrated to Entra enterprise applications with their claims rebuilt as Entra claims and the AD FS access-control and MFA rules re-expressed as Conditional Access policies, and, after a week of clean sign-in telemetry, the AD FS and Web Application Proxy servers decommissioned in the order Microsoft's decommission guide sets out. The fixed fee covers Microsoft 365 federation plus up to 10 relying-party applications; larger estates are quoted per estate. Why now: many AD FS and WAP farms still run on Windows Server 2016, which leaves extended support on 12 January 2027 per Microsoft's product lifecycle — retiring the farm removes those servers instead of upgrading them or paying for Extended Security Updates on a service you no longer need. Three boundaries up front: applications that need a new identity integration built are quoted separately; Conditional Access design beyond what replaces your AD FS rules is its own engagement; and your on-premises Active Directory stays — this retires federation, not the directory.
What this engagement is
AD FS — often written ADFS — was how federated sign-in to Microsoft 365 worked when the directory behind it was still called Azure AD, before cloud authentication matured, and in most estates it has simply never been switched off. What it costs to keep is easy to list: two or more AD FS servers, two Web Application Proxy servers in a DMZ, a load balancer, a public DNS name and certificate, token-signing and decryption certificates that roll on their own schedule, a Windows Internal Database or SQL Server behind it, and a second sign-in stack that every outage, every certificate expiry and every Conditional Access design has to route around. Nobody is forcing it off: AD FS still ships in Windows Server 2025 and remains a supported role. But Microsoft's own AD FS-to-Entra guidance gives the reason to retire it plainly — reducing the operational cost of managing and maintaining an AD FS environment — and Microsoft's investment in sign-in, MFA, risk-based access and application single sign-on is in Entra ID, not in the federation server. The date that turns a good idea into a plan is 12 January 2027, when Windows Server 2016 leaves extended support per Microsoft's product lifecycle. Many AD FS and WAP farms were built on 2016, which leaves three choices: upgrade the operating system under a service you no longer need, pay Microsoft's per-core Extended Security Updates to keep it patched, or retire it. This service is the third choice, delivered end to end. Microsoft 365 moves first, and it moves the way Microsoft documents: cloud authentication through staged rollout. We choose the sign-in method with you — password hash synchronization, which keeps working when your domain controllers or the network to them do not, or pass-through authentication where policy forbids hashes leaving the forest, with two or three PTA agents placed close to domain controllers for resilience — and seamless SSO on top so domain-joined Windows devices sign in without a prompt. Staged rollout then lets us move users in security groups while the domain stays federated: up to ten groups per feature, no nested or dynamic groups, a pilot of up to 200 users first and larger groups afterwards, with membership changes taking up to a day to apply. Users keep the passwords they already have. When the pilot and the waves are clean, the domain converts from federated to managed — through Microsoft Entra Connect if it originally configured the federation, or with Update-MgDomain if it did not — in a change window we plan for the up-to-60-minute propagation Microsoft describes. MFA changes hands in the same step: the tenant's federatedIdpMfaBehavior setting is documented and set so Entra MFA performs the challenge, and any AD FS MFA adapter — the Azure MFA adapter, Duo, RSA — retires with the farm, which is why we check every in-scope user's Entra MFA registration before the wave that moves them. Two things staged rollout does not cover get inventoried before cutover rather than discovered after it: legacy authentication such as POP3 and SMTP keeps falling back to federation until the domain converts, and hybrid-joined Windows devices need Windows 10 version 1903 or later to obtain their primary refresh token through cloud authentication. The applications are the real work, and the Entra admin center now does a meaningful share of it. The AD FS application migration wizard — generally available since August 2024 — reads your relying-party configuration and audit logs through Microsoft Entra Connect and the Connect Health agents for AD FS, lists every SAML relying party with a sign-in in the last 30 days, and grades each one: ready to migrate, needs review, or additional steps required. For the ready ones, a migration creates the app registration and service principal, configures the SAML settings, assigns users and groups, and carries the claims across; what stays manual is the service-provider side — the application's identity-provider metadata and signing certificate have to be updated by its owner, so every application cutover is scheduled with that owner and tested before the AD FS trust is removed. The wizard is SAML-only; WS-Federation and OpenID Connect relying parties are migrated by hand, which Entra supports and the wizard simply does not automate. Claims rules are re-expressed in Entra's claims configuration — attribute mappings, transformations, group claims and the conditional functions Entra provides — and the parts of AD FS that were never claims at all, the issuance authorization and MFA rules, are rebuilt as Conditional Access policies scoped to the application, because Microsoft does not auto-configure those. Every relying party gets one of four dispositions in writing: migrated with the wizard, migrated by hand, rebuilt or re-integrated under a separate quote, or retired because nobody has signed in to it in a month. Products that consume AD FS tokens in their own way — on-premises SharePoint, Dynamics or Citrix deployments, for example — follow Microsoft's documented Entra path for that product where one exists and are quoted where one does not. Decommissioning is a sequence, not a shutdown. After the last cutover the farm stays up, idle and monitored, for at least the week Microsoft's decommission guide asks for, with Connect Health and the AD FS event logs as the evidence that nothing is still authenticating against it. Then, in order: the Microsoft 365 relying-party trust is removed, each WAP server has its published applications removed before the Web Application Proxy role is uninstalled, the AD FS entries come off internal and external load balancers and out of DNS, the secondary AD FS nodes are uninstalled before the primary, the configuration database is deleted whether it lived in WID or SQL Server, the SSL certificates and the AD FS service account are removed, the certificate-sharing container is cleaned out of Active Directory, Microsoft Entra Connect is updated so it no longer references the farm, and the virtual machines are retired. What remains is what should: your Active Directory, synchronized to Entra ID as before. If you also want to leave on-premises Active Directory behind, that is the On-premises Active Directory to Microsoft Entra ID Transition, and this engagement is its natural first step.
Which one applies to you
Every relying-party trust in the farm gets one of four dispositions before anything moves. This service delivers three of them end to end and prices the fourth honestly instead of forcing it.
| Migrated with the wizard (this service) | Migrated by hand (this service) | Rebuilt or re-integrated (quoted) | Retired (this service) | |
|---|---|---|---|---|
| What it covers | SAML relying parties the Entra AD FS application migration wizard grades ready to migrate or needs review, plus the Microsoft 365 federation itself. | WS-Federation and OpenID Connect relying parties, SAML apps the wizard marks additional steps required, and custom claims logic that needs an engineer rather than a template. | Applications that only accept AD FS-issued tokens or need a new identity integration built — code changes, a product with no documented Entra path, or Kerberos-only apps behind WAP. | Relying parties with no sign-in in the last 30 days and no owner who claims them. |
| How | Wizard migration creates the app registration, service principal, SAML settings, assignments and claims; the app owner updates the service-provider side; Conditional Access replaces AD FS access rules. | Enterprise application created and configured manually; claims rebuilt in Entra's claims configuration; access and MFA rules rebuilt as Conditional Access; tested with the app owner before the AD FS trust is removed. | Named in the disposition report with the reason and the options — re-platform, Entra application proxy, or a minimal AD FS farm on a supported OS — and quoted separately so you can decide. | Owner confirmation sought, trust documented, then removed from AD FS as part of the decommission evidence. |
| Counts toward the 10-application fee cap | Yes. | Yes. | No — quoted on its own. | No. |
| Our role | We deliver this end to end — this page. | We deliver this end to end — this page. | We name it, explain it and scope it; the build is a separate decision. | We deliver this end to end — this page. |
The disposition is made from the wizard's readiness grade, the AD FS audit logs and a conversation with each application owner — not from a preference for the column that fits the fixed fee.
Success criteria
What you receive
How the work unfolds
Confirm scope, stakeholders, the federated domains and the licence position; deploy or verify Microsoft Entra Connect Health for AD FS on day one so the wizard and the observation evidence have data to work from; export every relying-party trust and the current federation settings as the rollback baseline.
Run the AD FS application migration wizard and the AD FS audit logs against each relying party, interview application owners, inventory MFA adapters, legacy authentication, device versions and Windows Hello for Business mode, and deliver the disposition register and sign-in method design for your approval.
Configure password hash synchronization or pass-through authentication and seamless SSO in Microsoft Entra Connect, set the MFA behaviour, verify MFA registration for the pilot group, enable staged rollout for the pilot, and validate sign-in across Windows, macOS, mobile, Outlook and Teams before any production wave.
Migrate in-scope applications with the wizard or by hand in owner-scheduled windows: Entra application configured, claims mapped, Conditional Access replacing the AD FS rules in report-only, service-provider side updated by the owner, test passed, AD FS trust retired. Production user waves move to cloud authentication through staged rollout in parallel.
Convert each federated domain to managed in a planned change window, validate sign-in and MFA, enforce the Conditional Access policies, remove the Microsoft 365 relying-party trust once Connect Health shows no new requests, and start the minimum one-week observation with the farm idle.
On the observation evidence and your written authorization, decommission WAP and AD FS in Microsoft's documented order, clean up load balancers, DNS, certificates, service account and Active Directory containers, update Microsoft Entra Connect, hand the server retirement checklist to your infrastructure team, and deliver the closeout report and handoff notes.
Prerequisites
Who does what
IT Partner
- Lead discovery, run the AD FS application migration wizard and the audit-log analysis, and produce the disposition register and sign-in method design.
- Configure Microsoft Entra Connect for cloud authentication and seamless SSO, set the MFA behaviour, and run staged rollout from pilot to production waves.
- Migrate in-scope applications with the wizard or by hand, rebuild claims and access rules in Entra, and coordinate each cutover with its application owner.
- Deploy the Conditional Access policies that replace the AD FS rules for in-scope applications, report-only first, and document the rule-by-rule mapping.
- Convert the federated domains to managed in the agreed windows, validate, and hold the rollback baseline until the observation week is complete.
- Execute the decommission in Microsoft's documented order on your written authorization, and deliver the evidence, the server retirement checklist and the closeout report.
- Say plainly which applications cannot move within the fixed scope, why, and what the options and cost are.
Your team
- Provide the access, licensing confirmation and server connectivity listed in the prerequisites in a timely manner.
- Name an owner per application and make them available for test windows and the service-provider-side changes.
- Approve the disposition register, the sign-in method, each wave, the domain conversion window and the decommission authorization.
- Send the user communications we draft, and staff the helpdesk on cutover days.
- Own the licence purchases, any third-party MFA vendor contract changes, and the retirement of the AD FS and WAP virtual machines and their backups per the checklist.
- Own application code changes or product upgrades flagged in the disposition register, or commission them as a separately quoted engagement.
What's not included
Limitations & technical notes
Frequently asked questions
Does Windows Server 2016 end of support actually force us off AD FS?
No — it forces a decision about the servers, not the role. Windows Server 2016 leaves extended support on 12 January 2027 per Microsoft's product lifecycle, and if your AD FS and WAP servers run on it you either upgrade them, buy Microsoft's per-core Extended Security Updates for them, or retire them. AD FS itself still ships in Windows Server 2025 and is supported. Retirement is the choice this service exists for, because in most farms the only remaining job is one Entra ID already does; it is delivered end to end, with the date on the plan.
Is Microsoft discontinuing AD FS?
Microsoft has not announced an end-of-support date for the AD FS role, and it is present in Windows Server 2025. What Microsoft has done is put its sign-in, MFA, risk-based access and application single sign-on investment in Entra ID, ship an AD FS application migration wizard in the Entra admin center, and publish a decommission guide. Its AD FS-to-Entra guidance names the benefit as reducing the operational cost of running an AD FS environment. Retiring AD FS is a recommended direction, not a forced one, and we say so on this page rather than inventing a deadline.
Password hash synchronization or pass-through authentication — which should we choose?
Password hash synchronization unless a written policy forbids it: it keeps Microsoft 365 sign-in working when your domain controllers or the network to them are down, it needs no extra servers, and it feeds Entra's leaked-credential detection. Pass-through authentication keeps password validation on your domain controllers — the right answer where hashes may not leave the forest — at the cost of two or three agent servers with line of sight to those controllers, and Microsoft supports up to twelve. Seamless SSO layers on either. We recommend in the sign-in method design, with the reasoning, and you decide.
Will users have to change passwords or re-register MFA?
Passwords, no: both sign-in methods validate the Active Directory password users already have. MFA depends on where it lives today. If AD FS invoked Entra MFA through the Azure MFA adapter, users are already registered and nothing changes for them. If MFA lived in a third-party adapter such as Duo or RSA, users must register Entra methods before their wave, because those adapters retire with the farm — we verify registration group by group and provide the communications, and a campaign for users who have never registered is scoped separately.
What do users see on cutover day?
A different sign-in page and the same credentials. Instead of being redirected to your AD FS page, users sign in on Microsoft's page with your company branding, which we align to what they saw before. Domain-joined Windows devices with seamless SSO sign in without a prompt; hybrid-joined devices on Windows 10 1903 or later and Windows 11 obtain their token through cloud authentication. Microsoft describes up to 60 minutes of propagation after a domain converts, and the change window is planned around it; the service does not promise zero user-visible change, because the page they land on does change.
What does the $4,950 cover, and what counts as an application?
Microsoft 365 federation for the domains in scope plus up to 10 relying-party applications dispositioned as migrated with the wizard, migrated by hand, or retired. A relying party the wizard grades additional steps required still counts if we can migrate it by hand; one that needs a new identity integration built does not count — it is quoted on its own so you can decide. Dormant trusts we retire do not count either. More than 10 applications, multiple farms or forests, or partner claims-provider trusts are quoted per estate after discovery.
What can the AD FS application migration wizard do, and what can it not?
It reads your relying-party configuration and audit logs through Microsoft Entra Connect and the Connect Health agents, lists SAML relying parties with a sign-in in the last 30 days, grades each as ready to migrate, needs review or additional steps required, and on migration creates the app registration and service principal, configures SAML, assigns users and groups and carries claims across. It is SAML-only — WS-Federation, OpenID Connect and OAuth relying parties are migrated by hand — it does not update the application's own identity-provider settings, and it does not create Conditional Access policies. It needs Entra ID P1 or P2.
What happens to our AD FS claims rules?
Issuance transform rules become Entra claims configuration: attribute mappings, group claims, transformations and Entra's conditional functions cover most of what AD FS did, and the wizard carries supported ones across. Issuance authorization rules and MFA rules were never really claims — they were access control — and they are rebuilt as Conditional Access policies scoped to the application, which Microsoft does not auto-configure. Rules with no one-to-one equivalent, such as custom logic on client IP or device claims, map to named locations and device filters where possible and are redesigned with you where not, in writing.
We use AD FS for multifactor authentication. What replaces it?
Entra MFA, driven by Conditional Access. As part of the domain conversion the tenant's federatedIdpMfaBehavior setting is set so Entra performs the challenge rather than trusting a claim from the federation server, and the AD FS MFA adapter is retired with the farm. Where the adapter was a third-party product, its vendor contract is yours to end, and users need Entra methods registered before their wave; we check that per wave rather than discovering it on cutover day.
What about Windows Hello for Business and smart cards?
They are the dependency most likely to hold a farm alive. Windows Hello for Business hybrid certificate trust requires AD FS and is not supported in staged rollout, and Microsoft provides no in-place migration to cloud Kerberos trust — the Hello container is deleted and re-provisioned. Smart-card users need Microsoft Entra certificate-based authentication. Discovery identifies both populations on day one; their move is scoped separately and must finish before the farm is decommissioned, and the wave plan sequences around it honestly rather than retiring AD FS out from under them.
What licensing do we need?
Microsoft Entra ID P1 or P2 for the users in scope, which Microsoft 365 Business Premium, E3 and E5 include. It is required by the AD FS application migration wizard, by Microsoft Entra Connect Health, and by Conditional Access. Without it we can still inventory relying parties from the AD FS logs and PowerShell and convert Microsoft 365 to cloud authentication, but the Conditional Access equivalents of your AD FS access rules cannot be built, and we say so in the discovery report rather than pretending parity.
Can we roll back?
Yes, until the farm is gone. Before anything changes we export the federation settings for every domain with Get-MgDomainFederationConfiguration; a domain can be returned to federated authentication with New-MgDomainFederationConfiguration while AD FS is still running, and staged rollout can be disabled per group. That is why the farm stays up, idle and monitored through the observation week and is decommissioned only on your written authorization. After decommission there is no rollback — rebuilding AD FS would be a new project.
What exactly gets decommissioned, and when?
After at least a week of Connect Health and event-log evidence that nothing authenticates against the farm, and in Microsoft's documented order: the Microsoft 365 relying-party trust and any remaining trusts are removed; each WAP server's published applications are removed and the role is uninstalled; AD FS entries come off load balancers and out of DNS; secondary AD FS nodes are uninstalled before the primary; the configuration database is deleted whether WID or SQL; SSL certificates and the service account are removed; the certificate-sharing container is cleaned out of Active Directory; and Microsoft Entra Connect is updated. Your team retires the virtual machines from our checklist.
Web Application Proxy also publishes some internal web apps. Can it go?
Only after those applications have another front door. WAP has two jobs — proxying AD FS to the internet, which this service makes redundant, and publishing on-premises web applications, which it does not replace. Applications WAP publishes are inventoried in discovery, and their move to Microsoft Entra application proxy or Microsoft Entra Private Access is scoped as its own project so the WAP servers can be retired; until then they stay for that job alone, on a supported operating system.
Does this retire our on-premises Active Directory too?
No. This engagement removes federation and leaves Active Directory synchronized to Entra ID through Microsoft Entra Connect — users, groups and passwords keep flowing as before, only the sign-in no longer routes through AD FS. Going cloud-only is a different project with its own blockers, chiefly applications that still need Kerberos or NTLM; our On-premises Active Directory to Microsoft Entra ID Transition covers it, and retiring AD FS first is its natural precondition.
What if an application cannot move before January 2027?
Then the farm is not retired on that date, and the plan says so instead of pretending. The disposition register names the application, the reason and the options: re-platform or upgrade the product so it can use Entra, front it with Entra application proxy, or keep a minimal AD FS farm alive for that one relying party on a supported operating system — or, as a last resort, on Extended Security Updates that Microsoft bills to you. Our Windows Server 2016 End of Support Assessment prices those server-side options; this service prices the identity side.