Migrate from PingFederate to Keycloak

The number of relying parties and how much each one differs from the others is the largest single driver. Every SAML or OIDC connection needs its own client, redirect URIs, signing certificates, attribute mappings and a test pass, so a estate with many connections costs far more than one with a few shared patterns. Teams that group connections by protocol and attribute needs usually reduce the work because similar apps can share a template. Ask any quote to state the relying party count, the number of distinct patterns, and how many connections are retired rather than moved.

Custom adapters and deep attribute contracts take the most engineering time because Keycloak has no direct equivalent to every PingFederate adapter. Each adapter has to be traced to the user source it reads, then rebuilt as a Keycloak user federation provider, an identity broker, an authenticator or a protocol mapper. Simple contracts that map to standard claims are cheap to move. Ask the quote to list each adapter, its purpose, whether its source code is available, and who maintains it today.

Yes. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, so any relying party that depends on WS-Federation or WS-Trust needs a separate decision. Those connections may need a different platform, a gateway, or a rebuild of the relying party, and that work is not covered by a standard Keycloak configuration. Confirm early which connections use WS-Federation or WS-Trust, because they can change the timeline and the number of platforms in scope.

The user store determines how much data moves and how identities stay synchronized during cutover. Keycloak can federate existing LDAP and Active Directory servers, which can reduce data migration but keeps those directories in the critical path. Moving users into Keycloak itself adds an import step and a plan for password handling, since password hashes may not export from every source. Ask the quote whether the directory stays authoritative, how attributes are synchronized, and how many user stores are involved.

High availability is mostly a recurring cost, since it needs more nodes, a supported production database and a synchronously replicated database for the documented designs. Keycloak supports several production databases, and the choice depends on what your organization already operates and supports. Infrastructure, database licensing where it applies, and the staff who run failover all recur every month. Ask the quote to separate the one-time build of the cluster from the ongoing operation and to name the database it assumes.

Testing is often the largest share of effort that teams underestimate. Each relying party needs login, logout, session and attribute tests, and the business owner should confirm the result before the connection moves. Running PingFederate and Keycloak in parallel during cutover also means extra monitoring and rollback planning. Ask the quote for the test scope per connection, who signs off, how rollback is handled, and whether the parallel run period is included.

Internal staff own the business decisions, application owner testing and access to relying party code, and their time is usually the largest unseen cost. An implementation partner, such as DeployOpen on a fixed written scope, is paid for planning, implementation, testing and documentation of the agreed work. A Keycloak support subscription is recurring and is bought separately from the software, which is licensed under Apache 2.0. Ask each quote to name who pays for each item and which items are one-time versus monthly or annual.

Keycloak plans four minor releases a year and a major release every two to three years, and says breaking changes in a minor release will be opt-in. That cadence means upgrades are a recurring task, and the cost depends on how often you take them and how much custom code you run. Operator updates should use manual approval mode to avoid unplanned upgrades. Ask the quote how upgrades are scheduled, who tests them, and whether the upgrade effort is included in a retainer or billed separately.

The cost depends mostly on how many connections you run, how many of them use custom adapters or attribute logic, and whether any relying parties depend on WS-Federation or WS-Trust. No price or effort figure is supplied for this move, so ask for one based on a written inventory. Cost falls into a few components: the discovery and inventory work, the mapping of each adapter and attribute contract to Keycloak clients, flows and mappers, testing with each application owner, and the parallel running period during cutover. Keycloak itself is licensed under Apache 2.0, so the software licence line is zero, but production hosting, database operations, and any support subscription recur. Ask any implementation partner to price each cost component separately, and ask which items are one-time and which recur.

The pace is set by the number of applications, the complexity of each connection, and how fast application owners can test. No duration is supplied for this move, so treat any timeline as something to agree in writing after the inventory is complete. Migrating application by application lets you move low-risk SAML and OIDC connections first and leave WS-Federation relying parties for a later decision. Test windows, change approvals and the need to keep both identity providers running during cutover will usually set the calendar more than the configuration work does. Ask for a timeline that lists each wave of applications, the owner who signs off each one, and the rollback step for each wave.

Yes, a team with experience in SAML, OIDC and directory integration can run the migration, and Keycloak's documentation covers realms, clients, identity brokering and user federation. The harder part is usually the discovery work: finding every connection, its owner, its certificates and its attribute dependencies, including connections nobody has touched for years. Keycloak's own export and import commands are not a complete backup mechanism, and its documentation warns that all nodes must be stopped while a realm export runs, so the team also needs a tested operating plan. If internal staff lack time or recent federation experience, a fixed-scope engagement with written deliverables is one option. DeployOpen plans, implements, integrates and documents self-hosted platforms in your own infrastructure, though it does not issue audit reports.

The project needs access to the PingFederate configuration, a named owner for every application that federates through it, and dedicated test windows for each application. Start with an export of the configuration archive, which holds connections, OAuth clients and certificates but leaves out items such as adapter drivers and the license file, so you will also need those from your own records. For each connection, record the protocol, the service provider metadata, the attributes sent, the signing and encryption certificates, and the business owner who approves a change. Test windows should include a user acceptance test, a rollback path and a period where the old and new identity providers both serve the application. Confirm with your Ping administrators and application teams which of these items already exist.

Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, so it covers SAML and OIDC relying parties directly. The supplied facts do not confirm WS-Federation or WS-Trust support in Keycloak, so do not assume a like-for-like replacement. Check every relying party for WS-Federation or WS-Trust dependencies before planning the move. Where those dependencies exist, you have several paths: move the relying party to SAML or OIDC if its vendor supports it, keep a separate component for those applications, or plan a move to WSO2 Identity Server, which supports WS-Federation. Confirm the protocol coverage of any candidate platform against its current documentation before you commit.

Keycloak is Apache 2.0 licensed, so the software itself does not require a licence fee to run. Whether you need paid support depends on your internal skills, your uptime obligations and how much on-call coverage you can staff. Red Hat offers a supported distribution called Red Hat build of Keycloak, which replaces Red Hat Single Sign-On, and the Red Hat product page lists version 26.6 as its latest. Ask any support provider which Keycloak versions it covers, its response terms and whether it covers upgrades. The support decision should be weighed against your own operations cost, not treated as a licence cost.

Keycloak plans four minor releases a year and a major release every two to three years, and it says breaking changes in minor releases will be opt-in, according to its October 2024 release update. The current release is 26.8.1, published October 13, 2026. Plan for regular upgrades in your operating budget, and read the upgrading guide before each one. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades. Database schema migration runs automatically at startup by default, but large deployments can apply the SQL manually, so decide that during design.