ForgeRock AM vs Keycloak: which to choose

ForgeRock Access Management alternative: when to stay on PingAM and when to move to Keycloak

Keycloak fits when your PingAM estate can be redesigned around standard protocols and a team willing to run an open-source server, and PingAM fits when the estate depends on Ping's roadmap, contracted support and features you cannot yet rebuild. The decision turns on four things: the authentication trees in use, the directory the estate depends on, the release cadence your team can absorb, and who will operate the platform after go-live. Keycloak is licensed under Apache 2.0 and is a Cloud Native Computing Foundation incubating project, so the license and governance are clear before you start. Moving is a design exercise, not a file copy: PingAM authentication trees do not transfer as configuration, and each one must be rebuilt as Keycloak authentication flows and tested against the same user journeys.

Stay on PingAM when a renewal is near and the estate uses trees with custom nodes, scripted logic or vendor-specific integrations that would take significant redesign, when your compliance evidence is built around Ping's support model, or when a residency requirement is already met by your current deployment. Confirm with Ping the exact end-of-support dates for your PingAM version, the upgrade path to PingAM 8, and what the contract covers. Move to Keycloak when you need to own the release schedule, when the estate uses mainly OpenID Connect, OAuth 2.0 and SAML 2.0 applications, or when licensing changes make the current model hard to justify. Keycloak's Backwards compatibility in Keycloak releases post explains how minor releases are handled, which your team must absorb as a standing operating task.

Before choosing, map every tree to the Keycloak flow it would become, list each directory attribute the trees read, and identify which user store Keycloak will federate. Keycloak supports user federation with existing LDAP and Active Directory servers, so the directory may stay in place while the authentication layer changes. Price the work by its components: the one-time design, rebuild and parallel run, and the recurring patching, upgrades and on-call support, with either your staff or a partner such as DeployOpen carrying the operations. Ask any implementation partner for a written scope that lists each tree, each directory dependency and each test before you commit to a date.

Which option fits each scenario

This table matches common ForgeRock Access Management situations to the option that tends to fit them better, Keycloak or staying on PingAM. Read each row as a condition to test against your own estate, not as a verdict, since the right answer depends on your integrations, team and support needs.

Scenario	Better fit	Why
Mostly SAML and OIDC web applications backed by LDAP or Active Directory	Keycloak	Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0 and has built-in user federation with existing LDAP and Active Directory servers. Confirm that each application's protocol profile and attribute needs map to Keycloak clients and mappers.
Custom authentication trees that encode business journeys	Stay on PingAM for now, or plan a rebuild	Trees are a visual, node-based model that Keycloak does not copy one for one. Journeys usually need to be rebuilt as Keycloak flows, required actions or extensions, so inventory each tree before deciding.
Need for source code access and patching on your own schedule	Keycloak	Keycloak is Apache 2.0 licensed, so your team can read, build and patch the code. Confirm your internal change control and who holds the skills to apply and test upgrades.
Organization already buys Ping products for other identity services	Stay on PingAM, or consolidate on Ping	Shared contracts, support and integrations with PingFederate or PingOne can outweigh the savings of a move. Model the cost of running two platforms before you decide to split.
No in-house identity engineers and need an operations partner	Keycloak with a partner for operations	Keycloak can run in your infrastructure while an implementation partner handles planning, hardening, backups, upgrades and support under a written scope. The skill gap is then covered by contract, not by hiring.
Estate needs a supported distribution with a vendor contract	Red Hat build of Keycloak, or stay on PingAM	Red Hat build of Keycloak is Red Hat's supported distribution based on the open source project. Confirm the support terms, lifecycle and which versions your contract covers.

How ForgeRock Access Management became PingAM

The product your team runs has changed owners and names several times, so roadmap risk depends on which line of the product you are on. Ping's documentation traces Access Management from Sun's OpenSSO, to ForgeRock OpenAM in 2010, to a rename to Access Management with versions 5 to 7.4 between 2017 and 2023, and then to PingAM 7.5 in 2024 and PingAM 8 in 2025. Thoma Bravo completed its acquisition of ForgeRock on August 23, 2023 and combined ForgeRock into Ping Identity, so the platform's direction since then has been set inside Ping's portfolio rather than by the original ForgeRock company. Check which major and minor version your estate runs (the admin console and the installed package show it) and map that to the names above, because a deployment on a 7.x release and one on PingAM 8 face different upgrade questions.

For a team deciding whether the product direction still matches its needs, the lineage raises three questions: whether the features you depend on (authentication trees, OAuth 2.0 and SAML configuration, and the directory integration) are still being developed, how often the platform changes and whether those changes break your customizations, and who accepts responsibility for fixes on your exact build. Ping has moved the product through a rename and a major version, which is normal for a platform in active development, but it also means that scripts, custom nodes and deployment templates written for older releases may need rework. Record your customizations in a list before you decide, since that list is the input to any migration estimate, whether you stay or move.

Do not rely on the product history alone to judge support. Ask Ping in writing to confirm the current support windows, end-of-life dates and supported upgrade paths for your exact PingAM version, including whether a move to PingAM 8 is supported from your release and what extended support would cost if you cannot upgrade in time. Ask the same question about any Ping roadmap item your business case depends on. Keep the written answers with your architecture decision record, because a verbal assurance about direction does not hold up at renewal or in an audit review.

Capability comparison: PingAM and Keycloak

This table maps the main identity capability areas of PingAM and Keycloak so you can see where each product applies and where you need to confirm details. Use the Keycloak column for supplied facts, and check the PingAM column against the Ping documentation for your exact version before drawing conclusions. The main takeaway is that the protocol and federation coverage overlaps heavily, while the authentication model and operating responsibilities differ.

Capability	PingAM	Keycloak
Protocols	Covers OpenID Connect, OAuth 2.0 and SAML 2.0 as core access management functions; confirm supported profiles and versions in the PingAM 8 documentation	Supports OpenID Connect, OAuth 2.0 and SAML 2.0
Single sign-on	Provides centralized web and API SSO; confirm session and cross-domain behavior for your version	Provides single sign-on across registered clients
Identity brokering	Confirm external IdP social and federated login options in the PingAM documentation	Provides identity brokering to external identity providers
User federation with LDAP and Active Directory	Connects to LDAP-based data stores; confirm Active Directory specifics for your version	Built-in user federation with existing LDAP and Active Directory servers
Admin console	Administration console and REST-based configuration; confirm the console scope for your version	Includes an admin console for realms, clients and users
Fine-grained authorization	Policy-based authorization through its policy engine; confirm policy agent and scope details	Fine-grained authorization services available
Authentication model	Authentication trees built from nodes and decision logic	Authentication flows built from executions and subflows; trees must be rebuilt as flows
Database support	Confirm supported data stores and configuration store options in the Ping deployment guide	MariaDB, Microsoft SQL Server, MySQL, Oracle Database, PostgreSQL 14 to 18, Amazon Aurora PostgreSQL and Azure SQL
High availability	Confirm clustering and site redundancy model in the Ping deployment planning docs	Three documented architectures; both supported designs need a synchronously replicated database
Licensing	Commercial subscription from Ping Identity, now part of Thoma Bravo's portfolio	Apache License 2.0
Source availability	Closed source; confirm access to code and patches under your Ping agreement	Open source on GitHub, CNCF incubating project

Authentication trees, Keycloak flows and directory dependencies

Moving from PingAM to Keycloak touches four layers that teams often assume map one to one: the protocols and applications that depend on the platform, the login logic, the directory behind it, and any custom code. Each card below names what to inventory first, why the conversion is design work, and what to confirm before committing to a cutover date.

Protocols and relying parties

Start with a list of every relying party that authenticates through PingAM, grouped by protocol: OAuth 2.0 and OpenID Connect clients, SAML 2.0 service providers, and any legacy agents or web policy enforcement points. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, so most federated applications have a direct equivalent. Record the redirect URIs, signing certificates, token lifetimes and claims each application expects, because a Keycloak client that issues a different claim set breaks an app that never reported the change. Confirm with Ping or your own configuration export which protocol features are in use before assuming parity.

Authentication logic and flows

PingAM authentication trees are graphs of nodes that branch on conditions such as risk scores, device state or group membership. Keycloak expresses similar logic through authentication flows, with executions, conditional sub-flows and required actions that prompt users to complete steps such as password updates or MFA enrollment. The conversion is design work: a tree branch that depends on a custom node may have no single Keycloak execution, and some decisions move to an external policy or custom authenticator. Map each tree to a written list of outcomes, then prototype the hardest path in a test realm and confirm which custom authenticators or extensions must be rebuilt.

Directory dependencies and password handling

Identify where user records live: an existing LDAP or Active Directory tree, a ForgeRock or Ping user store, or both. Keycloak has built-in user federation with existing LDAP and Active Directory servers, so the directory can often stay in place while Keycloak handles sessions and protocols. Inventory the service accounts used for binds, the attributes mapped into tokens, and how passwords are verified, because hash formats and password policies do not transfer automatically. Test password policy enforcement and attribute mapping on a copy of your data before any production user is pointed at the new realm.

Custom code and extensions

List every custom Java plugin, scripted node, token transformer, self-service page, and integration that calls PingAM APIs or REST endpoints. Each one needs an owner and an answer to a simple question: is it still required once the flow moves to Keycloak? Some items become Keycloak SPI extensions or authenticators, some become external services, and some disappear because a built-in feature covers them. Ask Ping which extension points your deployed version supports and whether any vendor-supplied code is licensed for reuse, and confirm the rebuild effort in a proof of concept rather than from a general estimate.

Who operates each option

Staying on PingAM keeps the product under Ping's release and support policies. Ping, or your existing internal team working under Ping's support terms, handles product defects and security fixes, but your team still owns the deployment, the configuration and the upgrades you schedule against Ping's version windows. Confirm the exact support terms, including which versions are covered and for how long, directly with Ping before you rely on them.

Patching: Product fixes arrive through Ping's channels. Your team applies them to each environment and tests authentication trees and directory connections after every change.
Upgrades: Major moves between PingAM releases follow Ping's lifecycle. Ask Ping which versions are supported at your target date and what extended support costs if you fall behind.
Backups and monitoring: Your team owns the directory, the configuration store and the recovery procedure, along with monitoring and alerting.
Incidents: Escalation runs through Ping's support contract. Check the severity model and response commitments in writing.
In-house: Authentication tree design, integrations with applications and the directory, and the upgrade calendar.

Ask Ping and your current partner which tasks are covered by your contract and which are your responsibility.

Data location, hosting and compliance implications

Keycloak runs wherever you put it: in your own cloud account, your data center or an air-gapped network. Identity records, credentials, sessions and audit events live in the database you connect through the supported database list, so the control question is who can reach that database, who holds its encryption keys and where its backups go. Under a self-managed ForgeRock Access Management deployment, the same questions apply to the AM configuration store and the directory behind it, so the first task is a written map of every store that holds user attributes, password verifiers, token data and session state, with its host, owner and backup location. Confirm with Ping's documentation and your own architecture which of these stores you control today.

Keycloak's realm export is the item most likely to be overlooked. The kc.sh export command writes realm data, including users and client configuration, to JSON files, and those files can contain sensitive material such as client secrets and hashed credentials, so treat them as restricted records: encrypted storage, access logging, a retention rule and no copies in collaboration tools. The Keycloak server guide warns that export and import have limitations as a backup and restore method and that all nodes must be stopped while the command runs. For a regulated environment that means a database-level backup and restore procedure is still required, and the export is a migration artifact, not your disaster recovery plan. Plan maintenance windows accordingly and test a restore before you rely on either path.

Compliance evidence is a shared task that you should settle before the migration starts. DeployOpen can plan, configure and document the controls that an assessment will look at, including access reviews for administrator roles, logging, key handling, backup and restore tests and change records, and it can package that evidence for your assessor. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments, so ask your assessor early which control evidence they expect for identity systems and whether the existing Ping evidence set can be matched control by control.

What drives the cost of each option

Costs for staying on PingAM and for running Keycloak fall into different buckets: license and support terms on one side, infrastructure and people on the other. Each card below names who is paid, whether the cost is one-time or recurring, and what moves it, so you can build a like-for-like quote before choosing a path.

PingAM subscription and license terms

Your current spend on PingAM is set by your Ping agreement, including the product entitlement, the number of users or the metric in your contract, and any renewal uplift. Find out whether the subscription covers the software, the update channel and the right to run in your own cloud, data center or air-gapped network. Ask Ping to confirm in writing which PingAM versions are covered at renewal and whether a move to PingAM 8 is included or billed separately.

Vendor support and extended support obligations

Support is the cost most likely to change at the next renewal. If your PingAM version is nearing the end of its support window, ask Ping in writing what extended or limited support would cost, how long it runs, and whether security fixes are included. Compare that recurring fee with the one-time effort of upgrading or migrating, and record the answers in your quote file so the comparison uses the same dates.

Keycloak software and optional commercial support

Keycloak is licensed under the Apache License 2.0, so there is no license fee for the software itself. Recurring costs come from optional support, such as Red Hat build of Keycloak or a partner support agreement, which you should price by written quote. Check which Keycloak release line the support covers, and confirm how often minor releases arrive, since the project plans four minor releases a year and opt-in breaking changes.

Infrastructure for clustered high availability

Production Keycloak needs compute, load balancing and a database that supports the high availability design you pick. Keycloak documents a single cluster across availability zones and a multi-cluster design, and both supported designs need a synchronously replicated database. Costs rise with the number of nodes, the database tier, backup storage and the second site. Ask your cloud or data center team to price these as recurring items, and ask Ping to show what your PingAM footprint costs today for a fair comparison.

Operations staff and on-call effort

Someone must patch, upgrade, monitor and back up the platform, whether it is PingAM or Keycloak. This is usually the largest recurring cost and it is often missing from first estimates. Count the hours for upgrade windows, the on-call rota, and the work to approve operator updates in manual mode if you use the Keycloak Operator. Ask any implementation partner to state in the written scope which of these tasks they run, which your team keeps, and for how long.

One-time migration work

Moving from PingAM to Keycloak carries one-time costs: inventorying applications, rebuilding authentication trees as Keycloak flows, moving identities and credentials, testing directory connections and running a controlled cutover. Costs rise with the number of applications, custom tree nodes and directory dependencies. Request a fixed-scope quote that lists each phase, the test evidence it produces, the rollback plan and who signs off each cutover, so you can compare it with the cost of staying on PingAM.

What a move from PingAM to Keycloak involves

This sequence takes a PingAM estate from inventory to a documented Keycloak operation, with each stage producing evidence that the next stage depends on. It is written for teams that have decided to move and want to know who does what and how each step closes.

Inventory applications, protocols and certificates
DeployOpen works with your architects and application owners to list every relying party that depends on PingAM, with its protocol (OpenID Connect, OAuth 2.0, SAML 2.0 or header-based access), redirect URIs, signing and encryption certificates, token lifetimes and session rules. You provide access to PingAM configuration exports, application owners for interviews, and the certificate inventory. The step is complete when every relying party has a row in an agreed inventory and each row has a named owner who has confirmed it.
Map authentication trees to Keycloak flows
Each PingAM authentication tree is documented node by node, including conditional branches, step-up logic, MFA choices and custom scripts. DeployOpen then maps each tree to a Keycloak authentication flow, identifying where a Keycloak built-in execution covers the behavior and where a custom authenticator or an external step is needed. Your security team reviews and signs off the mapping, including any logic that changes. The output is a flow design document with a gap list that names every behavior Keycloak will not reproduce without custom work.
Plan user federation and attribute mapping
The current user store, whether a ForgeRock or PingDirectory directory, LDAP or Active Directory, is examined for schema, password storage, account states and the attributes that tokens and claims depend on. Keycloak can federate existing LDAP and Active Directory servers, so the plan decides whether Keycloak reads the directory in place or whether identities are migrated. You provide directory access, schema details and the attribute consumers list. The step closes with an attribute mapping table and a decision, recorded in writing, on how passwords and credentials will be handled.
Build a non-production Keycloak on a supported database
DeployOpen builds a non-production Keycloak environment in your infrastructure using one of the production databases Keycloak supports, not the development file database. The build covers TLS, hostname and proxy configuration, realm structure and the client definitions from the inventory. Your platform team provides the hosts or cluster, the database and the certificate authority. The environment is ready when the configuration is stored as code, can be rebuilt from that code, and the team has logged in as an administrator.
Test relying party connections
Each relying party is connected to the non-production Keycloak and tested for login, logout, token claims, token refresh, SAML assertion content and error handling. Test cases come from the inventory and the authentication flow design, and application owners run their own acceptance tests. Failures are logged against the mapping document so that gaps are resolved or accepted by an owner. The step is complete when every relying party has a signed test result and every open gap has a recorded decision.
Design high availability and backup
Keycloak documents three high availability architectures, and both supported multi-site designs need a synchronously replicated database, so the team chooses one design against your availability requirements and network. The backup approach is set alongside it: the realm export and import commands are useful for moving configuration but have documented limitations as a backup and restore method and require all nodes to be stopped while they run. Database backups and infrastructure-as-code are therefore central to the recovery plan. You confirm recovery objectives with your business owners. The step closes with a tested restore procedure on the non-production environment.
Run both platforms in parallel with a rollback path
Applications are moved in waves while PingAM remains active for the rest. Each wave has a documented cutover, a verification checklist and a rollback step that returns the application to PingAM. Keycloak schema migrates automatically at startup by default. Large deployments can instead apply the migration SQL manually, which the upgrading guide suggests for them, and DeployOpen recommends deciding this before the first production start. Your change board approves each wave. The wave is closed when monitoring shows successful logins and the rollback has been rehearsed.
Document operations and upgrade procedures
The operating model is written down: who administers realms and clients, how changes are reviewed, how upgrades are tested against the non-production environment, and how monitoring and metrics are configured. Where Kubernetes is used, the Keycloak Operator is installed through Operator Lifecycle Manager and its documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades, so that setting is recorded as policy. Your operations team takes ownership and runs a handover exercise. The step is complete when runbooks are accepted and the first upgrade has been executed through them.

Questions buyers ask before moving from ForgeRock Access Management

How much does moving from ForgeRock Access Management to Keycloak cost?

The cost depends on the scope of the estate, and no single figure applies to every organization. The main components are the Ping or ForgeRock subscription you keep paying during the overlap, the infrastructure for Keycloak in your own environment, the internal staff time, the outside engineering for rebuilding authentication flows and integrations, and the support subscription if you want one. The biggest drivers are the number of applications and protocol connections, how many custom authentication trees exist, the directory and user store work, and the testing effort. Ask any provider for a quote built from a written scope that lists each component separately, and state whether the figure covers one-time migration work, recurring operations, or both.

How long does a migration from PingAM to Keycloak take?

Duration is set by how many applications, authentication trees and user stores need to move, and by how much of the old behavior you need to reproduce exactly. Teams with a small set of standard SAML or OIDC connections typically move faster than teams with many custom journeys, step-up rules and policy decisions tied to the access manager. Other factors include the directory design, the number of environments, change approval windows and the amount of parallel running you want before cutover. Ask for a timeline by phase in the written scope, with explicit assumptions about the number of applications and the test coverage expected.

Can our in-house team migrate to Keycloak without outside help?

Some teams can, particularly those with experienced identity engineers and a clear inventory of their applications. The work requires knowledge of OIDC and SAML details, Keycloak realms, clients, flows and mappers, database and clustering operations, and Kubernetes or VM operations depending on your deployment. It also requires someone who understands the existing authentication trees well enough to reproduce their logic. Assess your team against those skills, then decide which parts you will do internally and where an implementation partner adds value, such as hardening, testing or runbook preparation. DeployOpen plans and implements these migrations in the client's own infrastructure under a fixed-scope agreement, so you can separate internal and external work in the scope document.

Can Keycloak federate our existing LDAP or Active Directory directory?

Yes. Keycloak has built-in user federation with existing LDAP and Active Directory servers, so you do not have to move every identity before cutover. Confirm the details in your own environment: which attributes map to Keycloak user fields, how password validation works for your directory, whether group and role mappings meet your access model, and how account state and disablement are synchronized. Also confirm which directory dependencies sit behind ForgeRock, such as a separate identity store or custom data sources, because those need their own plan. Test the federation with real accounts from each directory segment before you commit to a cutover date.

How does the Keycloak release cadence affect our upgrade planning?

Since Keycloak 26.0, the project plans four minor releases a year and a major release every two to three years. The project says breaking changes in a minor release will be opt-in, which means routine minor upgrades should carry less disruption than major ones, but you still need to read the release notes and the backwards compatibility guidance for each version you adopt. Plan for a regular test cycle in a non-production environment, and decide whether you will use the Keycloak Operator with manual approval mode for updates so upgrades do not happen unintended. Confirm how your chosen support provider covers each release line and how long they maintain a given version.

What does the migration need from our staff and change process?

The migration needs named owners for applications, identity architecture, security review, and operations, plus access to application teams who can test their login flows. Your change process must allow staged rollouts, rollback plans and approval windows for each application cutover. Expect the security team to review the new configuration, certificates, token lifetimes and administrative access, and expect compliance staff to ask for evidence of testing and change records. Ask your provider to list these roles in the written scope, and confirm how much time each role must commit in each phase. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies perform the assessments.

Can we run PingAM and Keycloak side by side during the transition?

Yes, most teams run both during a transition, moving applications one at a time while the existing access manager continues to serve the rest. Running both requires a plan for session handling, cookie domains, redirect URIs, the user store that each platform reads, and which platform is the source of truth for each application. Confirm that your identity data remains consistent between systems, that you can route users to the correct platform, and that you can roll back an application without affecting others. Also confirm how long your PingAM subscription and support run during the overlap, because that period adds recurring cost.

How DeployOpen helps evaluate, implement or migrate

DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a ForgeRock Access Management or PingAM estate, that work starts with a written scope that separates the decision from the build.

How we scope

We inventory the PingAM realms, authentication trees, OAuth clients and SAML connections in use today.
We map which applications depend on each protocol and which directory backs their user lookups.
We agree deliverables, timelines and exclusions in writing before any build work starts.
Engagements are fixed-scope, and ongoing support can be added later as a retainer.

How we build

We rebuild in-scope authentication journeys as Keycloak authentication flows, with the gaps documented for your review.
We connect Keycloak to your existing LDAP or Active Directory servers through user federation and test attribute mappings.
We deploy to your infrastructure using the database and high availability design your scope specifies.
We run functional, negative and security tests on each protocol flow before any application cutover.

How we hand over

We deliver architecture, configuration and runbook documentation covering realms, clients, flows and upgrade procedures.
We document backup and restore steps, including the limits of realm export and import, so your team can run them.
We train your operators on administration, monitoring and the release process your team will own.
We produce compliance-readiness evidence for your assessors, while independent auditors issue any formal opinion.

How we support

Support can be contracted as a retainer covering upgrades, patching and post-cutover tuning of the Keycloak estate.
Upgrades are tested in a non-production environment against your applications before any production change.
Continuous security testing of applications and APIs that rely on the platform can be added to the retainer.
Ask any provider to confirm in writing who owns each operational task after handover.

ForgeRock Access Management vs Keycloak