Migrate from ForgeRock to Keycloak

The largest cost drivers are the number and complexity of authentication trees, the number of applications that depend on them, and the size of the identity store. Each authentication tree is a journey with its own branching logic, so a tree with many risk checks, social login branches and step-up rules takes more work to rebuild as Keycloak authentication flows than a simple username and password tree. Costs fall into one-time items (inventory, design, rebuilding flows, migrating identities, testing, cutover) and recurring items (hosting, database operations, patching, monitoring, and any support subscription you choose). Ask any partner or vendor for a quote that lists these components separately, and ask how each application's login path is counted. Keycloak itself is licensed under the Apache License 2.0, so the software licence line is not the main variable. Confirm with your Ping or ForgeRock account team what your current subscription covers and what contractual notice applies before you stop renewing.

Duration depends on the inventory, not on the Keycloak software, which installs quickly on its own. The main factors are how many authentication trees and journeys exist, how many relying applications need new client configuration, how many users and directory attributes must move, and how many environments (development, test, production) must be rebuilt. Teams with custom Java plugins or scripted nodes in their trees will need longer for design and testing because those behaviours must be re-expressed in Keycloak terms, which may involve custom authenticators. Plan time for parallel running, user communication and rollback rehearsal. Keycloak's own upgrading guide and release policy, with four minor releases a year since Keycloak 26.0, mean your target version should be fixed early so testing is not repeated. Ask for a timeline that is tied to a written scope with named deliverables.

You need to supply access and decisions that only your organization can give. This includes exports or read access to the ForgeRock configuration, a list of every application and its protocol (OpenID Connect, OAuth 2.0 or SAML 2.0), the authentication tree logic with its business rules, and the directory schema and attribute mappings. You also need named owners for each application, a test plan with users who can validate logins, a change window approved by operations, and a decision on the target hosting environment, including the database and high availability design. Keycloak supports several production databases, including PostgreSQL 14 to 18, so the database choice must be made early. Security and compliance teams should define password policy, MFA requirements and evidence they need. Without these inputs, any quote will carry risk allowances that raise cost.

An internal team can do it alone if it already operates identity infrastructure and has people with Keycloak, LDAP and protocol experience, and if the estate is small enough to test thoroughly. Many organizations split the work: internal staff own the applications, business rules and sign-off, while an implementation partner handles flow design, identity migration scripts, hardening and documentation. The decision depends on skills that are scarce, such as directory replication and token lifecycle knowledge, and on whether you can staff a cutover and an on-call rota. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms in your own infrastructure, and its engagements are fixed-scope with written deliverables. Ask any partner to show how knowledge will transfer to your staff.

Identities move by exporting user records and mapping them to Keycloak users, but password hashes are the hard part. Keycloak can import realms as JSON with the export and import commands, and the documentation warns that this is not a complete backup and restore method and that all nodes must be stopped while it runs, so it should be treated as a migration tool rather than routine backup. Keycloak can also federate existing LDAP and Active Directory servers, which lets users keep their directory credentials while you transition. If password hashes cannot be exported in a compatible format, the usual options are federation during a transition period, forced password reset or a progressive migration on first login. Ask your ForgeRock or Ping team which hash algorithms are in use and whether a hash export is available under your contract.

Yes, parallel running is a common pattern, and it is usually the safest way to cut over application by application. Each relying application can be pointed at Keycloak in a test environment, then in production, while the rest stay on the existing platform. This requires that both platforms can reach the same user population, typically through directory federation or synchronized identities, and that session and token behaviour is documented for each app. Keep the old platform available until rollback has been rehearsed and the agreed exit criteria are met. Keep in mind that Keycloak upgrades use database schema migration at startup by default, or manual SQL for large deployments, so plan the parallel environment carefully. Confirm with your current vendor how long existing support and environments remain available during the overlap.

The choice is a business decision that should compare protocol needs, directory dependencies, release lifecycle and who operates the platform. Keycloak is open source and self-hosted, which gives you control over upgrades and hosting, but it also means your organization or a partner owns operations, patching and backups. Staying on a Ping product keeps operations with the vendor but leaves you dependent on its roadmap and support terms. Make the decision from a written inventory and a cost model that covers both paths. Confirm with Ping which support windows apply to your current versions, and with your architects whether any relying party needs protocols that Keycloak does not cover in your environment.