Windows Server

Windows Server 2016 AD FS: Migrate the Farm or Move to Microsoft Entra ID

Windows Server 2016 AD FS has no in-place upgrade. Add newer farm nodes, raise the behavior level safely, or move to Entra ID: steps and rollback points.

Published 06 November 2026

Active Directory Federation Services (AD FS) is the server that answers when Microsoft 365, a software-as-a-service app or a partner site asks "who is this person?". If your AD FS farm runs on Windows Server 2016, the question is not only how to move it but whether to keep it. This guide covers the documented farm migration, the alternative Microsoft recommends, the cmdlets, the points of no return, and the mistakes that leave users unable to sign in. Sources checked 6 November 2026 against Microsoft Learn and Microsoft Lifecycle; they are listed at the end.

Verdict

Verdict: Migrate.

Microsoft's role matrix says AD FS cannot be upgraded in place; you add newer servers to the farm and retire the old ones, and Microsoft highly recommends moving to Microsoft Entra ID instead of upgrading AD FS.

The second half of that verdict is the one to take seriously. A farm migration gets you to a supported operating system. A move to Microsoft Entra ID removes the farm. Both end the Windows Server 2016 dependency; only one removes the next one.

Who this is for and what changes on the end-of-support date

This is for anyone running AD FS federation servers or Web Application Proxy (WAP) servers on Windows Server 2016, usually to federate Microsoft 365 sign-in, to issue claims to line-of-business apps, or to provide certificate-based or smart-card sign-in.

Microsoft Lifecycle lists Windows Server 2016 under the Fixed Lifecycle Policy. The Lifecycle table shows the extended support end as 1/13/2027 6:59:59 AM, while Microsoft's extended security updates page names 12 January 2027. Plan to finish before 12 January 2027.

AD FS is a sign-in dependency: when it fails, everything that federates through it fails. WAP servers face the internet. On ESU, Microsoft's Azure Arc documentation says Windows Server 2016 reaches end of support on January 12, 2027, and that Extended Security Updates provide Critical and Important security updates for up to three years, through 2030, without new features, customer-requested nonsecurity hotfixes or design change requests. Arc-enabled ESU can be configured in the Azure portal from August 3, 2026, and its billing begins January 13, 2027. Standard and Datacenter editions are supported; physical-core licences need at least 16 cores per machine, and virtual-core licences need at least 8 per VM and use Standard. You must attest to Software Assurance or an equivalent server subscription, or license through SPLA. The pages I read show no price, so get a quote. Microsoft describes ESU generally as a last resort paid option and a temporary bridge, so treat it as a way to finish a migration, not as the plan.

Decision table

Option	What Microsoft documents	Fit for AD FS
Stay and buy ESU	Azure Arc ESU: Critical and Important updates for up to three years, through 2030, billed from 13 January 2027; needs Software Assurance or an equivalent subscription	A temporary bridge, not a plan; no price is published on those pages, so get a quote
In-place upgrade	The role matrix lists AD FS as not upgradeable in place	Not available
Side-by-side migration	Add newer federation servers to the existing farm, move the primary role, remove old nodes, raise the farm behavior level	The documented farm route; Microsoft's matrix says it is not downtime-free because new nodes must be added to the farm
Move to Microsoft Entra ID	Microsoft's decommission resources, application migration guidance and cloud authentication guides (password hash sync, pass-through authentication)	What Microsoft highly recommends instead of upgrading

Steps, with the rollback point

The first four steps apply whichever route you choose. The farm steps then follow Microsoft's article for a farm that uses Windows Internal Database (WID).

Inventory the farm. On a federation server run Get-AdfsFarmInformation for the current farm behavior level and nodes. List relying party trusts with Get-AdfsRelyingPartyTrust | Select Name, Enabled, claims provider trusts with Get-AdfsClaimsProviderTrust, and the certificates with Get-AdfsCertificate. Run Get-AdfsProperties and note the federation service name. Note whether a database is WID or SQL Server, and which WAP servers are published.
Decide: keep AD FS or move apps to Entra ID. Microsoft's AD FS decommission page lists a migration readiness script for apps, an application migration wizard, and guides for moving from federation to cloud authentication with password hash synchronization or pass-through authentication. Use the application inventory from step 1 to decide which apps can move and which cannot; the ones that cannot decide how long the farm lives.
Check prerequisites. Microsoft requires target-version servers installed, fully updated and with the AD FS role, and an Active Directory schema at least level 85 for AD FS on Windows Server 2016 or later and level 88 for AD FS on 2019 or later. If the schema is behind, that is a domain controller job first; see the domain controller guide. Back up the AD FS configuration and the federation servers. Rollback point: this backup and the unchanged old nodes.
Set the timeline. Microsoft says not to run a mixed-mode farm for an extended time because it may cause issues. Pick the weeks, not the quarter.
Add the new federation servers. Join each to the existing farm (Add-AdfsFarmNode or the wizard). A later-version node joining a lower-level farm runs in mixed mode at the lower level, so you cannot use new features yet.
Move the primary role. On one new server run Set-AdfsSyncProperties -Role PrimaryComputer. On every other node run Set-AdfsSyncProperties -Role SecondaryComputer -PrimaryComputerName "<primary-FQDN>".
Repoint traffic and validate. Update load balancer, DNS and network settings to the new servers and test sign-in end to end: Microsoft 365, each relying party, certificate-based sign-in, and password change if you use it. If you use Windows Hello for Business in a certificate trust on AD FS 2019 or later, Microsoft documents a scope fix for an "ugs" error; check for it.
Remove the old nodes. Uninstall the AD FS role from the old servers, then run Set-AdfsFarmInformation -RemoveNode "<old-server-FQDN>" to clear stale entries.
Test the behavior-level raise. On the primary run Test-AdfsFarmBehaviorLevelRaise, review the output, and only then run Invoke-AdfsFarmBehaviorLevelRaise. Microsoft's table maps levels to versions: 1 for 2012 R2, 3 for 2016, and 4 for 2019 and 2022; check Microsoft for newer versions. Raising the level creates a new AD FS configuration database. I found no documented way back after the raise, so treat it as the point of no return and keep the backup.
Upgrade Web Application Proxy. Deploy new WAP servers, import the federation certificate, then run Install-WebApplicationProxy -CertificateThumbprint "<thumbprint>" -FederationServiceName "<name>" -FederationServiceTrustCredential $trustcred. Keep only the new servers with Set-WebApplicationProxyConfiguration -ConnectedServersName "WAP1","WAP2" and, if the configuration version is not Windows Server 2016, Set-WebApplicationProxyConfiguration -UpgradeConfigurationVersion.
Retire and watch. Leave the old servers powered off but intact for a business cycle, and watch sign-in logs for apps that still point at an old node.

Mistakes that cause outages

Treating a farm move as a lift and shift. In-place upgrade is not supported; build new nodes.
Raising the behavior level too early. It creates a new database and ends mixed mode; do it after the new nodes carry the load.
Forgetting certificates. The service communication, token-signing and SSL certificates must be present and trusted on the new nodes, or relying parties reject tokens.
Skipping schema. The AD schema level is a prerequisite for the farm raise.
Hard-coded node names. Applications, load balancers and DNS entries that name an old node fail when it is removed.
Leaving mixed mode for months. Microsoft says it may cause issues.
Forgetting WAP. The proxy needs its own upgrade and its own new servers.
Decommissioning before dependencies are known. Apps that quietly rely on AD FS surface after the farm is gone; use the sign-in logs and Microsoft's readiness script first.

Checklist

Farm, trusts, certificates, WAP servers and database type documented
Decision recorded: keep AD FS or move apps to Microsoft Entra ID
Schema level and prerequisites confirmed; backups taken
New nodes added; primary role moved; traffic repointed and tested
Old nodes removed and farm information cleaned
Behaviour level raised only after validation
WAP servers upgraded
Old servers kept offline for a business cycle
Finish before 12 January 2027

Sources

Checked 6 November 2026.

Windows Server 2016 on Microsoft Lifecycle
Extended Security Updates for SQL Server and Windows Server
Prepare to deliver Extended Security Updates for Windows Server through Azure Arc (2016 dates, coverage, Software Assurance)
License provisioning guidelines for Extended Security Updates for Windows Server (editions, core minimums)
Billing service for Extended Security Updates for Windows Server through Azure Arc (billing start)
Product Lifecycle FAQ: Extended Security Updates
Upgrade and migrate roles and features (AD FS: no in-place upgrade)
Upgrade an AD FS farm by using Windows Internal Database (farm behavior levels, steps, WAP)
AD FS decommission reference (move to Microsoft Entra ID)
Upgrade domain controllers to a newer version of Windows Server

General planning information, not a design for your environment. Rehearse in a lab farm first.