AD FS on Windows Server 2016 end of support: what the deadline forces
If your AD FS farm and Web Application Proxy servers still run Windows Server 2016, the deadline is January 13, 2027, when extended support ends. The short answer: upgrade the servers if federation has to stay on Windows and the timeline is short, or use the deadline to replace AD FS if your estate can move to another identity provider. Microsoft's recommended exit from AD FS is Microsoft Entra ID, and this page covers the case where federation must stay on-premises, in-country or inside an isolated network. Confirm the exact end-of-support date for your edition against the Microsoft Lifecycle page for Windows Server 2016 before you set the project plan.
The first decision is scope. An upgrade touches every farm node, every Web Application Proxy server and the database or configuration store behind them, and each of those servers needs a tested path to a supported Windows Server release. Windows Server 2022 mainstream support has already ended and its extended support runs to October 15, 2031, while Windows Server 2025 is the current release. Ask your Microsoft account team or partner for the in-place or side-by-side upgrade steps that apply to your AD FS version, and confirm whether your farm's certificates, service accounts and proxy trust settings survive the move. Do not assume an upgrade is simpler or faster than a replacement without measuring it against your own relying party count, which you can get from an inventory of your trusts.
The second decision is whether the deadline is a reason to replace. Replacing AD FS means moving each relying party, re-creating its claim logic, and deciding how Active Directory stays the user source, which is a project measured in relying parties rather than servers. Upgrading keeps behavior unchanged but leaves you with another Windows Server lifecycle and the license and certificate work that comes with it. Start with an inventory of relying party trusts, protocols and real usage, then compare the two paths on the same list. If you choose replacement, keep Active Directory in place as the user store during the move.
What the Windows Server 2016 deadline requires from the farm
The January 13, 2027 end of extended support touches every server in the AD FS farm, not just the federation service itself. Each card below is a requirement the team must meet whichever path it chooses, whether that is an in-place upgrade or a move to a self-hosted identity provider.
Supported OS for every farm member
Each federation server and each Web Application Proxy server must run an operating system that Microsoft still supports for the period you plan to operate it. Microsoft's lifecycle page lists Windows Server 2016 extended support ending on January 13, 2027, and Windows Server 2025 mainstream support running to November 14, 2029. Check every server individually, including proxies in the DMZ that are easy to forget, and confirm with your Microsoft agreement what your licensing covers.
Active Directory dependency plan
AD FS depends on Active Directory for authentication, and upgrading the federation layer does not change that. Confirm the domain controller versions, the functional level and the health of replication before any change to the farm. If the identity provider replacement uses Active Directory as a user source, that dependency stays in place and must be documented as such.
Certificate and load balancer continuity
Token-signing and service communications certificates, the service names and the load balancer rules in front of the farm all shape how relying parties reach it. Inventory certificate expiry dates, private key locations and the URLs that clients and partners trust. A new server with a different name or certificate chain can break relying parties that were never documented, so record these before any server is replaced.
Tested rollback path
Before cutover, prove that the farm can return to its previous state. Take a backup of the AD FS configuration and the proxy settings, and test restoring them in a non-production setting. Define who decides to roll back, which relying parties are checked after the change, and how long old servers stay available. Without a tested path, a failed upgrade becomes an outage on a fixed deadline.
Confirm support contracts and patch cadence
Your own support agreements, patch schedule and maintenance windows determine how much time you actually have. Confirm with your Microsoft account team and any third-party support provider which versions they cover, and whether an extended security update option applies to your servers. Set the patch cadence for the new OS and the proxies before cutover so the work does not stall after the deadline.
Upgrade the farm or replace AD FS: which path fits which estate
This path keeps AD FS and Web Application Proxy as they are and moves the farm to a Windows Server release that is still supported. Microsoft's lifecycle pages give the current options: Windows Server 2025 became available on November 1, 2024, with mainstream support ending November 14, 2029 and extended support ending November 15, 2034. Windows Server 2022 mainstream support ended on October 14, 2026, and its extended support ends on October 15, 2031, so it is a shorter-lived target than 2025. Licensing is per core, with a minimum of 16 cores per server and 8 per processor, and both Standard and Datacenter editions need a Client Access License for every user or device that accesses the server. Federation traffic usually does not change those counts, but each new farm and proxy node adds core licenses.
- Newest release: Windows Server 2025 gives the longest runway from the supplied lifecycle dates.
- Windows Server 2022: Its extended support end date is near enough that it only makes sense as a short bridge.
- Core and CAL cost: Each farm and proxy node is licensed per core, and CALs apply to every user or device that reaches the server.
- Pay-as-you-go: Microsoft's pricing page lists Azure Arc per-core monthly billing as an alternative to perpetual licenses. Confirm the rate and eligibility with Microsoft or a reseller.
- Ongoing work: Certificates, patching, and the SQL Server or WID configuration stay with your team.
Before choosing this path, confirm with Microsoft and your reseller which licensing agreement applies to your estate and how many cores each node needs.
This path uses the deadline to move relying parties to a self-hosted identity provider. The candidates in this group are Keycloak, authentik and WSO2 Identity Server. Keycloak is Apache 2.0 licensed, supports OpenID Connect, OAuth 2.0 and SAML 2.0, and can federate with existing Active Directory through LDAP. WSO2 Identity Server is the option to evaluate when many WS-Federation relying parties must keep working. authentik suits smaller estates, and its WS-Federation provider sits in the Enterprise edition. Active Directory itself can stay in place as the user store, so the replacement does not have to include a directory migration.
- Protocol coverage: Inventory which apps use SAML, OIDC, WS-Federation or header-based sign-in before choosing a product.
- Keep Active Directory: Federation can sit on top of the existing directory through LDAP.
- Operations: The team takes on clustering, database backup, upgrades and certificate management.
- Sequencing: Move low-risk relying parties first and keep AD FS running until the last one is confirmed.
- Cost shape: Software licensing may be lower, but migration and operations labor is the main cost. Ask for these in a written scope.
Confirm the protocols each application needs before you commit to any product, because that list usually decides the choice.
A hybrid path upgrades the AD FS farm to a supported Windows Server release now, then replaces relying parties on a longer schedule. This keeps production sign-in stable while the replacement is planned. It suits estates where the inventory of relying parties is not yet complete, or where a compliance review must approve a new identity provider first. The cost is paying for two platforms during the transition, so the overlap window should be short and written into the plan.
- Immediate step: Move the farm and Web Application Proxy nodes to a supported release before the deadline.
- Parallel run: Stand up the candidate identity provider in a test environment while AD FS stays live.
- Pilot apps: Move a small set of relying parties first, then expand in waves.
- Decommission date: Set a retirement date for AD FS in advance so the overlap does not extend indefinitely.
- Double cost: Budget for both platforms until the last relying party is moved.
Check with your auditors whether the interim platform needs its own evidence and control mapping before you start the overlap.
The right path depends on the number and type of relying parties, the number of farm nodes, and whether federation must stay in-country or inside an isolated network. A small estate with a few SAML and OIDC apps often finds replacement simpler than a large one with many WS-Federation apps, which narrows the field toward WSO2 Identity Server. A large farm with few apps may find that upgrading to a newer Windows Server release is the lower-risk option for the current cycle. Neither path is correct for every estate, and the choice should follow an inventory rather than a preference for one vendor.
- Relying party count: A short list of SAML and OIDC apps points toward replacement.
- WS-Federation apps: Many of these favor WSO2 Identity Server over Keycloak.
- Farm size: A large farm with a stable app list may suit an upgrade in the short term.
- Network isolation: Air-gapped or in-country requirements limit cloud-hosted options.
- Team skills: Operating a self-hosted identity provider needs staff who can run Linux, databases and clustering.
Before deciding, ask your team to produce a list of every relying party trust with its protocol and usage over a representative period.
Whichever path you take, several points must be confirmed with Microsoft, your reseller, the product vendor, or your own environment. The lifecycle dates in this section come from Microsoft's published pages, and you should check them again before finalizing a plan. Licensing terms depend on your agreement and region, so ask for a written quote that states the core count per node, CAL counts, and any Azure Arc billing. For an open-source path, ask a provider for a fixed-scope written plan that names the protocols, the database, the upgrade approach, and the operations responsibilities.
- Lifecycle dates: Recheck the Windows Server 2016 and 2022 end dates on Microsoft's lifecycle pages.
- Licensing terms: Confirm core and CAL counts with your agreement holder.
- Protocol list: Confirm every protocol each relying party needs.
- Certificate plan: Confirm how signing and TLS certificates will be issued and renewed.
- Evidence: Confirm with your auditor what control evidence the chosen path must produce.
Ask for these answers in writing so the decision rests on your own inventory and contracts.
How each path meets the deadline and where it falls short
This table compares upgrading the AD FS farm, replacing it with self-hosted Keycloak, and replacing it with authentik or WSO2 for smaller or WS-Federation-heavy estates. Read each row against your own relying party inventory, because protocol coverage decides which path is viable. The main takeaway is that an upgrade keeps the current design, while a replacement moves the federation work to an open-source product you must operate.
| Option | How it meets the deadline | Licensing or subscription model | Trade-offs |
|---|---|---|---|
| In-place or side-by-side upgrade to a newer Windows Server | Moves the AD FS farm and Web Application Proxy servers to a Windows Server release still in support, keeping the current AD FS design and relying party trusts unchanged. | Windows Server is licensed per core with a 16-core minimum per server, plus Client Access Licenses for each user or device (Microsoft Windows Server pricing page). Confirm the current editions with your reseller. | Keeps AD FS and its claim rules, but you still depend on Microsoft's lifecycle. Confirm the target release's end of support date on the Microsoft Lifecycle page before committing. |
| Self-hosted Keycloak replacement | Re-creates relying party trusts as SAML 2.0 and OpenID Connect clients and connects to existing Active Directory through user federation, so the deadline becomes a migration project with its own timeline. | Keycloak is licensed under Apache 2.0 and is a CNCF incubating project, so there is no license fee. Costs are infrastructure, database, operations, and any Red Hat build of Keycloak subscription if you choose one. | Keycloak does not serve WS-Federation, so confirm each relying party before choosing it. Plan for a database, clustering, and operating the upgrade path yourself. |
| authentik or WSO2 Identity Server replacement | authentik covers SAML and OIDC, and its Enterprise tier adds a WS-Federation provider. WSO2 Identity Server supports WS-Federation alongside SAML, OIDC and SCIM, which suits estates with many WS-Federation relying parties. | authentik's free edition is MIT licensed with community support only. WS-Federation and Microsoft Entra ID integrations sit in authentik Enterprise under a separate license. WSO2 offers an open source build and a paid subscription. | Community support is the only option on the free authentik edition. You must confirm WS-Federation coverage for each SharePoint or legacy relying party, and confirm the SAML2-token limit on authentik Enterprise before committing. |
| Coverage of WS-Federation relying parties | Determines whether a path can serve every application before the deadline. Upgrade keeps coverage, while Keycloak leaves a gap that needs a separate answer. | Does not change license cost directly, but a missing protocol can add a second product, custom integration, or a retained AD FS farm. | Confirm WS-Federation use per relying party with your inventory, including SharePoint and any apps that exist only as WS-Federation endpoints. |
| Active Directory as the user store | All three paths can keep Active Directory as the source of identities, so users do not need to move before the deadline. | Active Directory sits within the Windows Server licensing you already hold, so licensing is not a new cost for this row. | Linux federation servers need an approach to reach Active Directory, such as LDAP federation or Kerberos. Confirm the authentication method each application uses. |
| Web Application Proxy and external access | Upgrading keeps Web Application Proxy in place. Replacement paths need a separate publishing layer, such as an authentik outpost or Pomerium. | Web Application Proxy is part of Windows Server, so it adds to the server count and core licensing. Open-source proxies add operations work rather than license fees. | Each replacement must reproduce pre-authentication and any header or Kerberos behavior the current proxy handles. Confirm this with your load balancer and certificate setup. |
| Operating effort after cutover | Upgrade keeps the current operating model with Windows patching and farm maintenance. Replacement shifts upgrades, database care, and certificates to your own team or a support partner. | Upgrade effort recurs with each Windows Server release. Keycloak and authentik effort recurs through upgrades, monitoring, and backups, and needs a named owner. | Ask any implementation partner for a written scope covering upgrades, backups, and testing before you choose a path. |
How to sequence the move before January 13, 2027
The sequence turns the January 13, 2027 end of extended support date into a set of dated decisions, so each AD FS farm is either upgraded in place or replaced with a tested target before it becomes unsupported. Each step ends with a written output that the next step depends on.
Inventory every relying party trust
Export the list of AD FS relying party trusts, claims provider trusts, claim rules, certificates and token signing settings from each farm, then record the protocol (SAML 2.0, WS-Federation, OpenID Connect or Kerberos-based access through Web Application Proxy) for every relying party. Use Microsoft's migration readiness tooling and activity reports to separate applications that are still in use from those that are not, and have the application owners confirm each one. Done when the inventory names an owner, a protocol and a usage status for every trust, and the owners have signed off on it.
Decide upgrade or replace for each farm
For each farm and its Web Application Proxy servers, compare two paths: upgrade to a newer supported Windows Server release, or replace AD FS with a self-hosted identity provider such as Keycloak, authentik or WSO2 Identity Server. The inventory results drive the choice, since protocol coverage (especially WS-Federation), the number of relying parties and the team's operating skills differ widely between estates. Ask your Microsoft licensing partner for current Windows Server pricing, and ask any replacement partner for a written scope before committing. Done when each farm has a recorded decision, a rationale and a named owner.
Stand up the target in a staging network
Build the chosen target in a staging network that mirrors production network paths, certificates and DNS names, connected to a test or copy of the Active Directory user store. For Keycloak, install the server on a supported database (PostgreSQL 14 to 18 is among the supported options) and deploy with the Keycloak Operator if you run Kubernetes. Keycloak migrates its database schema automatically at startup by default. For larger deployments, the upgrading guide suggests manual migration, and the Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades. Done when the staging instance authenticates test users against Active Directory and the change and rollback steps are written down.
Migrate relying parties in waves
Move relying parties in small groups, starting with low-risk internal applications and leaving business-critical and external-facing applications for later waves. For each wave, re-create the client in the new platform, translate claim rules into mappers or equivalent attribute mappings, test sign-in with real user accounts, and record the results. Keep the old trust enabled for the same application until the wave is accepted. Done when each wave has a signed test record and the application owner confirms successful sign-in.
Keep AD FS as fallback until cutover is proven
Leave the original AD FS farm and its Web Application Proxy servers running, with their trusts unchanged, until every wave has operated through a normal business cycle without incident. Keep the rollback procedure current, including DNS or load balancer changes that send traffic back to AD FS. Keep the upgraded or replacement target monitored with metrics and logs enabled. Done when the operations team has documented a rollback test and the owners agree that no application still depends on the fallback.
Decommission AD FS and document the result
Once no relying party uses AD FS, remove the trusts, stop the farm and proxy servers, and retire the certificates and service accounts they used. Update the asset inventory, access reviews and any compliance evidence to reflect the new identity provider. Back up configuration before removal, as Keycloak's realm export and import is a limited backup mechanism and all nodes must be stopped while it runs. Done when the decommission record, the final inventory and the updated evidence pack are complete and approved.
Questions buyers ask before deciding to upgrade or replace AD FS
What does upgrading AD FS servers cost in Windows Server licensing?
Licensing is the most visible cost, and it is set per core rather than per server. According to Microsoft's Windows Server pricing page, Windows Server 2025 is licensed per core with a minimum of 16 cores per server and 8 per processor. The same page lists a suggested price of 1,176 US dollars for Standard and 6,771 US dollars for Datacenter for 16 core licenses, and notes that prices vary by region. Both editions also need a Windows Server Client Access License for every user or device that accesses the server. Ask your Microsoft reseller or licensing partner for the price in your region, the core count of each farm and Web Application Proxy server, and whether your existing agreement already covers the upgrade. Pay-as-you-go pricing through Azure Arc is also listed on the same page at 33.58 US dollars per core per month, which changes the cost pattern from one-time to recurring.
How long does replacing AD FS take?
The duration depends mainly on how many relying party trusts you must move and how many of them use protocols that need custom work. Each application needs its client or relying party re-created in the new identity provider, its claims or attributes mapped, and its sign-in tested with real users. A small estate with a few SAML or OpenID Connect applications is far quicker than a farm with dozens of WS-Federation applications such as SharePoint. The inventory step is often the longest, because usage and certificate details are easy to miss. DeployOpen does not publish timelines, so ask for a duration in the written scope, built from the trust count you confirm during discovery.
What does the migration need from our internal team?
The work needs several roles at once: someone who owns the identity platform, Active Directory administrators, Windows and network administrators for the farm and proxy servers, and application owners who can confirm how each sign-in should behave. Security and compliance staff should review certificates, MFA policy and audit logging. Plan time for application owners to test, because they are the people who know whether a claim or group is still needed. Before the project starts, confirm who can approve changes, who signs off each cutover, and who has time for testing in the change window. These commitments usually matter more than the software itself.
Can our own team replace AD FS without a partner?
A capable team with experience in Keycloak or authentik, Active Directory and SAML or OpenID Connect can do it, particularly for a small number of applications. The harder cases are WS-Federation applications, Kerberos or header-based apps behind a proxy, and high availability design, where mistakes are costly. Consider whether your team has operated Linux, a PostgreSQL database and a clustered identity service, and whether it can keep the platform patched after go-live. Run a short pilot with one low-risk application before committing to a plan. If the pilot exposes gaps, that is a signal to bring in outside help.
When should we bring in an implementation partner?
Bring in a partner when the estate is large, the applications are hard to move, or your team cannot absorb the work alongside its existing duties. Outside help is also useful when you need a documented design, hardening and evidence for an assessment, or a test plan that your auditors can follow. DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source identity platforms inside your own infrastructure, and it prepares systems and evidence for compliance assessments without issuing audit reports. It is not a reseller of any vendor, so the recommendation follows your requirements rather than a product line.
What should we ask for in a fixed-scope quote for AD FS replacement?
Ask for a written scope that lists every relying party trust in or out of scope, the protocols each one uses, and the claim or attribute mappings to be rebuilt. The quote should name the deliverables, such as a design document, a tested pilot, cutover runbooks, a rollback plan and operator documentation. Ask how the Active Directory connection, LDAP or Kerberos federation, and any WS-Federation applications are handled, and what is excluded. Confirm the backup and upgrade approach for the new platform, who performs testing, and what acceptance criteria close the work. Also ask what recurs after go-live, such as support or upgrades, and whether those are separate retainers. DeployOpen works from a written scope and does not publish a price list, so the quote follows from those details.
Evidence to keep for the cutover
Whichever path you choose, a federation change is judged by the records behind it. The cards below cover the artifacts a security reviewer or external auditor will ask for, and they connect because each one proves a different step: what was trusted, who approved the change, what the configuration was, who still has access, and whether you can go back.
Relying party inventory
Before you upgrade or replace anything, list every AD FS relying party trust and every Web Application Proxy published application. Record the protocol (SAML 2.0, WS-Federation or OpenID Connect), the owner, the claim rules, the certificates and whether the application is still used. Microsoft's migration readiness tooling can help build this list, but an inventory that nobody owns goes stale quickly and should be signed off by the application owners.
Approved change records
Keep a change record for each step: the upgrade of a farm node, the cutover of a relying party, and any certificate renewal. Each record should name the approver, the scheduled window, the affected applications and the exact rollback step. Auditors reviewing a change process look for evidence that changes were authorized before they happened, not a summary written afterward.
Configuration exports
Export the AD FS farm configuration, trust definitions and claim rules before the first change, and store them in a controlled location. For a Keycloak target, keep the realm exports too, but note that the export process is not a full backup and restore mechanism and that all nodes must be stopped while it runs. Check that exports contain no plaintext secrets before you store them with the change records.
Access reviews after cutover
Within a defined period after each cutover, have application owners confirm which users and groups still need access and which do not. Compare the results with the directory groups that feed the new identity provider. This review shows whether claim mappings or group memberships carried over correctly, and it gives a reviewer a dated record that access was checked, not assumed.
Rollback test results
Test the rollback path in a non-production environment before the production window, and record what happened: how long the trust took to restore, which applications failed and which sessions were invalidated. Ask your vendor or integrator to confirm what a rollback does to tokens already issued and to certificates that were rotated during the change. Keep the test results with the change record that relies on them.
What changes for your team after either path
The biggest operating change is who owns each layer of the stack. Upgrading the farm keeps your team on Windows Server, where you already patch domain-joined servers, renew the SSL and token-signing certificates on the AD FS and Web Application Proxy servers, and watch the Windows lifecycle dates. Windows Server 2025 is the current release, and the lifecycle page for it lists mainstream support ending November 14, 2029 and extended support ending November 15, 2034. Confirm with your Microsoft licensing contact which edition and core count your farm needs, because that drives the upgrade's cost and the Client Access License count.
Replacing AD FS moves that work to Linux and a database. Keycloak is supported on a set of production databases, including PostgreSQL 14 to 18, and its high availability designs need a synchronously replicated database, so your team must own the database backups, failover testing and cluster sizing. Keycloak also migrates its schema automatically at startup by default, but the upgrading guide suggests manual schema migration for large deployments. Keycloak's realm export and import is not a full backup mechanism, and all nodes must be stopped while it runs, so plan a database-level backup and restore test before cutover.
Under a manual approval policy, the upgrade decision stays with your change board, not the vendor. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates, so if you run Keycloak on Kubernetes, someone on your team must review each release, test it against your realms and approve the rollout. Keycloak 26.8.1 is the current release, and minor releases are planned four times a year with breaking changes made opt-in. Confirm with your own staffing whether you have people who can own that cadence, because the upgrade calendar is the recurring cost that most often gets underestimated.
How DeployOpen approaches the AD FS exit
DeployOpen starts by agreeing in writing what the AD FS decision covers, then plans and builds whichever path the organization chooses, whether that is a supported upgrade or a self-hosted replacement. Every step is documented so the client's own team can operate the result after handover.
How we scope
- Inventory every AD FS farm, Web Application Proxy server and relying party trust, with protocol and certificate details, before any change is planned.
- Confirm the deadline and the data residency or network constraints that rule out Entra ID for this estate.
- Agree the scope, deliverables and timeline in a written fixed-scope document before work starts.
How we build
- Build the chosen target in the client's own cloud accounts, data centers or isolated network, with no dependency on DeployOpen systems.
- Re-create or upgrade relying party trusts in waves, testing each one against real sign-in paths and claim outputs.
- Test authentication, MFA, failover and the proxy path, then run security testing on the new identity layer.
How we hand over
- Document the architecture, trust inventory, configuration, runbooks and rollback steps for the client's operations team.
- Prepare control and evidence records that the client's independent auditors can review during compliance assessments.
- Walk the client's team through daily operation, patching, backup and restore, and the decommissioning of old AD FS servers.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Ask for a named list of deliverables, acceptance criteria and exclusions in every quote so the boundary of support is clear.
- Confirm with DeployOpen during scoping which licensing, Windows Server and vendor terms apply to your environment.
