PingFederate end of life: what an aging version means for your federation
If your PingFederate version is approaching or past its end of support, the decision is whether to upgrade within the support window or move to Keycloak, and it turns on how many connections, protocols and maintenance commitments your team carries. A small set of SAML and OIDC relying parties on a well-understood configuration often moves more easily to an open-source hub. A large estate with WS-Federation dependencies, custom adapters and strict change windows may be better served by staying on a supported Ping release while the migration is planned. Treat Ping's Long-Term Support and Short-Term Support windows, and the terms of Extended Limited Support, as contract and policy details to confirm directly with Ping, since the dates and fees that apply to your version are not something to assume from a general policy. The open-source path to evaluate is Keycloak, which is licensed under the Apache License 2.0 and is a Cloud Native Computing Foundation incubating project.
Start by inventorying what depends on the aging version. List every relying party, the protocol it uses, the certificates and signing keys bound to it, and any scheduled renewals or audit evidence that reference the current release. Ask Ping, in writing, which maintenance window your exact version falls into, what security fixes continue to ship in that window, and what Extended Limited Support would cost and cover if you needed more time. Those answers set the deadline. The cost of upgrading is mostly the internal testing and change effort across every connection, and that effort is the same whether you stay or leave, so it belongs in both columns of the comparison.
Keycloak is a realistic option only if your federation is mostly SAML 2.0 and OIDC, since it does not cover WS-Federation out of the box. Confirm that dependency first. If it exists, a move to WSO2 Identity Server or a split approach may be needed. Keep the aging PingFederate instance running in parallel during cutover, and plan for the cost of operating Keycloak yourself or through an implementation partner such as DeployOpen, scoped in writing before work starts.
What the lifecycle decision requires from your team
Whichever way you go, upgrading PingFederate or moving to Keycloak, the decision depends on the same few inputs. The cards below cover what your team must have in hand before choosing, and each one links to a check that changes the cost or the risk.
An inventory of SAML and OIDC connections
Every SAML and OIDC connection that PingFederate serves is a dependency that either moves with you or gets retired. List each relying party, its protocol, its attribute contract, its signing certificates and its owner. Relying parties that use WS-Federation or WS-Trust need separate handling, because Keycloak does not cover those protocols by itself. Without this list, you cannot size an upgrade or a migration, and the inventory is the first deliverable on either path.
A support window that matches your change calendar
Ping publishes Long-Term Support and Short-Term Support versions with different maintenance windows, and Extended Limited Support is sold separately. Map your PingFederate version to its window and compare the end date with your freeze periods, audit cycles and renewal dates. If the window closes before your change calendar allows a cutover, the cost of extended support becomes part of the decision. Ask Ping for the written end date of your exact version rather than relying on the version family.
A tested rollback path
A cutover needs a rollback that you have rehearsed, not one you have described. For Keycloak, the realm export and import commands are useful for moving configuration, but the Keycloak documentation warns that this process has limitations as a backup and restore mechanism, and that all nodes must be stopped while it runs. Plan a database-level backup, test restoring it into a non-production environment, and record how long a reversal to PingFederate would take for each application group.
A supported database and clustering design
Keycloak supports PostgreSQL 14 to 18 among its production databases, and its high availability guidance covers a single cluster, a multi-cluster design without external Infinispan, and a deprecated multi-cluster design. Both supported high availability designs need a synchronously replicated database. Confirm your database version, replication mode and failover behavior with your DBA before sizing nodes, since the clustering choice shapes the infrastructure cost and the failure modes you must test.
A schedule for Keycloak minor releases
Since Keycloak 26.0, the project plans four minor releases a year and says breaking changes in a minor release will be opt-in. That cadence is a recurring task, not a one-time project. Decide whether you will apply minor releases in a fixed window, how you will test them against your realms, and whether schema migration runs automatically at startup or manually through SQL. Large deployments often choose manual migration, so plan that step into the change process.
A named owner for upgrades
Whoever owns the platform must own upgrades, security patches and the vendor or support relationship. With PingFederate, that role is often split between the identity team and the vendor. With Keycloak, the owner also sets the operator update policy, and the Keycloak Operator documentation strongly recommends manual approval mode to avoid unintended automatic upgrades. Name one owner, document who approves each change, and confirm who answers when a release breaks a relying party.
Upgrade PingFederate or move to Keycloak: how each path fits
Staying on PingFederate keeps existing connections, adapters and attribute contracts in place while the server moves to a version inside a supported maintenance window. This path meets the goal of continuity: relying parties see little change, and the operations team keeps the tooling it already runs. What it leaves open is the cost of each upgrade cycle and the dependency on Ping's roadmap.
- Version gap: Measure how far the current version sits from the newest release in the Long-Term Support or Short-Term Support track, and confirm with Ping which window applies to your build.
- Upgrade effort: Test every SAML and OIDC connection, OAuth client and custom adapter on a staging node, because adapter code often needs rework across major versions.
- Recurring cadence: Short-Term Support versions require upgrades more often, so the upgrade budget recurs. Ask Ping for the maintenance dates in writing before you plan.
- Licensing: Confirm whether the subscription covers the target version and any new features you need, since licensing terms and their scope come from Ping's contract.
- Dependencies: Map any WS-Federation or WS-Trust relying parties, since those depend on PingFederate features that a move to Keycloak does not replace.
Before committing, ask Ping for the exact end-of-support date for your current version and the upgrade path it recommends.
Extended Limited Support is the option for teams whose PingFederate version has passed its maintenance window and who need more time before upgrading or migrating. It buys time under a narrower service level, but it does not return the version to full maintenance. This path meets a deadline problem; it does not solve the underlying version debt.
- Time-boxed relief: Treat the extension as a bridge with a stated end date, and write that date into the migration plan.
- Separate fee: Extended Limited Support is sold separately from the base subscription, so the fee is an added recurring cost. Ask Ping for the price, term and scope in a written quote.
- Reduced scope: Confirm which fixes, security patches and support hours the extension includes, and whether they cover your certificate and key handling.
- Audit evidence: Ask how the extension appears in your vendor risk file, since assessors will look for a supported platform or a documented exception with a plan.
- Parallel work: Use the extension period to inventory connections and build the target environment, not to postpone the inventory.
Keep the extension term shorter than the time your migration needs, and get the exit conditions in writing before you sign.
Moving to Keycloak replaces PingFederate's SAML and OIDC federation with a self-hosted server under the Apache License 2.0. It supports OpenID Connect, OAuth 2.0 and SAML 2.0, and can federate users from existing LDAP and Active Directory servers. The cost moves from a vendor subscription to your own infrastructure, skills and support arrangements. What remains is the migration project and the operating model you take on.
- Protocol coverage: Keycloak covers SAML 2.0, OIDC and OAuth 2.0, which matches most modern relying parties, but WS-Federation and WS-Trust are not covered by Keycloak alone.
- Release cadence: Keycloak's current release is 26.8.1, published October 13, 2026, and the project plans four minor releases a year. Plan an upgrade process, and keep the Operator on manual approval if you run it on Kubernetes.
- Backup and HA: Realm export and import is a limited backup tool and needs all nodes stopped, so design backups at the database level. High availability requires a synchronously replicated database, and the supported production databases include PostgreSQL 14 to 18.
- Operating cost: Recurring costs include infrastructure, database administration, patching, monitoring, and any Red Hat build of Keycloak subscription or external support you choose.
- Migration effort: Inventory, attribute mapping and cutover run application by application, with both systems running during the overlap.
Ask any implementation partner for a written scope that lists each connection, the protocol used and the test evidence for each cutover.
Some PingFederate estates serve WS-Federation relying parties alongside SAML and OIDC. Those relying parties, often older Microsoft or line-of-business applications, depend on WS-Federation and WS-Trust behavior that Keycloak alone does not provide. For these estates, moving everything to Keycloak leaves a gap. This path asks which relying parties still need WS-Federation before any target platform is chosen.
- Dependency inventory: Identify every relying party that uses WS-Federation or WS-Trust, including token formats, claim rules and certificate settings.
- Split target: One option is to run Keycloak for SAML and OIDC applications while a platform that supports WS-Federation handles the remaining relying parties. Confirm the split with both teams before cutover.
- WSO2 path: The sibling migration page for PingFederate to WSO2 Identity Server covers WS-Federation relying parties, connection and adapter mapping, user stores and the subscription question. Use it as the next read for these estates.
- Application changes: Some relying parties need code or configuration changes when the issuing server changes, so include application owners in the plan.
- Two-platform operations: Running two identity platforms adds monitoring, patching and audit scope, which should be priced into the decision.
Before choosing a path, confirm with each application owner whether WS-Federation is required or can be retired.
What the LTS and STS maintenance windows mean for planning
Ping's support policy gives Long-Term Support (LTS) and Short-Term Support (STS) versions different maintenance windows, so the version you run decides how long you can stay put before a forced decision. Before you compare upgrade and replacement costs, confirm which track your PingFederate version belongs to and get the exact end dates for maintenance, security fixes and any post-window options in writing from Ping. Do not rely on memory, on a reseller's summary or on a general description of the policy, because the window for your specific version is what sets your deadline.
Ask Ping to state, for your version, when standard maintenance ends and what Extended Limited Support covers, if anything, after that point. Extended Limited Support is sold separately, so it belongs in the cost model as a recurring line item rather than a free extension. Get the quote for it in writing with its term and scope, and confirm whether it covers security patches only or also defect fixes. Ask whether the window dates change if you later upgrade within the same track, since that changes the sequence of your upgrade projects.
Map those written dates against your change freeze calendar, your audit cycle and any scheduled identity projects, such as certificate renewals or partner onboarding. An upgrade must fit into a window your change board will approve, and a replacement migration needs a period where both systems run in parallel, which is harder to schedule near an audit or a fiscal close. If the end of your window falls inside a freeze, decide early whether you need a bridge contract, an accelerated upgrade or a migration start date. Record that decision with its owner, because auditors and risk committees will ask how the platform was supported during the gap.
How the cost of upgrading compares with moving to Keycloak
This table lists each cost component of staying on PingFederate through an upgrade or Extended Limited Support against moving to self-hosted Keycloak. Read it as a checklist of who is paid, what recurs, and what to request in writing before choosing a path. No Ping or DeployOpen prices are shown, so every figure should come from your own quotes and written scopes.
| Cost component | One-time or recurring | What drives it up or down | What to ask for in a quote |
|---|---|---|---|
| Ping subscription | Recurring | Licensed products, number of connections and environments, and renewal terms. Confirm which PingFederate version each subscription covers. | Itemized subscription for each environment, the support window for your exact version, and the end date of the current term. |
| Extended Limited Support fees | Recurring while used | Length of time you stay on a version past its support window, and how many versions you carry. Ping sells this separately from the subscription. | Price per year and per version, what the coverage includes and excludes, and the date it ends. |
| Upgrade project effort | One-time | Number of SAML and OIDC connections, custom adapters, OAuth clients, and how many test cycles your change process requires. | Written scope listing connections to retest, environments to upgrade, and the rollback plan, with named responsibilities for Ping and the implementer. |
| Keycloak licensing | None for the software | Keycloak is licensed under Apache 2.0, so the software itself carries no license fee. Costs shift to the components below. | Written confirmation from your implementer that no license fee applies to the community build you plan to run. |
| Red Hat build of Keycloak subscription | Recurring, if chosen | Choosing Red Hat's supported distribution instead of community Keycloak adds a subscription. Its support terms and version cadence differ from the upstream project. | Subscription tier, included support hours or channels, and the Keycloak version and end-of-support dates the subscription covers. |
| Infrastructure | Recurring | Hosting for the Keycloak nodes, a database from the supported list, load balancing, and a second site if you need high availability. Parallel running during cutover adds capacity for a period. | Node sizing for your user and login volume, database engine and version, and the high availability design your assessors expect. |
| Migration effort | One-time | Mapping PingFederate adapters and attribute contracts to Keycloak flows and mappers, handling WS-Federation dependencies, and moving user data. Users stored in a directory can be exported as LDIF and password hash handling needs its own plan. | Connection inventory, attribute mapping sheet, cutover plan for running both systems, and a statement of what is out of scope. |
| Ongoing operations | Recurring | Staff time for patching, Keycloak upgrades (four minor releases a year are planned), backups, monitoring, and on-call. The Keycloak Operator's manual approval mode adds a deliberate review step to each update. | Who performs each upgrade and backup task, the retained support or retainer scope if used, and the monitoring and alerting coverage included. |
How to deploy Keycloak to replace an aging PingFederate
This sequence moves PingFederate's federation work to a self-hosted Keycloak cluster in controlled waves, so each relying party is proven on Keycloak before PingFederate is retired. The result is a running, backed-up Keycloak estate with a tested cutover record for every application.
Confirm the target database and platform
The platform team chooses a production database from Keycloak's supported list, which includes PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database, Amazon Aurora PostgreSQL and Azure SQL. The default dev-file database is for development only and must not be used. Confirm the chosen database version against the Keycloak database guide and your own support matrix. The step is done when the database version, hosting model and operating team are written down and approved.
Choose the high availability architecture
The architecture lead selects one of the documented designs: a single cluster, optionally spread across availability zones, or a multi-cluster design. Keycloak documents multi-cluster deployments (v2) that do not need an external Infinispan cluster, and marks the older multi-cluster v1 as deprecated. Both supported designs require a synchronously replicated database, so confirm that your database platform can provide this before committing. The step is done when a written architecture diagram has been reviewed by security and operations.
Install Keycloak through the Operator
The platform engineers install the Keycloak Operator through Operator Lifecycle Manager, which Keycloak recommends, and deploy the Keycloak custom resource into a non-production namespace first. Set the operator's update approval to manual, as the Keycloak Operator documentation strongly recommends, so that no upgrade starts without a reviewed change. The step is done when a test cluster starts, reports healthy and accepts an administrator login.
Set up realm export as a limited backup
The operations team schedules regular realm exports with the kc.sh export command and stores the JSON files in a protected location. The Keycloak documentation warns that export and import have limitations as a backup and restore method, and that all nodes must be stopped while the process runs, so the database backup remains the primary recovery path. Restore a sample realm into a test environment to confirm the files are usable. The step is done when a documented restore test has succeeded.
Plan schema migration for each release
Keycloak migrates its database schema automatically at startup by default. For large deployments, Keycloak's upgrading guide suggests manual migration, where administrators apply the SQL themselves after review by a database administrator. The team decides which mode applies to its estate and records the choice in the runbook before any production upgrade. The step is done when the database team has approved the migration method and a rollback procedure exists.
Migrate relying parties in waves
The integration team moves applications in groups, starting with low-risk SAML and OIDC relying parties. For each application, it recreates the client in Keycloak, maps attributes through protocol mappers, and tests sign-in with real test accounts while PingFederate continues to serve production. Applications that depend on WS-Federation or WS-Trust need a separate decision, because Keycloak alone does not cover them. The step is done when each wave has a signed-off test record and a fallback to PingFederate is confirmed.
Run both systems through cutover
During each cutover window, the operations team keeps PingFederate available as a fallback while traffic for migrated applications moves to Keycloak. Monitor sign-in success, error rates and session behavior using Keycloak's metrics, and keep rollback steps ready for each application. Retire a PingFederate connection only after the application has run stably on Keycloak for a period the security owner agrees. The step is done when every in-scope connection is either live on Keycloak or formally retired.
Evidence to keep for the upgrade or migration decision
Whichever way the decision goes, the same evidence is needed to justify it and to run it safely. These items connect the lifecycle position of your current PingFederate version with the migration work that follows. Auditors and certification bodies, not DeployOpen, judge whether the controls around them are adequate.
Connection inventory
A dated list of every SAML service provider, OIDC client, OAuth client and WS-Federation or WS-Trust relying party that depends on PingFederate, with owner, protocol, attributes sent and business criticality. This is the baseline for every other item. Check it against traffic or sign-in logs, not only the configuration, because connections that no one remembers are often the ones that break at cutover.
Ping lifecycle letter for your version
Written confirmation from Ping of the support dates that apply to the exact PingFederate version you run, including whether it is on a Long-Term Support or Short-Term Support track. Keep it with the decision record. Ask in writing whether Extended Limited Support is offered for that version, what it covers, and what it costs, so the upgrade and replace options are compared on the same facts.
Test log per relying party
For each application, a record of the sign-in, single logout, attribute and token tests run against the upgraded PingFederate or the Keycloak candidate. Note the test account, the expected claims or assertions, the result and the tester. Relying parties that accept or reject tokens based on signing certificate, audience or issuer need explicit test cases, because those are the failures users see first after a change.
Cutover and rollback runbooks
Step-by-step procedures for switching each relying party, with named owners, the order of changes, the communication plan and the exact conditions that trigger a rollback. Include how DNS, metadata URLs and client secrets change, and how both systems run in parallel during the transition window. A runbook that has not been rehearsed in a non-production environment is a plan, not evidence.
Keycloak configuration exports and their limits
Exports of realm configuration taken with kc.sh export from the target environment, stored under the same change control as other configuration. Record what the export does not replace: it is not a full backup and restore mechanism, and the Keycloak docs say all nodes must be stopped while it runs. Keep user data, secrets and certificates in a separate, tested backup process.
Access reviews for administrator accounts
Dated reviews of who holds administrative access to PingFederate, to the target Keycloak realms and to the underlying hosts and databases, with approval records and removal of accounts that no longer need access. Run one before cutover and one after the old system is retired. Include service accounts and the credentials used by automation, since those are often missing from the review.
Questions buyers ask before choosing upgrade or replacement
How much does upgrading PingFederate cost compared with moving to Keycloak?
No public figure is available for either path, so the comparison has to be built from components. An upgrade costs the Ping subscription you already pay, any Extended Limited Support fees for a version past its window, and the internal or partner effort to test and cut over to the new version. A move to Keycloak removes the Ping subscription but adds a one-time migration project, a support subscription if you want one from a Keycloak distributor, and the operating cost of running the servers, database and high availability design in your own infrastructure. Ask Ping for the Extended Limited Support terms in writing, and ask your engagement partner for a fixed-scope quote based on your connection count. The gap between the two totals depends mostly on how many applications you run and how many need custom work.
How long does a PingFederate to Keycloak migration take?
Duration depends on the inventory, not on the product alone. The main drivers are the number of SAML and OIDC connections, how many use custom adapters or attribute transformations, whether any relying parties need WS-Federation or WS-Trust, and how many user stores feed the federation hub. Each application needs its own mapping of attribute contracts to Keycloak mappers, testing with the relying party's team, and a cutover window. Running both systems in parallel for a period is common and extends the calendar. No duration is stated here because none was supplied; ask for a timeline tied to a written inventory of your connections before accepting any estimate.
What does the migration require from our internal team?
The internal team owns the business decisions and the application knowledge, and that is usually the constraint. Someone needs to confirm which applications are live, who owns each relying party, which attributes each one expects, and when each can accept a change. Platform engineers need to run Keycloak on Kubernetes or virtual machines, manage the PostgreSQL database and handle upgrades. Security staff should review certificate handling, token lifetimes and MFA policy. Start by exporting the PingFederate configuration to build the inventory, which shows what the archive holds and what it leaves out, including adapter drivers and the license file.
Can our team migrate from PingFederate without outside help?
A team with Keycloak experience and a small number of standard OIDC or SAML connections can often do the work in house. Teams with many connections, custom adapters, WS-Federation relying parties or strict change control usually benefit from an outside partner for planning, parallel running and cutover testing. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Ask any partner to show how they will test each relying party before cutover.
What happens to WS-Federation relying parties if we move to Keycloak?
Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, so WS-Federation and WS-Trust relying parties are not covered by a Keycloak-only move. Identify them first in the PingFederate inventory. For those applications, the options are to keep PingFederate running for that subset, to move them to a platform that supports WS-Federation such as WSO2 Identity Server, or to change the relying party to SAML or OIDC where the application owner can do so. Each option has its own cost and test plan, so confirm the protocol coverage of any target platform against your list before committing.
How does Extended Limited Support fit into the decision?
Extended Limited Support is an option Ping sells separately for versions that have passed their standard maintenance window, so it is a cost line in an upgrade-in-place scenario rather than a replacement for an upgrade. Its scope, length and price are not included in the researched facts for this page, so ask Ping for the exact coverage, the end date and what it excludes, such as security patches or specific fixes. Compare that fee with the cost of an upgrade project and with a migration, and record the decision date so a contract change does not force a rushed move.
Which support window should our PingFederate version be on?
Ping's end of life policy separates Long-Term Support and Short-Term Support versions, and each has a different maintenance window. Find your installed version in the admin console, then check Ping's published lifecycle table for its window and end date. If the version is near the end of its window, plan the upgrade or migration before the date rather than waiting for a fee-based extension. Confirm the dates directly with Ping, because support windows and policy details can change.
What to confirm with Ping and in your own environment
Start by putting three questions to Ping in writing. First, what is the exact support window for your PingFederate version, and does it fall under Long-Term Support or Short-Term Support? Ask for the end of general maintenance date and the end of support date as separate answers, since the first can arrive well before the second. Second, what do Extended Limited Support terms cover for your version: which fixes, which severity levels, how long, and at what fee? Ask Ping to state those terms in the quote rather than in a general policy link. Third, does your version reach end of support on a fixed calendar date, or does the date depend on a later release? Keep the answers with the contract file, because they set the deadline for every option that follows, including a move to Keycloak.
Next, build the internal inventory that either path needs. List every relying party and its protocol, whether SAML 2.0, OpenID Connect, OAuth 2.0 or WS-Federation, and flag any WS-Federation or WS-Trust dependency, because Keycloak does not cover those protocols and that affects the choice of target. Record the signing and encryption certificates used for each connection, with their expiry dates, so that a renewal cannot break a relying party during a cutover. Document the PingFederate database, the clustering layout and the number of engine nodes, along with the backup and restore procedure your team has tested. These details determine whether an in-place upgrade or a new deployment is the lower-risk route.
Finally, confirm the environment that the upgrade or replacement will run in. Check who holds the PingFederate license file and administrator credentials, since a configuration archive does not contain everything needed to rebuild the service. Confirm the hosting platform, the load balancer and the monitoring already in place, and whether your change process allows parallel running of both systems during cutover. Ask your internal application owners which SSO connections are business critical and which can tolerate a short outage. The answers to these questions, combined with Ping's written terms, will show whether the cost comparison on this page holds for your estate.
How DeployOpen runs a PingFederate exit under your constraints
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source identity platforms inside your own infrastructure. For PingFederate end of life, we start by agreeing what the upgrade or replacement must cover, then build and hand over the result in writing.
How we scope
- We inventory your PingFederate version, support window and the connections that depend on it before work starts.
- Scope, deliverables and timelines are agreed in writing, because most engagements are fixed-scope.
- We confirm which relying parties need WS-Federation or WS-Trust, since Keycloak alone may not cover them.
How we build
- We map SAML and OIDC connections, adapters and attribute contracts to Keycloak clients, flows and mappers.
- We deploy Keycloak in your cloud account, data center or air-gapped network, with the database and high availability design you specify.
- We test each application in a staging realm and run old and new federation side by side during cutover.
How we hand over
- We document the configuration, runbooks, backup and restore procedures, and the upgrade path for future Keycloak releases.
- We prepare systems, controls and evidence for your compliance assessment, while independent auditors issue any audit report.
- We walk your platform and security teams through operation so they can run the service without us.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We can plan Keycloak minor upgrades in a staged way, keeping the Operator in manual approval mode if you run Kubernetes.
- We run security testing of the new identity service so findings feed back into your change process.
