Migrate from Auth0 to Keycloak: what the move involves
Moving from Auth0 to Keycloak is a realm rebuild plus user and credential migration, not a file copy. Auth0 tenant settings, connections, Actions and application registrations do not transfer as they are. The usual trigger is a renewal where monthly active user pricing has grown, a data residency requirement, or a wish to stop depending on one vendor's login flows. The work is typically done by platform or security engineers working with the owners of each application, because every client that signs in through Auth0 must be re-pointed at Keycloak's OpenID Connect endpoints. Plan for the first realm to be a pilot, then repeat the pattern for the rest.
Users are the part that needs the most planning. Auth0's bulk export job, run from the Dashboard or the Management API, produces NDJSON or CSV files, but standard exports do not include password hashes. Paid plans can request a hash export through a support ticket, Auth0 does not guarantee a delivery date, and the option is not available on the Free tier. Confirm this with Auth0 early, because without hashes users must reset passwords or be migrated through a just-in-time approach at first login. Keycloak imports realm data as JSON through kc.sh import, and the import mechanism is not a backup tool, so treat it as a one-time load into a freshly built realm and verify user counts and login before cutover. Also confirm which hash algorithms the exported data uses so Keycloak can verify them.
Connections and logic take the most engineering time. Each Auth0 social or enterprise connection is recreated as an identity provider in the Keycloak realm, and each Action or Rule must be rewritten as Keycloak authentication flow steps, protocol mappers or custom code that you own and test. Application SDKs switch to standard OIDC settings, so expect changes to issuer URLs, client IDs and token claims. Keep a short inventory of every Auth0 tenant setting and mapping it to a Keycloak equivalent, then run a parallel test with a pilot application. Ask the team that will run Keycloak to confirm its patching, backup and high availability plan before go-live, since the realm moves do not cover those operating duties.
Which Auth0 capabilities map cleanly to Keycloak
This table maps each Auth0 construct to its Keycloak equivalent and marks it clean, needs rework or gap. Read the status column first, then the notes, to see which parts of your tenant move as configuration and which need engineering time. Most of the work sits in Actions and Rules logic and in confirming how Organizations and MFA behave in the Keycloak version you deploy.
| Auth0 capability | Keycloak equivalent | Status and notes |
|---|---|---|
| Tenant | Realm | Needs rework. Keycloak realms are the isolation boundary, so one Auth0 tenant usually becomes one realm, and each environment is recreated separately. |
| Applications | OIDC clients | Needs rework. Redirect URIs, allowed origins, grant types and token lifetimes must be re-entered. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0 clients. |
| Users and metadata | Users, attributes and imported password hashes | Needs rework. Standard exports carry profile data, but password hashes need a separate Auth0 support request on paid plans. Confirm hash format compatibility before cutover. |
| Database connections | User federation or imported user store | Needs rework. Keycloak has built-in user federation with LDAP and Active Directory servers. Custom Auth0 database scripts must be ported by hand. |
| Social connections | Identity providers (brokering) | Clean. Keycloak identity brokering covers common social providers, but each client ID, secret and callback URL must be recreated and retested. |
| Enterprise connections (SAML, OIDC, AD) | Identity providers and LDAP or AD federation | Clean for SAML 2.0, OIDC and LDAP or AD. Attribute and group mappers must be rebuilt for each customer connection. |
| Actions and Rules | Authentication flows and custom code | Gap. Keycloak has no direct equivalent. Pre-login, post-login and token logic must be ported by hand into flows, SPIs or custom providers. |
| Organizations | Keycloak Organizations feature | Needs rework. Confirm the current Organizations model, per-organization identity providers and domain handling in the current Keycloak docs before design. |
| MFA and passwordless | Built-in OTP, WebAuthn and passkey support | Needs rework. Confirm which factors and enrollment flows your version supports, and rebuild enrollment policies. |
| Branding and email templates | Login themes and email templates | Needs rework. Themes are rebuilt in FreeMarker and templates are re-authored. Plan design and testing time for every login screen. |
What data moves out of Auth0 and what must be rebuilt
Auth0 hands over user records through a bulk export, but password hashes, clients, connections and custom logic follow different paths. Each item below needs its own decision and owner before the Keycloak realm goes live. Confirm the export scope with Auth0 early, because the password hash request has no fixed delivery date.
Bulk user export job
The Dashboard or the Management API create export users job (POST /jobs/users-exports) produces a file of user profiles in NDJSON or CSV. Use this file to build the Keycloak user import, and map Auth0 user fields and custom metadata to Keycloak attributes before you run it. Check whether the export includes the identity provider links and metadata your applications depend on, and test the import in a non-production realm first.
Password hashes need a support ticket
Standard exports do not include password hashes. Paid-plan customers must request the hash export through a support ticket, and Auth0 does not guarantee a delivery date, so start this request early in the project. Without hashes, every user must reset a password after cutover, so plan that communication and the reset flow before the switch. Confirm the format and hashing algorithm of the delivered hashes before you design the import.
Free tier has no hash path
The option to request password hashes is not available on the Free tier. If your tenant is on the Free plan, your users cannot keep their passwords through a hash import, and you must plan a forced reset or a staged login migration instead. Confirm your current plan and entitlements with Auth0 before you commit to a password strategy, since an upgrade may be needed to obtain hashes.
Clients and redirect URIs
Auth0 applications, their allowed callback, logout and web origin URLs, and token settings are not part of the user export. Recreate each one as a Keycloak client with exact redirect URIs, and decide which clients need confidential or public settings. Keep a written inventory of every application, including staging and local development URLs, so no login path breaks at cutover.
Connections and custom database scripts
Social and enterprise connections, along with any custom database connection scripts that validate or transform users, must be recreated as Keycloak identity providers or user federation. Each external provider needs its own client registration, callback URL and attribute mapping. Custom database scripts do not port directly, so review each one for the logic it performs and rebuild that logic in a Keycloak user storage provider or mapper.
Actions, hooks and tenant settings
Auth0 Actions and legacy Rules or Hooks run custom code during login and token issuance, and tenant settings control branding, MFA policy, session lifetimes and password policies. None of this moves with the user export. Document what each Action changes in the token, then rebuild it as a Keycloak authentication flow, protocol mapper or realm setting, and test each change against the claims your applications read.
Realm JSON and the Operator
Keycloak imports realms from JSON, and the Keycloak Operator can apply that file through the KeycloakRealmImport custom resource. Use this path to version the realm configuration in Git, so clients, identity providers and flows are reviewed like code. Note that the export and import commands are limited as a backup mechanism, so keep your user data backup process separate.
How password hashes decide whether users keep their passwords
Users keep their passwords only if Auth0's password hash export arrives and Keycloak can verify the hash format. Standard Auth0 user exports leave password hashes out, so the export you run for user profiles will not carry credentials. On paid plans, you request the hash export through an Auth0 support ticket, and Auth0 does not guarantee a delivery date. The option is not available on the Free tier. If the hashes do not arrive, or Keycloak cannot verify them, the fallback is either a forced password reset for every user or a custom user storage provider that checks the old credential on first login and then migrates it. Both paths change the user experience, so decide which one you accept before you set a cutover date.
Request the hash export as early as your project plan allows, because the delivery timing is outside your control. In the same ticket or a separate question to Auth0 support, confirm which hash algorithm and parameters your tenant uses, and ask whether the export includes every connection type you have, including database connections and any users who signed up through social logins without a local password. Record the answers in your migration runbook. Keycloak's password policy and hashing settings are per realm, so the realm you import into must be able to handle the algorithm you are given, and you should check that against the Keycloak documentation for the version you deploy.
Test before you commit. Import a sample of exported users, including a few with hashes and a few without, into a non-production realm, then sign in with known test passwords through the same OIDC client configuration that production will use. Confirm that a successful login works, that a wrong password fails, and that a user without a hash is routed to the reset or migration path you chose. Only after these checks pass should you fix a cutover date. Illustrative example: if the sample login fails for one algorithm, you learn this during testing rather than after your users have been moved, and you can still choose the reset or migration fallback on your own schedule.
The migration sequence from inventory to decommission
The sequence moves Auth0 tenant configuration and users into Keycloak realms one application at a time, with a parallel run and a retained export archive so each stage can be checked and reversed if needed. Each step ends with a named output that gates the next one.
Inventory applications, connections, Actions and users
Start by listing every Auth0 application (client), its grant types and callback URLs, every social and enterprise connection, every Action and legacy Rule, and every custom database connection that holds users. Record the user count and which users sign in with a password, because those users depend on the hash export. The output is an inventory register with one row per item, an owner for each application, and a note on which items have no Keycloak equivalent and need a design decision. The step is done when the application owners have signed off the register.
Request the password hash export early
Auth0 does not include password hashes in standard user exports, and on paid plans the hashes come through a support ticket with no guaranteed delivery date. Open that ticket as soon as the inventory shows password-based users, and confirm with Auth0 which hash format is provided and whether your plan qualifies, since the option is not available on the Free tier. The output is a confirmed delivery of the hash file, or a documented decision that affected users will reset passwords. Keycloak can then import those hashes, which you should test in the pilot before relying on them.
Build and test a pilot realm with one application
Export users with the bulk export job, then create a dedicated Keycloak realm for the pilot and import the users and the hash file with the realm import tooling. Recreate one application as a client, one identity provider and the required mappers, and point a test copy of that application at the realm. Keycloak realms are exported and imported as JSON, so keep the pilot realm definition in version control and test a full export and re-import on a non-production node. The output is a tested realm export, a short test log showing that a password login, a social login and a token claim check passed, and a list of gaps found.
Port Actions and Rules logic to Keycloak flows
Translate each Auth0 Action or Rule into a Keycloak mechanism: an authentication flow step, a protocol mapper, a required action or a custom provider where none of the built-in options fit. Auth0 Actions run custom code, so review each one for behavior that depends on Auth0-specific APIs, and rewrite those parts rather than copying them. The output is a mapping table from each Auth0 Action to its Keycloak equivalent, with the owner and test result for each row. Confirm each mapping against the token contents your applications expect before the parallel run starts.
Run Auth0 and Keycloak in parallel
Switch the pilot application's SDK to standard OpenID Connect against the Keycloak realm, while the other applications keep using Auth0. During this period, define one system of record for user writes: either Auth0 stays authoritative for profile and password changes and changes are synced to Keycloak, or the reverse, but not both. Document which system handles password resets, account deletion and MFA enrollment, and monitor sign-in failures in both systems. The output is a parallel-run log that records the sign-in success rate, the open defects and an agreed ownership table for user writes.
Cut over with DNS, client configuration and issuer changes
For each remaining application, change the OIDC issuer URL from the Auth0 tenant to the Keycloak realm, update the client ID and secret, and update any callback URLs, logout URLs and allowed origins. Where applications or APIs validate tokens against a hardcoded issuer, update that setting too, because tokens from the new issuer will not validate against the old one. If you use a custom domain for login, change the DNS record in the same window and keep the previous record available for rollback. The output is a signed-off cutover checklist with one line per application, the rollback steps and the named person who approved each change.
Retain an export archive and make Auth0 read-only
After every application has been running on Keycloak through an agreed period, export the final Auth0 user and configuration state and store it in an encrypted archive that your retention policy covers. Then set the Auth0 tenant to a read-only operating period in which no new logins are expected, and watch for traffic that still reaches it. Confirm with your compliance owner which logs and records must be kept, and where. The output is a retained, checksummed export archive and a dated decommission record. Cancel the Auth0 subscription only after that record is approved, and confirm the terms and data deletion process with Auth0 in writing.
How the move differs by tenant size and starting point
A consumer tenant with a single database connection is usually the shortest path. The user store is one collection, so the bulk user export becomes one import into a Keycloak realm, and the main decisions concern the realm settings, client registrations and how the login pages look. Password hashes are the item to settle early, because they decide whether users keep their current passwords or must reset them.
- Export first: Run the bulk user export job and confirm which fields arrive in NDJSON or CSV before designing the realm.
- Request hashes early: Ask Auth0 by support ticket for the password hash export on a paid plan, since delivery is not guaranteed on a fixed date.
- Rebuild the realm once: Recreate client registrations, redirect URIs, password policy and token lifetimes in a single realm, then export it as JSON for review.
- Switch SDKs to standard OIDC: Point each application at the Keycloak issuer URL and test login, logout and token refresh on every client.
- Plan a cutover window: Decide whether sessions are invalidated, and confirm how users with no imported hash will reset their passwords.
Before committing, confirm with your team which hash format your Auth0 export contains and whether Keycloak can verify it without forcing resets.
A B2B tenant that uses Auth0 Organizations gives each customer its own members, roles and enterprise login. Here the work is less about moving users and more about modeling the customer structure in Keycloak, which has its own Organizations feature for per-customer identity providers and domains. Each enterprise connection must be recreated as an identity provider and tested against the customer's own identity system.
- Map customers first: List every Organization, its members, its roles and its domains, then decide how each maps to a Keycloak organization or realm.
- Recreate enterprise connections one by one: Rebuild each SAML or OIDC connection as an identity provider and test it with a pilot customer before wider use.
- Check token claims: Organization context and role claims may change shape, so compare tokens from Auth0 and Keycloak for the same user.
- Coordinate with customers: Some enterprise IdP administrators must update their own application registrations, which adds lead time outside your control.
- Test isolation: Confirm that one customer's users cannot see another customer's members or connections.
Ask your team how many Organizations and enterprise connections exist, since each one adds coordination work that is not visible in the user count.
A tenant with heavy Actions or custom database connection scripts carries logic that is not in any export file. Auth0 Actions run in a managed runtime during login and can enrich tokens, call external services or block access. Keycloak has no direct copy of that runtime, so each behavior must be reimplemented as a Keycloak authenticator, protocol mapper, event listener or code in a custom extension, and then tested. Custom database scripts that validate passwords or fetch users from an external store follow the same pattern, usually through user federation or a custom provider.
- Inventory every Action: List each trigger (login, post-login, credentials exchange, pre-user-registration) and what it reads or writes.
- Classify the logic: Separate token claim enrichment, access decisions, external calls and user data changes, because each maps to a different Keycloak mechanism.
- Reimplement with the right extension point: Use protocol mappers for claims and custom authenticators or providers for login logic, and keep secrets out of realm JSON.
- Test with production-like data: Replay representative logins and compare results, including failure paths.
- Budget for skilled Java work: Custom Keycloak extensions are Java code that your team or a partner must build, upgrade and patch with each Keycloak release.
Ask for a written inventory of Actions and scripts before estimating, because this inventory decides most of the effort in this shape.
Most teams run more than one Auth0 tenant or Keycloak environment, for example development, staging and production. The rollout order matters because realm JSON export and import are not a full backup and restore mechanism, and the Keycloak documentation says all nodes must be stopped while the export or import runs. Planning environments in sequence keeps production changes small and lets each step be repeated.
- Build configuration as code: Keep realm definitions in version control and apply them to each environment the same way.
- Stop nodes for realm export: Plan a maintenance window whenever you export or import realms on a running cluster.
- Promote through staging: Move clients, identity providers and flows from development to staging before production, and repeat the test set each time.
- Keep the Auth0 tenant running: Leave the old tenant available until rollback is no longer needed, and record which applications still point to it.
- Plan for upgrades: Pin the Keycloak version per environment and agree on a patch schedule, since the operator documentation recommends manual approval for updates.
Before scheduling, confirm your maintenance windows and whether the Keycloak deployment will run as a single node or in a high availability design.
What running Keycloak after the move requires
Start with the database, because every other production decision depends on it. Keycloak supports MariaDB, Microsoft SQL Server, MySQL, Oracle Database, PostgreSQL (14 to 18), EnterpriseDB Advanced, Amazon Aurora PostgreSQL and Azure SQL, and the default dev-file database is for development only. Pick the engine your team can back up, patch and restore, and confirm its version against the supported range before you import a single user. For high availability, Keycloak documents three architectures: a single cluster optionally spread across availability zones, multi-cluster deployments (v2) without external Infinispan, and the deprecated multi-cluster v1. Both supported designs need a synchronously replicated database, so a database replica that lags behind the primary is not an acceptable foundation for login.
Plan how Keycloak gets upgraded before it goes live. The Keycloak Operator, installed through Operator Lifecycle Manager, manages Keycloak and KeycloakRealmImport resources, and its documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades. Keycloak has moved to four minor releases a year and a major release every two to three years, and since Keycloak 26.0 breaking changes in a minor release are opt-in. Read the release notes for each minor version, test your realm configuration and custom providers in a staging cluster, and schedule upgrades as a recurring task with an owner. Confirm the upgrade cadence and support terms for your chosen distribution, including whether you use the community release or the Red Hat build of Keycloak.
Decide how schema changes are applied. By default Keycloak migrates its database schema automatically at startup. The upgrading guide suggests manual migration, where administrators apply the SQL themselves, for large deployments, which gives a database team review and a rollback window. Also treat realm export and import as configuration transfer, not backup. The kc.sh export and kc.sh import commands require all nodes to be stopped while they run, and the documentation warns of limitations as a backup and restore mechanism. Build a database backup and restore procedure, rehearse it, and keep realm exports only as a configuration snapshot.
What drives the cost and duration of the migration
This table lists the main drivers of Auth0 to Keycloak migration effort, why each one moves cost or schedule, and how to keep it manageable. Use it to see which factors your environment has and which questions to put in a written scope before comparing quotes.
| Driver | Why it changes cost or effort | How to keep it down | Ask for in the written scope and quote |
|---|---|---|---|
| Number of applications and SDK changes | Each Auth0 SDK integration (SPA, mobile, server, API) must move to standard OIDC clients in a Keycloak realm, with its own redirect URIs, scopes and token claims tested. | Group applications by login pattern, migrate one pilot app first, and reuse a common OIDC configuration template across similar apps. | A list of every application, its SDK and flow type, and the testing a cutover of each one requires. |
| Password hash availability | Standard Auth0 user exports omit password hashes. Paid-plan customers must request hash exports by support ticket, and Auth0 does not guarantee a delivery date, so without hashes users may need password resets. | Open the support request early, confirm your plan tier qualifies, and plan a reset or staged login path as a fallback. | Whether the scope covers hash import into Keycloak, how a reset flow is handled if hashes do not arrive, and who owns the support request. |
| Number of enterprise and social connections | Each social or enterprise connection must be rebuilt as a Keycloak identity provider with its own metadata, claim mappings, attribute handling and first-login behavior. | Inventory connections, retire unused ones, and standardize claim mapping rules across providers of the same type. | A count of identity providers by type, the SAML or OIDC metadata each one needs, and test accounts for each provider. |
| Volume of Actions and Rules logic | Auth0 Actions and Rules run custom code during login. Each hook must be rewritten as Keycloak authenticators, mappers or custom providers, which adds development and review time. | Catalog every hook by purpose (claims, enrichment, blocking, notifications), drop logic that is no longer needed, and move simple claim changes into protocol mappers. | A hook-by-hook inventory, the target Keycloak mechanism for each, and whether custom Java or SPI code is included in the fixed scope. |
| Need for high availability | A production Keycloak cluster needs a supported database such as PostgreSQL with synchronous replication, multiple nodes and load balancing, plus monitoring. Each design adds infrastructure and operations work. | Size the deployment for actual login peaks, choose the simplest supported high availability design that meets your recovery targets, and automate builds and upgrades. | The high availability design chosen, the database and infrastructure owner, and whether metrics, backups and upgrade runbooks are in scope. |
| Export and import handling for users and realms | Keycloak realm export and import through kc.sh requires all nodes to be stopped during the operation. Bulk user import must be validated against counts, attributes and duplicate handling before cutover. | Plan a maintenance window for realm import, run rehearsal imports in a non-production environment, and reconcile user counts after each run. | The rehearsal plan, reconciliation checks, and the maintenance window the migration plan assumes. |
| Testing depth | Login flows, MFA, token claims, logout, session lifetimes and failure paths must be tested for each application and identity provider, including users who sign in with social or enterprise accounts. | Write a test matrix from the application and connection inventories, automate login regression checks, and run a limited user pilot before full cutover. | The test matrix, the environments used, who performs user acceptance testing, and the rollback criteria agreed in writing. |
What usually goes wrong and how to prevent it
Most failed Auth0 to Keycloak migrations fail at the edges: users who cannot sign in, tokens that no longer carry the claims applications expect, and logic that was never ported. Each risk below has a specific check you can run before cutover, so problems surface in a staging realm rather than in production logins.
Password hashes missing from the export
Auth0 standard user exports do not include password hashes, so a plain bulk export moves profiles but not credentials. On paid plans you request the password hash export through a support ticket, and Auth0 does not guarantee a delivery date, so start that request early. Before cutover, confirm with a test user that the imported hash validates at login, and plan a fallback such as forced password reset for accounts without hashes.
Token claims that break authorization
Keycloak puts roles, groups and custom attributes into tokens through its own client scopes and protocol mappers, which rarely match the namespaced custom claims an Auth0 Action added. An application that reads a role claim from a different path can silently grant or deny access. Decode tokens from both systems for the same test user, diff the claim names and values, and verify every authorization check in each application against the new claim set.
Redirect URI mismatches
Keycloak compares redirect URIs and web origins against the client configuration exactly, so a trailing slash, a changed hostname or a missing staging callback returns an error at login. Recreate every Auth0 application's allowed callback, logout and origin URLs in the matching Keycloak client, including development and preview environments. Test sign-in, sign-out and token refresh in each environment before switching DNS or SDK configuration.
Attribute gaps in identity brokering
Social and enterprise identity providers send attributes under their own names, and Keycloak only stores what its identity provider mappers pick up. A connection that worked in Auth0 can create accounts with no email, no organization or no department after migration. For each connection, compare a sample login's raw attributes with the mapped user profile, and confirm that linking to existing accounts works for users who already exist in the realm.
Actions logic left untested
Auth0 Actions and Rules run as JavaScript inside the login pipeline, while Keycloak handles the same jobs with authentication flows, required actions, event listeners and custom providers written in Java. Logic such as enrichment, deny rules or conditional MFA is easy to drop without noticing. Inventory every Action, map each one to its Keycloak equivalent, and write test cases for both the allowed and denied paths before go-live.
Realm export used as a backup
The Keycloak server guide documents that realm export and import have limitations as a backup and restore method, and that all nodes must be stopped while the process runs. Teams sometimes treat a one-off realm JSON file as their disaster recovery plan, which misses user sessions, secrets and the live database state. Back up the production database with your standard database tooling, and use realm exports only as configuration snapshots kept under version control.
Questions buyers ask before moving from Auth0 to Keycloak
Can an internal team migrate from Auth0 to Keycloak without outside help?
Yes, a capable internal team can do the work, but the decision depends on whether it has someone who already runs Keycloak or similar identity infrastructure. The migration touches four separate areas: exported users and password hashes, social and enterprise connections rebuilt as identity providers, Auth0 Actions and Rules logic ported into Keycloak mechanisms, and application SDKs switched to standard OIDC. Each one needs testing against real login flows. Keycloak's own documentation covers import, export and high availability, but a production cluster also needs a synchronously replicated database, backups and a patching routine. Ask whether your team has capacity for that operating load after cutover, not only for the migration itself. DeployOpen plans and implements these migrations under a written, fixed scope if you prefer to hand off part or all of the work.
Will our users keep their passwords when we move from Auth0?
Not automatically. Auth0 does not include password hashes in standard user exports. Paid-plan customers request a password hash export through a support ticket, Auth0 does not guarantee a delivery date, and the option is not available on the Free tier. Plan for that request early, because it sits on the critical path. If the hashes do not arrive or cannot be imported, users will need a password reset flow at first login, which affects support volume and the test window. Confirm with Auth0 what hash format the export uses and whether Keycloak can verify it directly before you commit to a cutover date.
What drives the cost of moving from Auth0 to Keycloak?
The cost has four main components: the migration work itself, the infrastructure that runs Keycloak, the ongoing operations effort, and any support contract. The migration work scales with the number of applications, the number of social and enterprise connections, the complexity of Actions and Rules, and how many login flows need custom testing. Infrastructure scales with availability requirements and the database you choose. Keycloak is licensed under Apache 2.0, so there is no per-user or per-tenant license fee to pay, but that does not make the move free. Your Auth0 spend is recurring and metered by monthly active users, while the Keycloak costs are mostly one-time build work plus recurring hosting and staff time. Ask any vendor, including DeployOpen, for a quote that separates these lines.
How long does an Auth0 to Keycloak migration take?
No duration can be stated here from the facts available for this page. The timeline depends on the number of applications and SDK changes, the number of enterprise connections to rebuild, how much Auth0 logic must be ported, when the password hash export arrives, and how long your test window is. Keycloak's own release cadence does not set your schedule, but it matters for planning: since Keycloak 26.0 the project plans four minor releases a year and a major release every two to three years, with breaking changes in minor releases opt-in. Ask for a timeline in the written scope, with each dependency on your side listed separately.
What do we need from our application owners and test team?
Each application owner must confirm which login flows their application uses, which claims and token fields it reads, and how it handles sessions and logout. Your team must provide test accounts, staging environments that mirror production redirect URIs, and a test window long enough to cover every social and enterprise login path. Security or compliance staff should review the new identity provider configuration and the export handling. Without named owners and a test window, the migration tends to stall at SDK changes, which are the most application-specific part of the work. Agree on these responsibilities in writing before the project starts.
What breaks when Auth0 Actions and Rules move to Keycloak?
Custom logic that runs during login, such as claim enrichment, role assignment or conditional checks, does not transfer as code. It must be rebuilt using Keycloak mechanisms, such as protocol mappers, authentication flow customization, or small custom providers, depending on what the logic does. Token contents will change in places, so any application that reads a custom claim name or depends on a specific token structure needs review. Test each rule against the expected output for a representative set of users. Document every rule and its replacement, because that record becomes the audit trail for the change.
How does Keycloak's Apache 2.0 license change the cost comparison?
Apache 2.0 means the Keycloak software itself carries no license fee, so the comparison shifts from a metered subscription to the costs of running it. Keep in mind that Keycloak is open source software, not a managed service, so you pay for the infrastructure, the database, high availability design, backup, upgrades and the people who run them. Some vendors sell paid support or distributions of Keycloak, such as Red Hat build of Keycloak, and those are separate contracts with their own terms. When comparing, ask for a total cost model over your expected user growth that includes staff time, support, and the upgrade cadence, rather than comparing license lines alone.
How DeployOpen scopes and runs the migration
DeployOpen plans and implements the move from an Auth0 tenant to a self-hosted Keycloak realm inside your own infrastructure. Engagements are fixed-scope, so the export, import, connection rebuild, Actions porting and SDK changes are agreed in writing before work starts.
How we scope
- Inventory the Auth0 tenant: applications, APIs, social and enterprise connections, Actions, Rules and custom database scripts.
- Confirm with Auth0 whether a password hash export is available on your plan and how it will be requested by support ticket.
- Agree in writing which applications move in each wave, the target Keycloak version and the hosting model before work starts.
How we build
- Build the target realm, then import exported users and password hashes into a staging Keycloak to test login for each application.
- Recreate each social and enterprise connection as a Keycloak identity provider and verify claims and attribute mapping.
- Port Actions and Rules logic to Keycloak authentication flows and protocol mappers, and switch application SDKs to standard OIDC.
How we hand over
- Document realm configuration, client definitions, identity provider settings and the runbook for export and import operations.
- Deliver a cutover plan with a rollback path, including how users with unmigrated password hashes are handled at first login.
- Walk your operations and security teams through monitoring, backup procedures and the upgrade process for the Keycloak release in use.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the migration closes.
- Plan Keycloak upgrades with manual operator approval and tested schema migration, so minor releases do not change production unexpectedly.
- Prepare configuration and evidence that your internal or external auditors can review, without DeployOpen issuing any audit report or certification.
