What a Keycloak to authentik migration involves
A team running Keycloak realms and clients that wants authentik should plan this as a rebuild of each client as an authentik provider, followed by a staged user cutover, not as a database copy. The two products store configuration in different object models, so nothing carries over directly from a Keycloak realm export into authentik. Each client needs an authentik application and provider chosen for its protocol, its redirect and logout settings, and its claims or assertions, and each one is checked against the application it serves before users move.
Effort depends on four things: the number of clients and realms in use, the mix of OIDC, OAuth 2.0 and SAML clients, how user passwords will be handled, and how many applications must switch on the same day. A realm with a few OIDC clients and no federation is a small job. A realm that brokers several external identity providers, relies on Keycloak roles inside application logic, or has SAML clients that require signing certificates and attribute mappings is a larger one. Ask any partner to inventory each client's protocol, redirect URIs, mappers and token lifetimes before quoting, because those details set most of the work.
Before any work starts, confirm the exact Keycloak source version and the target authentik version in writing. Keycloak documents its own upgrade and backwards-compatibility rules in its backwards compatibility release notes, and authentik ships breaking changes per release, so the two version numbers determine which configuration fields and behaviors you are rebuilding against. Confirm both against your own environment and the vendors' current documentation rather than relying on a version recorded in a plan.
Which Keycloak objects map cleanly to authentik
This table compares Keycloak objects with their closest authentik counterparts and flags where the mapping is partial or absent. Read each row as a starting point for your inventory, then confirm the target behavior in the authentik documentation for the version you plan to run.
| Keycloak object | authentik counterpart | Mapping quality | What to confirm before cutover |
|---|---|---|---|
| Realm | No direct equivalent. Tenant scope is handled by separate instances, brands, flows and policies | Partial | Decide whether each realm becomes its own authentik instance or a set of applications, flows and groups, and check current brand and tenancy options for your version |
| OIDC client (confidential or public) | OAuth2/OIDC provider paired with an application | Close | Client type, redirect URIs, signing algorithm and token lifetimes must be re-entered and tested per application |
| SAML client | SAML provider paired with an application | Close | Entity ID, ACS URL, signing certificate and name ID format need to match what the service provider expects |
| Client scopes and protocol mappers | Property mappings attached to providers and scopes | Partial | Mapper types and claim names differ, so compare the token or assertion each application receives before and after |
| Identity brokering (external IdP) | Sources such as SAML or OAuth sources, or the Keycloak source for federating Keycloak during cutover | Partial | Source behavior on first login, attribute mapping and account linking depend on the source type you choose |
| User federation (LDAP or AD) | LDAP source for syncing users and groups from a directory | Partial | Confirm sync direction, attribute coverage and whether password checks still run against the directory |
| Realm roles | Groups used for authorization, with property mappings to emit them as claims | Partial | Roles are not identical to groups, so map each role to a group and verify that applications read the claim you emit |
| Client roles | Groups or application-specific mappings, depending on how the application reads them | Partial | Applications that check client roles in tokens need a claim shape they accept, which usually requires testing |
| Groups | Groups | Close | Nested group behavior and membership syncing should be checked against your Keycloak hierarchy |
| Authentication flows (browser, direct grant, first broker login) | Authentication, enrollment and recovery flows with stages and policies | Partial | Rebuild each required step, such as MFA or conditional access, as explicit stages and policies, then test each path |
Documented paths for moving data and configuration
authentik gives you four documented routes for getting Keycloak realms, clients and users into a new deployment. Each one moves a different part of the configuration, so most cutovers combine two or more. Check each card against your own realm export before you commit to a sequence.
Keycloak as a SAML source
authentik can federate Keycloak as a SAML source once the two systems have exchanged signing certificates. This lets users keep signing in through Keycloak while you move applications one at a time to authentik providers. It moves no users or clients, so it is a cutover bridge rather than a migration. Check which attributes Keycloak sends, because authentik maps only what the source releases, and confirm how long Keycloak stays in the login path before you retire it.
Blueprints for providers and applications
Blueprints declare authentik providers, applications, flows and mappings as YAML, which makes the rebuilt Keycloak clients reviewable and repeatable across environments. Each Keycloak client becomes an OAuth2/OIDC or SAML provider plus an application entry. Blueprints do not carry user accounts or password hashes, and client secrets and signing keys must be supplied from your secret store. Map Keycloak realm roles and client scopes to authentik groups and property mappings by hand.
API for creating objects
The authentik API creates users, groups, providers and applications programmatically, which suits bulk loads from a script that reads your Keycloak export. It is the path to use when the object count or ordering is too large for hand entry but blueprints are awkward for your pipeline. Scripts must handle idempotent reruns, dependency order between groups and providers, and the mapping of Keycloak required actions to authentik stages. Test on a staging instance first.
Pre-hashed password import
authentik 2026.5 can import pre-hashed Django-format passwords through blueprints and the user password-hash API. This lets users keep their existing passwords without a forced reset, but only if the Keycloak hash format can be expressed in the Django format authentik accepts. Keycloak stores hashes with its own algorithm and iteration settings, so confirm the format with a test account before planning the cutover around it. Hashes you cannot convert need a reset flow or a staged login through Keycloak.
Keycloak realm export as planning input
A Keycloak realm export lists clients, roles, groups, identity providers and authentication flows, which makes it the inventory for your migration plan. It is not a direct import into authentik, because the two products model realms, flows and roles differently. Use the export to decide which clients become OIDC or SAML providers, which realm roles become groups, and which custom authenticators need a rebuilt flow. Treat the export as sensitive, since it can contain secrets.
How the cutover runs in phases
The sequence moves Keycloak realms, clients and users into authentik one application at a time while both systems stay available, so each application has a tested path forward and a way back. Keycloak is retired only after every application has run on authentik for a period the owners have agreed in writing.
Inventory realms, clients and users
Export a list of every Keycloak realm, client (OIDC and SAML), client scope, identity provider, user federation link, and role or group that applications depend on. Record which applications use each client, which protocol they speak, the redirect URIs and signing certificates they hold, and who owns them. Your team and DeployOpen review the inventory with application owners. The step is done when every client has an owner, a protocol, a target authentik provider type and a cutover group assigned, and the user count per realm is confirmed against a fresh export.
Build a pilot authentik instance
Deploy a non-production authentik instance on a release that is still in the supported set listed in the security policy, using the deployment method your platform team already runs. Connect it to a dedicated PostgreSQL database, since authentik stores its configuration and data there, and confirm the worker container runs background tasks. Configure branding, the default flows and at least one administrator group. The step is done when a test user can sign in to the pilot and the upgrade path to the next supported release is documented.
Recreate the first providers and applications
Start with two or three low-risk applications from the inventory, one per protocol family you need. For each, create the matching authentik provider and application, map the Keycloak client scopes to authentik property mappings, and translate Keycloak roles into authentik groups. Test sign-in with a pilot group of users in the pilot instance, not in production. The step is done when each recreated application completes a full login, logout and token or assertion check that the application owner signs off.
Federate Keycloak as a SAML source
Connect Keycloak to authentik as a SAML source by exchanging signing certificates and metadata between the two systems, so users who still authenticate through Keycloak can reach migrated applications without a second password. Confirm which attributes Keycloak releases and map them onto the authentik user profile. Test that a user whose account exists in Keycloak can sign in to a migrated application and that the account is linked, not duplicated. The step is done when linked sign-in works for the pilot group and duplicate-account checks return no results.
Run both systems in parallel
Keep Keycloak serving the applications that have not moved, and let authentik serve the migrated set. Users move between the two through the federated source, so they experience one sign-in path per application. Monitor failed logins, token errors and session behavior on both systems, and track which users have signed in to authentik. Add applications in batches only after the previous batch has run without open defects. The step is done when the application owners agree the parallel state is stable and each remaining client has a scheduled cutover window.
Cut over each application with a rollback path
For each remaining application, repoint its redirect URIs, metadata or client configuration to authentik during an agreed window, and keep its Keycloak client disabled but not deleted until the rollback window closes. Record the exact configuration changes so they can be reversed. If sign-in fails and cannot be fixed within the window, revert the application's configuration to Keycloak. The step is done when the application's sign-in, logout and role-based access checks pass in production and the owner confirms the cutover in writing.
Decommission Keycloak after a verified period
Once every application has run on authentik through an agreed verification period, remove the Keycloak federation, export a final copy of realm configuration and audit records for retention, and stop Keycloak services. Confirm that no application, script or integration still points at Keycloak endpoints, and check that backups of its database follow your retention rules before deletion. The step is done when Keycloak endpoints return no traffic in monitoring, the final export is stored under your retention policy, and the decommission is recorded in your change system.
Moving users and password options without forced resets
There are three ways to move Keycloak users into authentik, and the choice is made per user population, not once for the whole migration. The first is federation through a SAML source: authentik can federate Keycloak as a SAML source after the two systems exchange signing certificates, so users keep signing in against Keycloak until their account is moved. Nothing about their credentials changes during this period, which makes it the safest default while applications are cut over. The second is importing pre-hashed passwords. authentik 2026.5 can import Django-format password hashes through blueprints and the user password-hash API, so users whose Keycloak hashes can be converted to a supported format can sign in to authentik with their existing password. The third is requiring a reset for any population whose hashes cannot be converted, and for which federation is not a practical long-term fit.
Which path applies depends on what Keycloak actually stores. Hash format conversion is a discovery task, not an assumption: export a representative sample of users and confirm the algorithm, iteration count and salt format for each stored credential type in your Keycloak realm, then test one import in a non-production authentik instance and confirm the user can sign in. Do not assume that every realm uses the same hashing policy, especially if the realm has been upgraded over several Keycloak releases or if some users were created through user federation rather than local storage. Users whose credentials are held by an external directory are not covered by a Keycloak password hash at all, and their handling should be decided with the directory owner.
MFA enrollments are a separate decision and should not be carried over by default. Password hashes move, but OTP and WebAuthn enrollments in Keycloak are tied to that realm's configuration, and authentik enrolls second factors through its own stages and flows. Decide which users must re-enroll, whether a grace period applies, and how recovery works for users who lose a device. Record each decision per population so that the password path and the MFA path are reviewed together before the cutover date is set.
Questions buyers ask before a Keycloak migration
Can our team migrate from Keycloak to authentik without a partner?
Yes, if you have people who know both systems and time to rebuild each client as a provider. The work is mostly repetitive: every OIDC and SAML client is recreated, tested and cut over, and every role becomes a group or policy. Teams without prior authentik experience usually spend the first weeks learning providers, flows and property mappings, so the question is less about capability and more about available hours and the risk of cutting over a client that nobody on the team owns. A partner is useful when you want a fixed scope, a written cutover plan and someone accountable for the parallel run. DeployOpen plans, implements and documents this work in your own infrastructure under a written scope.
What drives the effort of a Keycloak to authentik migration?
The main drivers are the number of realms, clients and protocol mappers, how many applications have custom claims or SAML attribute mappings, and how much of your role model depends on realm roles, client roles and composite roles. Other factors are user volume, whether password hashes can be carried over, the number of applications that cannot be changed quickly, and how many user federation links to LDAP or Active Directory exist. Each client that needs a new redirect URI or a changed signing certificate adds coordination with its owner. Ask for a client inventory before any quote, because it turns these drivers into a countable list.
Does authentik have a direct importer for Keycloak realms?
Based on the documented paths we can confirm, authentik does not document a one-step importer that moves a Keycloak realm, its clients and its roles into authentik. The documented route for the cutover period is to federate Keycloak as a SAML source in authentik after the two sides exchange signing certificates, so users can sign in through authentik while applications move. Clients are then recreated as authentik providers and applications. Confirm the current import options in the authentik documentation for your version before you plan the work, because the supported paths change between releases.
How long should a parallel run between Keycloak and authentik last?
The length depends on how many applications you must move, how many users still sign in through Keycloak, and how quickly each application owner can test. A parallel run is usually sized around the slowest application owner, not the fastest technical step, so plan for a window that covers testing, a rollback path and at least one full business cycle for the most sensitive systems. Set a cutover date per application, keep Keycloak running and reachable until the last application has moved, and agree on the exit criteria in writing. Ask any partner to state the window and the criteria in the written scope.
What must our team provide before a migration starts?
You need to provide a complete client inventory from each Keycloak realm, with protocol, redirect URIs, signing settings, mapped attributes and whether the client uses roles or groups. You also need a named owner for every application who can test sign-in, approve the cutover and confirm the rollback plan. Other inputs include access to the Keycloak admin console or exports, the current role and group model, a list of user federation links, the target infrastructure and database, and a decision on password handling. Without these inputs, scope and schedule cannot be fixed, and unknown clients tend to surface during cutover.
What do authentik's license terms mean for the features we choose?
The core of authentik is released under the MIT license, but code in the authentik/enterprise/ directory is under a separate enterprise license. The pricing page lists Enterprise-only features that are priced separately from the open source edition, and these include Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, password history and enhanced audit logging. Enterprise is listed at $5 per user per month billed annually plus $0.02 per external user per month, according to the authentik pricing page. Before you design the target, check each Keycloak feature you rely on against the pricing page and the license, because a feature you need may fall into the Enterprise tier.
Can we move user passwords from Keycloak without forcing resets?
It may be possible, but only for hash formats that authentik can accept. authentik 2026.5 can import pre-hashed Django-format passwords through blueprints and the user password-hash API. Keycloak stores password hashes in its own format, so you must confirm which algorithm and parameters your realm uses and whether a conversion is needed before import. If hashes cannot be carried over, the usual options are a forced reset at first sign-in or a federated period during which Keycloak still validates the password. Ask the team doing the work to confirm the hash format and test one account end to end before committing to a password strategy.
What drives the cost and duration of the move
This table lists the factors that change the effort of moving from Keycloak to authentik, whether each cost is one-time or recurring, and what to request in a quote. Use it to compare the scope of each driver against your own realm, client and directory inventory before you ask for a fixed-scope proposal.
| Driver | Why it changes effort | One-time or recurring | What to request in a quote |
|---|---|---|---|
| Number of realms and clients | Each realm needs its own provider, application, flow and group design, and each client needs a matching authentik provider and application. | One-time | Per-realm and per-client breakdown with a named owner for each. |
| Protocol mix (OIDC versus SAML) | OIDC clients map to authentik OAuth2/OIDC providers, while SAML clients need entity IDs, certificates and attribute statements rebuilt and tested. | One-time | Separate estimate lines for OIDC and SAML clients, with test steps for each. |
| Custom protocol mappers and client scopes | Keycloak mappers must be rebuilt as authentik property mappings, and any custom claim logic needs review against each application. | One-time | Inventory of mappers and scopes, plus which claims each application consumes. |
| Role-to-group redesign | Keycloak realm and client roles do not carry over as-is, so group structure and application bindings need a deliberate redesign. | One-time, with ongoing group administration | Proposed group model, who approves changes, and how group membership is reviewed. |
| Password hash formats | Importing existing hashes depends on the format Keycloak stored, and unsupported formats force resets or conversion work. | One-time | Confirmation of hash algorithms in use and the import method for each. |
| MFA re-enrollment | Users may need to register authenticators again, which affects helpdesk load and the cutover communication plan. | One-time, with recurring helpdesk demand | Plan for enrollment flows, reminder schedule and recovery procedure. |
| Hard-coded Keycloak endpoints | Applications that point at Keycloak issuer, token or logout URLs need configuration changes or code changes before cutover. | One-time | List of applications with endpoint changes and who makes each change. |
| Directory and user federation | Connections to LDAP, Active Directory or other stores change how users are sourced, synced and attributed in authentik. | One-time setup, recurring sync operations | Directory sources, sync schedule, attribute mapping and failure handling. |
| Target hosting model | Docker Compose, Kubernetes with a separately managed PostgreSQL, and high availability designs each carry different build and run work. | One-time build, recurring operations | Hosting design, database ownership, backup scope and who runs day-two tasks. |
| Keycloak source during cutover | Federating Keycloak as a SAML source requires exchanging signing certificates and testing login paths while both systems run. | One-time, plus temporary run cost until retirement | Length of coexistence period, certificate exchange steps and retirement criteria. |
What usually goes wrong in a Keycloak to authentik move
Most failed cutovers trace back to a handful of issues: identifiers that change when clients move, access models that do not map cleanly, and parallel systems that drift apart. Each card below names one risk and the check that prevents it. Review them before the first user is moved.
Redirect URI and issuer mismatches
Every application registered in Keycloak holds exact redirect URIs and expects tokens from a specific issuer URL. When authentik creates its own provider and application, the issuer, client ID and callback paths often differ, so sign-in fails with an invalid redirect or a token rejected for the wrong issuer. Build a table that maps each Keycloak client to its authentik provider, including the issuer and discovery URL, and test each application's callback in staging before DNS or client configuration changes go live. Keep the Keycloak client registered until every application has signed in successfully.
Roles flattened into groups incorrectly
Keycloak separates realm roles, client roles and composite roles, and applications often read them from token claims. authentik models access through groups, policies and property mappings, so a direct role-to-group copy can grant too much access, drop nested grants or lose the client scope that separated one application's roles from another's. Inventory every role and composite role, then decide per application which group and claim carry the same meaning. Compare the claims each application receives from both systems for a test account with each role combination before cutover.
Lockouts after a password hash import
Keycloak stores password hashes in its own credential format, and authentik can import only certain pre-hashed Django-format passwords. If the hash type is not converted correctly, users cannot sign in on the first day and may assume the account is compromised. Before importing, confirm the hash algorithm and iteration settings for a sample of accounts, run the import against a copy of the data, and sign in with a test user from each hash type. Keep a documented reset path so support staff can recover accounts without a manual project change.
Sessions diverging during parallel run
While some applications still sign in through Keycloak and others through authentik, a user can be logged in to one system and logged out of the other. Logout in one system may not end the session in the other, and a changed password or disabled account can take effect in only one place. Decide which system is the authoritative source for each user attribute during the parallel period, define which applications stay on which system, and test single logout and account disablement across both systems. Limit the parallel window in the plan so the divergence risk does not last longer than the cutover needs.
SAML signing certificate expiry
Federating Keycloak as a SAML source requires exchanging signing certificates between the two systems. When a certificate expires or is rotated on one side without updating the other, every federated sign-in fails at once, and the failure can look like an outage in authentik. Record the certificate expiry dates and owners, add the rotation to the change calendar, and test a rotation in staging before the production federation runs. Confirm which metadata or certificate fields the federation requires before the build starts.
Unplanned Keycloak upgrade mid-project
Keycloak ships minor releases several times a year, and a platform upgrade during the migration changes the systems being moved and the behavior being tested. Before the project starts, pin the current Keycloak version, decide who approves any upgrade, and check the upgrade and backwards compatibility notes for breaking changes. If an operator manages Keycloak, set updates to manual approval so a release does not install during the cutover window. Re-export realms and clients after any upgrade so the mapping table reflects the running version.
What the target authentik deployment needs before migration
Before any Keycloak realm is recreated, the target authentik deployment needs a settled architecture, because the components you size, back up and upgrade are different from Keycloak's. An authentik deployment has a server container that runs the core application with an embedded outpost, a worker container that handles background tasks, and PostgreSQL, which stores all configuration and data except uploaded files. Keycloak's clustering and cache decisions do not carry over, so plan the authentik topology from scratch and confirm it against the authentik architecture documentation before you provision hosts.
The Docker Compose guide lists a minimum of 2 CPU cores and 2 GB of RAM and positions Compose for test setups and small-scale production, so treat that as a floor rather than a sizing answer for a migrated user base. The Kubernetes guide's Helm chart bundles a PostgreSQL intended for demonstration and test use, and recommends a separately managed PostgreSQL for production. Decide early who owns that database, its backups and its high availability, since the migration writes all of your realms, users and clients into it. Also note that the 2025.10 release removed Redis and moved caching, tasks, sessions and WebSocket functions into PostgreSQL, and warned of roughly 50% more PostgreSQL connections after upgrading. Size your connection limits and any pooler against that, and confirm the figures for your chosen release in the release notes.
Finally, check the supported versions in the authentik security policy before you pick a target release. The policy lists the release lines that receive security fixes, and the project announces security releases at least 24 hours in advance, so choose a line you can keep current. Record the target version in your migration plan, confirm that your deployment method and PostgreSQL version support it, and agree who will watch for security notices during the cutover window.
