Migrate from Okta to Keycloak

Migrate from Okta to Keycloak: what the move involves

The move from Okta to Keycloak is a re-federation and rebuild project, not a data copy. Whether the trigger is a renewal, a licensing change, a residency requirement or lock-in pressure, the work is to stand up Keycloak, bring identities across, and then re-create every trust relationship, policy and enrollment that Okta currently holds. User exports carry identities, not the configuration around them. This work is usually run by an internal platform or security team, often with an implementation partner for the parts that are new to them. Ownership is the first decision to settle: who operates the Keycloak cluster and its database after cutover, who approves app changes, and who signs off on the identity model. Effort and risk depend mostly on the number of applications, how many use SAML versus OIDC, and whether Okta's directory is the source of truth or a copy of Active Directory.

Okta's List Users API with a filter can produce the active user list, and the Admin Console's Password Health report offers a CSV for the same purpose. Those exports contain profile attributes, not passwords, so users will need to set new credentials or sign in through a federated directory during the transition. Confirm with your own Okta administrators which attributes and group memberships must be carried over, because they are the input for kc.sh import and for any LDAP or Active Directory mapping. The items that must be rebuilt by hand are the application integrations (redirect URIs, signing certificates, attribute statements and client secrets), sign-on and access policies, group-based assignments, and MFA enrollments. Each enrolled factor is tied to Okta, so plan re-enrollment and a fallback path for users who lose their device during the window. Keycloak's realm export is useful for documenting the target configuration, but the docs warn it has limits as a backup and that all nodes must be stopped while it runs, so plan the cutover around that constraint.

Which Okta capabilities map to Keycloak, and which need rework

This table maps each Okta capability used in a workforce deployment to its Keycloak equivalent and marks it clean, needs rework or gap. Treat every mark as a starting point: confirm Keycloak feature coverage against the documentation for the release you deploy, not against assumed parity with Okta.

Okta capability	Keycloak equivalent	Status and what to plan
OIDC and OAuth 2.0 app SSO	Clients in a realm with redirect URIs, scopes and client scopes	Clean for most apps. Re-register each client, then confirm token claims and redirect URIs match what each app expects.
SAML 2.0 app SSO	SAML clients with signing certificates and attribute mappers	Needs rework. Each SAML app needs a new entity ID, ACS URL and signing certificate, and the app side must trust the new metadata.
Okta AD agent and delegated authentication	LDAP or Active Directory user federation in Keycloak	Needs rework. Keycloak reads directory users directly, so service accounts, bind permissions and attribute mappings must be designed and tested.
Okta Universal Directory user store	Keycloak internal user store or an external LDAP directory	Needs rework. Decide whether identities live in Keycloak or in a directory such as FreeIPA, then plan the user import or federation path.
SCIM provisioning to SaaS apps	Keycloak has no general-purpose SCIM provisioning engine for downstream apps in the way Okta does	Gap. Confirm current SCIM support in the release you deploy and plan per-app provisioning or a connector for each target app.
Lifecycle workflows (joiner, mover, leaver)	Driven by directory changes, admin API scripts or an external workflow tool	Gap. Okta Workflows-style automations need to be rebuilt in your own tooling, and each leaver step must be defined and tested.
MFA factors (push, OTP, WebAuthn)	Built-in OTP and WebAuthn, with other factors through extensions or external tools	Needs rework. Users re-enroll factors, and Okta Verify push and vendor-specific factors have no direct equivalent to confirm.
Adaptive, risk-based sign-on policies	Conditional authentication through authenticator flows and custom SPIs	Gap. Risk signals and threat-based step-up are not replicated out of the box, so confirm what your policies require before cutover.
Okta API Access Management (custom authorization servers)	Client scopes, protocol mappers and token policies, or a dedicated server such as Ory Hydra	Needs rework. Map each custom scope and claim to Keycloak configuration and test machine-to-machine tokens separately.
Password policies and session settings	Realm password policies, brute force detection and session timeouts	Clean for baseline settings. Confirm lockout and reset behavior, and note that stored Okta password hashes are not part of the standard export.

What you can export from Okta and what you rebuild

Okta gives you a user list, not a full copy of your identity configuration. Plan the migration around what each export carries and what must be recreated in Keycloak by hand, script or review.

Okta Password Health report CSV

The Admin Console offers a CSV export of active users from the Password Health report. It is the simplest path for a one-time list of profile fields such as login, email and name. Confirm which attributes the file includes in your tenant before you map them to Keycloak user attributes, because custom profile fields may be missing or named differently. Treat the file as personal data and restrict where it is stored.

List Users API with a filter

The Okta List Users API, filtered by status, returns users in pages and is the option that scripts well for repeatable exports. Use an API token from a scoped admin account and record the export date, since users change status between runs. Pay attention to paging, rate limits and the fields returned for each user, and validate the output against a count taken from the Admin Console.

Community Rockstar extension

Okta's support article also names the community Rockstar browser extension as a way to export users. It runs in your browser against your admin session, so it suits small tenants and quick checks rather than audited migrations. Your security team should approve any third-party extension that handles directory data before anyone installs it.

Passwords and MFA enrollments

Exports carry profile data, not password hashes or enrolled authenticators. Plan for users to set a new password or re-enroll MFA in Keycloak, or to be sent a reset during cutover. Decide whether Keycloak will verify credentials against your directory through LDAP or Active Directory federation, which avoids a reset for users whose passwords live there. Confirm the approach with your security owner before the cutover window.

App assignments and group membership

User lists do not describe which applications each person can open or which groups grant access. Export group membership and app assignments separately, then rebuild them as Keycloak groups, roles and client scopes. Each SAML and OIDC application needs its own client, redirect URIs, signing certificates and attribute mappings, so inventory every app and its owner before rebuilding.

Realm export for configuration only

The kc.sh export command writes a Keycloak realm to JSON, which helps move clients, roles and settings between environments. Keycloak's documentation warns that this is limited as a backup and restore mechanism, and all nodes must be stopped while it runs. Use it for staging copies and configuration review, keep a separate database backup for recovery, and schedule the export in a maintenance window.

How the migration sequence runs from inventory to decommission

The sequence moves Okta workloads to Keycloak in controlled stages, so each app is proven on the new identity provider before Okta access is withdrawn. Every step ends with a written artifact that the next step depends on.

Inventory apps, users and assignments
Your team lists every Okta application, group, assignment and policy that affects sign-in, and records the protocol each app uses (SAML 2.0, OIDC, or a header or proxy pattern behind Okta Access Gateway). For the user list, use the Okta Password Health CSV, the Users API with a filter, or the community Rockstar extension, and confirm which export method your Okta edition allows. The output is an app register with owner, protocol, redirect URIs, attribute mappings and group membership for each app. The step is done when every app owner has signed off on their row.
Build a pilot realm with a few apps
DeployOpen or your platform team stands up a Keycloak realm in a non-production environment, with a database from Keycloak's supported list and the directory source you chose (Keycloak's own users, or LDAP or Active Directory federation). Pick two or three low-risk apps that cover both SAML 2.0 and OIDC, then re-federate them as clients using the attribute mappings from the app register. The output is a re-federation checklist per app, recording each claim, signing certificate, logout URL and test result. The pilot is done when a test user can sign in and out of each app through Keycloak.
Enroll credentials and MFA in the pilot
Decide how passwords and second factors move. Okta does not hand over password hashes as part of a routine export, so most teams plan for users to set new credentials at first sign-in, or use directory-backed passwords where the directory remains the source of truth. Map Okta's enrolled factors to Keycloak's OTP and WebAuthn options and communicate the enrollment steps to pilot users. The output is a written enrollment plan and a test log showing enrollment and recovery paths work. Confirm with your security and compliance owners which MFA methods they accept before enrollment starts.
Run both identity providers in parallel
Apps in the pilot and remaining apps are split into groups that stay on Okta and groups that move to Keycloak. During the parallel run, each application is assigned to exactly one identity provider at a time, so a user is never sent to both for the same app. Monitor sign-in success, MFA prompts, session length and help desk tickets in both systems. The output is a parallel-run log and a rollback plan for each group that names the Okta app assignment to restore and the owner who approves the switch.
Cut over applications in staged groups
Move each app group from Okta to Keycloak in a planned change window, starting with the lowest-risk group and ending with systems that have the most users or the strictest access rules. Before each cutover, take a Keycloak realm export as a restore point, noting the documented limits of export and import as a backup method, and stop all Keycloak nodes while the export runs. The output is a cutover record per group with the change time, test results, approvals and the verified rollback path. The group is done when its owners confirm sign-in and authorization work.
Verify logs and access before decommissioning Okta
Once every app is served by Keycloak, confirm that audit and sign-in logs in Keycloak capture the events your SIEM and compliance evidence need, and that access reviews reflect the new assignments. Remove leftover Okta app integrations and the Okta AD agent only after the directory source and access checks pass. Keep the last Okta export, configuration records and the rollback plan under your retention policy. The output is a signed decommission checklist showing that no app depends on Okta, that logs are retained and that the Okta tenant access has been withdrawn.

Replacing the Okta AD agent with Keycloak LDAP or Active Directory federation

The Okta AD agent pattern keeps Active Directory as the source of identity while Okta handles sign-on. Keycloak follows the same division of labor through its built-in user federation, which connects to an existing LDAP or Active Directory server and reads users from it at login. The directory stays authoritative for accounts, passwords and group membership, and Keycloak takes over the SSO role: issuing OIDC and SAML tokens to the applications that Okta used to front. Before cutover, decide which directory is the system of record, because a user that exists in both places with different attributes will produce confusing login behavior.

The Okta agent and Keycloak federation are configured differently, so do not assume a like-for-like copy of the Okta setup. In Keycloak, the user federation provider is defined inside the realm with its connection URL, bind credentials, search base and attribute mappings, and group sync is a separate mapper. Map each attribute that your SAML assertions or OIDC claims depend on, such as the login name, email and department, and confirm the exact directory attributes in your environment. Create a dedicated, read-only bind account for Keycloak and test that it can read the users and groups it needs without write permissions. Run a pilot realm with a small set of test accounts and compare the token claims against what Okta sent to each application.

Kerberos and FreeIPA are also options to evaluate, not defaults. FreeIPA can provide an LDAP directory with Kerberos and can create trusts with Active Directory, but whether your environment can use that arrangement depends on your domain design, DNS and existing trusts, so confirm this with your directory team before choosing it. Ask your identity team to document which directory holds each attribute, who owns the bind account and how group changes flow from the directory into Keycloak. Those answers determine whether the pilot is a valid test of the production design.

What drives migration cost and duration

This table lists the main drivers that move the cost and schedule of an Okta to Keycloak migration, why each one matters, and how to keep it manageable. Use it to shape a written scope, because most of the effort comes from the number and complexity of applications, claims and users rather than from Keycloak itself.

Driver	Why it changes cost or effort	How to keep it down
Application count and protocol mix	Each SAML or OIDC application needs its own client, metadata exchange, certificate handling and test login, so cost scales with the number of apps and the share of SAML.	Inventory every app in Okta first, group apps by protocol and vendor, and retire unused apps before migrating them.
Custom claims and mappers	Okta expression-based attributes and group claims must be recreated as Keycloak protocol mappers, and differences in token contents can break downstream apps.	Document each claim per application, reuse shared client scopes, and agree the expected token contents with each application owner.
Directory design	Whether users stay in Active Directory or LDAP with Keycloak federation, or move into Keycloak's own store, changes sync rules, attribute mapping and the work to retire the Okta AD agent.	Decide the source of truth before build starts, keep existing directory data where it already lives, and confirm attribute mapping with the directory team.
MFA and password re-enrollment volume	Okta does not export password hashes in a form you can assume to import, so users may need to set new passwords and enroll factors again, which drives help desk volume and rollout time.	Ask for a staged cutover by user group, enrollment guidance, and a plan for lost or unenrolled devices. Confirm with Okta what credential data, if any, can be exported.
High availability and database choice	Supported production databases include PostgreSQL 14 to 18 along with MariaDB, MySQL, SQL Server, Oracle and others. Multi-site designs need a synchronously replicated database and more testing of failover.	Pick a database your team already operates, such as PostgreSQL within the supported range, and limit HA design to the sites you truly need.
Operator or upgrade approach	Running Keycloak on the Operator with manual approval mode, or on hand-managed nodes, changes how upgrades, schema migrations and rollbacks are planned and staffed.	Use manual approval for operator updates, decide whether schema migration runs at startup or manually, and write the upgrade runbook during the build.
Testing depth	Login flows, token claims, logout, session timeouts, MFA steps and each downstream app must be tested in a staging realm before any user is moved.	Agree a test matrix per application in the written scope, include negative tests, and define who signs off each application.

How the move differs by size and starting point

A small estate usually has a handful of SAML and OIDC applications, a single user directory and few custom policies. The work is mostly re-creating each application integration in Keycloak and moving users in one controlled batch. Keycloak realms, clients and identity providers can be defined by hand in the admin console for a few apps, which keeps the project simple but leaves configuration that is hard to review later.

Application inventory: List every SAML and OIDC integration in Okta, including the redirect URIs, signing certificates and attribute mappings each one expects.
User export: Use the Admin Console Password Health report or the List Users API with a filter to get active users, then check which attributes are missing.
Password path: Okta does not hand over password hashes in a standard export, so plan for users to set new credentials or sign in through a federated source.
MFA re-enrollment: Decide which second factors users will re-register in Keycloak and communicate the enrollment window before cutover.
Configuration as code: Keep realm JSON exported with kc.sh export under version control, since the docs note the export is not a complete backup.

Confirm first: the exact list of applications, who owns each one, and whether any app depends on Okta-specific claims or group names.

What usually goes wrong and how to prevent it

Most Okta to Keycloak migrations stall on the same few issues: incomplete inventories, mismatched SAML and OIDC settings, and users locked out during re-enrollment. The cards below name each risk and the check that prevents it, so the cutover plan can be tested before any user depends on it.

Missed SAML signing certificates

Each SAML service provider holds a copy of the identity provider's signing certificate. When Keycloak replaces Okta, its realm generates new keys, so every relying party that still trusts the Okta certificate will reject assertions. Before cutover, export the metadata for each app from Keycloak, load it into the service provider, and confirm one sign-in per app in a staging tenant. Track certificate expiry dates in the same inventory.

Redirect URIs left unregistered

OIDC and SAML clients only complete sign-in when the callback URL matches a registered redirect URI or assertion consumer service URL exactly, including scheme, host, path and trailing slash. Apps that moved hostnames or added environments during the migration often break on the first login. Build the redirect URI list from each app's own configuration rather than from the Okta app tile, then test sign-out and callback paths as well as sign-in.

Attribute mapping gaps

Okta's attribute statements and claim mappings often carry values that applications read on every request, such as department, employee number or group membership. If Keycloak mappers emit different claim names or formats, apps may create duplicate accounts or lose roles after login. Document each app's expected claims, map them in Keycloak client scopes, and compare decoded tokens from both systems for the same test user before switching.

Lockouts during MFA re-enrollment

Okta does not export factor secrets or enrolled authenticators, so every user must re-enroll MFA in Keycloak after cutover. Users who lose a phone, or administrators who lack a recovery path, end up locked out of the realm. Plan a staged wave by group, keep a documented break-glass administrator with a tested second factor, and set a service desk procedure for identity verification before any reset is issued.

Incomplete application inventory

Applications that never appear in the Okta admin console, such as legacy apps behind a header proxy, scripts using API tokens, or apps federated through a secondary identity provider, are the ones most often forgotten. Build the inventory from sign-on logs, the app assignments of each group, and the owners who confirm each dependency. An app with no owner or no recent sign-in should be retired or scheduled, not assumed unused.

Untested Keycloak upgrades

Keycloak ships minor releases several times a year, and the Keycloak Operator documentation strongly recommends manual approval mode for operator updates. Upgrading production without rehearsal can change database schema, defaults or deprecated settings. Run the same version path in a staging environment with a copy of the database, use manual schema migration for large deployments, and keep a rollback plan tied to a verified database backup.

Backup gaps from realm export limits

Keycloak documents that realm export and import has limitations as a backup and restore mechanism, and that all nodes must be stopped while it runs. Relying on JSON exports alone can leave out user data and secrets, and it causes downtime. Back up the production database with its own tooling, store exports as configuration snapshots, and restore into a test environment at least once before go-live to confirm what comes back.

Questions buyers ask before moving from Okta to Keycloak

How much does it cost to move from Okta to Keycloak?

No single figure applies, because the cost depends on the scope you agree in writing. Keycloak itself is free under the Apache License 2.0, so the spend moves to components: the infrastructure to run Keycloak and its database in your own environment, a high availability design, the migration work, testing, and ongoing operations and patching. Okta's per-user suites and add-ons stop recurring, but your team or a partner carries the operating work. Ask any quote to break out one-time costs (design, migration, app re-federation, cutover) from recurring costs (hosting, database, patching, upgrades, support). DeployOpen does not publish a price list, and a quote follows from the written scope.

How long does an Okta to Keycloak migration take?

The duration depends on how many applications you federate, how many use SAML versus OIDC, how many directories sit behind the Okta AD agent, and how much change control your organization requires. Applications with custom claims, group-based access or legacy header authentication take longer than standard OIDC apps. A phased plan that moves a pilot group, then waves of applications, usually takes longer than a single cutover but reduces risk. No fixed timeline is safe to assume before an inventory of your Okta apps, policies and directories is complete. Ask for a timeline tied to that inventory, with dependencies and approval gates listed.

What does the client team need to provide for the migration?

The work needs decisions and access from your side more than it needs raw engineering hours. You will need an application inventory with owners, the SAML and OIDC settings each app uses, the group and attribute mappings in use, the Okta policies that gate access, and access to the Active Directory or LDAP sources that feed Okta. You also need someone who can approve identity changes, schedule cutovers and confirm that each application still works after re-federation. Plan for an owner in security, one in IT operations, and application owners for each system being moved.

Can our own IT team migrate from Okta to Keycloak without a partner?

Yes, a capable team can do this internally, provided it has experience with OIDC, SAML, LDAP and Kubernetes or container operations. The main questions to answer honestly are whether you can staff the operation after go-live, whether you can meet your own patching and backup standards, and whether you have time to re-test every application. Keycloak's high availability designs require a synchronously replicated database, and upgrades need a tested process, so those skills must exist in-house. A fixed-scope engagement can cover planning, implementation, hardening, backup and documentation, and ongoing support can be added as a retainer.

Do passwords and MFA move from Okta to Keycloak?

Usually not automatically. Okta does not hand over password hashes in a standard user list, so the answer depends on your user source. If users authenticate against Active Directory or LDAP, passwords stay in that directory and Keycloak federates to it. If identities live only in Okta, plan for password reset or re-enrollment, and confirm with Okta whether any hash export is available to your tenant. MFA enrollments are tied to the identity provider, so users usually re-register their authenticators in Keycloak, using OTP or WebAuthn. Plan a staged enrollment, a help desk script and a fallback path for users who lose devices.

Does Keycloak's Apache 2.0 license change the migration decision?

The Apache License 2.0 lets you use, modify and run Keycloak without a per-user license fee, and it does not require you to publish your own changes to the server. That affects cost and lock-in, but it does not remove the operating obligations. You still own hosting, security patching, upgrades and the custom themes or extensions you build. Confirm with your legal team how the license interacts with any Red Hat build of Keycloak subscription you might choose, since that is a separate supported product based on the open source project. Keycloak is also a Cloud Native Computing Foundation incubating project, which is a governance fact to note, not a support commitment.

What does a Keycloak support subscription change?

A support subscription changes who you call when something breaks and what is committed to in writing. Without one, your team relies on community channels and its own expertise. A commercial subscription, such as the Red Hat build of Keycloak, adds vendor support and a supported release stream, but it is a separate purchase with its own terms. It does not replace your operating responsibilities, and it does not remove the need for your own testing before upgrades. Ask any provider what response times, supported versions, patch cadence and support scope they commit to in writing, and whether those terms cover your database and operating system.

How do we keep Keycloak patched and upgraded after migration?

Keycloak publishes minor releases several times a year and major releases less often, and it states that breaking changes in a minor release are opt-in. You still need a routine: a staging environment, release notes review, automated tests against your key applications, and a rollback plan. Database schema migration runs automatically at startup by default, but larger deployments often apply it manually. If you run the Keycloak Operator on Kubernetes, the documentation strongly recommends manual approval mode for operator updates to avoid unplanned upgrades. Budget the recurring upgrade effort as an operating cost from day one.

Official sources for the Keycloak migration

Before you scope the move, read the Keycloak server administration guide and the Keycloak upgrading guide against the exact release you intend to run in production. The current release is 26.8.1, published October 13, 2026, so confirm that number on the Keycloak website and in the project's release notes before you pin a version. The administration guide covers realms, clients, user federation and identity brokering, which are the areas where a Okta tenant's configuration maps onto Keycloak. The upgrading guide tells you whether your planned version changes any default you depend on, such as how the database schema is migrated at startup or how it is applied manually for larger deployments.

Next, read the Keycloak documentation on importing and exporting realms before you decide how users move. The export and import commands write realm data as JSON, and the docs state that this process has limits as a backup and restore mechanism and that all nodes must be stopped while it runs. Plan the user cutover around that constraint, and confirm with your Keycloak support provider or in your own test environment exactly which user attributes and credentials the export includes. On the Okta side, check Okta's support article on exporting active users to confirm which of the three documented export methods your tenant can use, and what each one leaves out, such as group membership, application assignments and password state.

Finally, check the Keycloak Operator and high availability documentation if you plan to run Keycloak on Kubernetes or across sites, because the topology you choose determines the database and cluster layout you must size and test. Ask Okta for written confirmation of your contract's data export rights and any notice period before you start parallel running, since those terms, not the documentation, govern what you can take out. Keep a dated record of every source version you used, so the plan can be reviewed when Keycloak's minor releases change behavior.

How DeployOpen scopes, runs and supports the migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so a move from Okta to Keycloak runs in your cloud account, data center or network. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory every Okta application, SAML and OIDC integration, group rule and policy that the Keycloak realm must replace.
Agree which user sources stay authoritative: Okta, Active Directory, or an LDAP directory federated into Keycloak.
Define password and MFA re-enrollment approach, cutover waves and rollback conditions in the written scope.

How we build

Deploy Keycloak on your chosen database and high availability design, with the production configuration reviewed before go-live.
Re-federate each SAML and OIDC application to the new realm, testing claims, redirect URIs and logout behavior per application.
Replace the Okta AD agent pattern with Keycloak LDAP or Active Directory federation, and test group and attribute mapping.

How we hand over

Document the realm configuration, client inventory, federation settings and the export and backup procedure your team will run.
Provide a cutover runbook covering the user export, the re-enrollment communication and the rollback steps.
Train your administrators on the Keycloak admin console, metrics and upgrade process so operations stay with your team.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately in writing.
Plan minor and major Keycloak upgrades against the release notes and breaking change guidance before applying them.
Confirm your support boundaries, response expectations and who approves production changes before the engagement starts.

Migrate from Okta to Keycloak