Zitadel migration from Auth0 or Keycloak

What a Zitadel migration involves

Moving from Auth0, Keycloak or Firebase to self-hosted Zitadel is a migration of identity, not just of a user table. The work covers user records and their profile attributes, password credentials and any second factors, the application registrations that rely on them, and the OIDC and SAML clients that sign people in. Login flows, such as sign-up, password reset, MFA prompts and the redirects back to each application, need the same care because a change in any one of them breaks sign-in for every user of that application.

The usual triggers are licensing terms, where identity data is stored, the running cost of a hosted service at your user volume, and the wish to control the identity estate directly. Each trigger sets different priorities. A licensing or data location driver usually means the target instance and database must sit in infrastructure you choose from day one, while a cost driver makes the size of the estate and the number of active users the first numbers to pin down.

Who runs it. Many teams migrate a small estate in-house: a handful of applications, a modest user base and a team that already runs its own databases and Kubernetes or Docker hosts. A partner is more common when the estate is large, regulated, or has many client applications, each with its own redirect URIs, token settings and claim mappings. In those cases the risk sits in re-registering clients consistently and proving that users can still sign in.

What to confirm first. Inventory every application and every client registration, including SAML entity IDs and the claims each relies on. Check which password hashing scheme the source platform uses and whether the target can accept those credentials, since Zitadel's import paths and just-in-time options vary by source. Confirm with Zitadel's migration guides for your source platform rather than assuming parity.

What the work includes

A Zitadel migration from Auth0 or Keycloak runs as six linked workstreams. Each one ends in a artifact the client keeps, so the migration can be reviewed, repeated in a test environment and handed over to the team that will operate Zitadel afterwards.

Source inventory of tenants

Before any data moves, the source is catalogued: tenants or realms, user stores, identity connections, clients, roles and custom rules or hooks. The inventory shows which users depend on which connections and which applications depend on which clients, and it becomes the baseline every later step is checked against. Ask who owns each client and whether any are retired.

Instance and organization mapping

Each source tenant or realm is mapped to a Zitadel instance, organization and project structure. This decision sets data isolation, delegated administration and where project grants apply, so it is made once and documented. The mapping document records every source object and its target, including roles that must be recreated as project roles.

User migration approach

Users move either by up-front import of exported records or by just-in-time migration, where Zitadel checks the legacy store at first login. The choice depends on whether password hashes can be exported, how many users exist and whether source access will remain available. Zitadel's migration guides are the reference for each source platform.

OIDC and SAML client re-registration

Each application is re-registered as a Zitadel application with its redirect URIs, post-logout URIs, scopes and claims recreated exactly. SAML service providers need their entity IDs, assertion consumer URLs and attribute mappings checked. Small differences in redirect URIs or token claims are a common cause of failed sign-in after cutover.

Parallel run, cutover and rollback

Applications are tested against Zitadel while the source stays live, then traffic is switched in a planned window. The cutover runbook defines the order of steps, the checks at each stage and the conditions for returning to the source. Confirm how users created during the parallel run are reconciled before cutover.

Source decommissioning

Once cutover is accepted, the source is retired in a controlled way: credentials are revoked, connections and webhooks are disabled, and data retention obligations are met before deletion. Confirm with your compliance owner which audit logs and user records must be kept, and for how long, before the source is removed.

What drives cost and duration

Each row names a source-side factor that changes migration effort for Auth0 or Keycloak to Zitadel, why it matters, and what the client can do to keep it down.

Driver	Why it moves effort	How to keep it down
Users and activity	Every exported account needs mapping, validation and login testing, and dormant accounts add cleanup decisions.	Agree which accounts move before export, and archive or exclude dormant users first.
Source platform and edition	Export options, password hash handling and feature parity differ by Auth0 tenant setup or Keycloak version and edition.	Record the exact source version and edition early, and confirm export options with the vendor or project.
Password credentials and MFA factors	Password hashes and enrolled factors may not export cleanly, which can force resets, re-enrollment or just-in-time handling.	Confirm hash format and factor types early, then decide whether to migrate, reset or move users to passkeys.
Applications and protocols	Each OIDC or SAML client needs a new registration, redirect URIs, metadata exchange and separate testing.	Inventory clients, retire unused ones, and reuse one configuration pattern for similar OIDC or SAML applications.
Custom claims, rules and actions	Source-side logic must be reproduced as Zitadel Actions or application changes, and each piece needs its own tests.	Keep only logic that is still needed, and trim claims to the values applications actually read.
Organizations and tenants	Mapping Auth0 tenants or Keycloak realms onto Zitadel instances, organizations and projects shapes the data model and admin delegation.	Settle the hierarchy before the first import, and avoid one-off structures for individual customers.
Federated upstream identity providers	Each connection to Entra ID, Okta, LDAP or another provider needs reconfiguration and login testing per organization.	List every connection, consolidate where possible, and reuse one per-organization identity provider setup pattern.
Integrations reading identity data	Services that store user IDs, read claims or query user stores need changes when identifiers or subjects change.	Map identifier dependencies early, and keep stable IDs or maintain an explicit ID mapping table.
Environments and compliance evidence	Each environment needs its own cutover test, and assessors may expect records of what moved, when and who approved it.	Keep environments configured the same way, and record change logs, test results and approvals as work progresses.

Migration phases and outputs

The sequence moves identities and applications in controlled waves, and each phase closes with a record that the next phase depends on.

Discover and inventory the source
Your team and DeployOpen list every user store, application, OIDC and SAML client, redirect URI, custom rule or hook, and API or SCIM consumer on Auth0 or Keycloak. The inventory also records password and MFA settings in use. Output: a signed-off inventory that maps each application to an owner and a cutover group.
Design target structure and choose approach
Map the inventory to Zitadel instances, organizations and projects, including roles, grants and any per-customer identity providers. Confirm with the source vendor what password data can be exported, then choose between importing users up front and just-in-time migration. Output: a written target design and an approved migration approach.
Build and test in non-production
Deploy a non-production Zitadel with PostgreSQL, configure the instances, organizations, projects and federation from the approved design, and run the import or just-in-time flow against a copy of source data. Test sign-in, MFA, password fallback and token claims. Output: a repeatable migration runbook with recorded test results.
Re-register clients and test integrations
Create the OIDC and SAML clients in Zitadel for each application, then update redirect URIs, signing certificates, metadata and client secrets, and point each application at the new issuer. Test sign-in, logout, token refresh and role claims for every integration. Output: a client register and signed integration test results per application.
Run a pilot cohort
Move one small group of users or one customer organization first, chosen with the application owners, and keep the source running so pilot users can fall back. Monitor authentication errors, support tickets and account-linking issues. Output: a pilot report with defects resolved and a recorded decision to proceed with the remaining cohorts.
Cut over with a tested rollback
Move the remaining users and applications in agreed waves during a change window, with the rollback procedure rehearsed beforehand. Confirm that DNS, redirect URIs and secrets have switched, and watch sign-in volume and error rates after each wave. Output: a cutover record for each wave, with the rollback point kept available until sign-off.
Decommission the source platform
After the business accepts the cutover, disable source logins, export and retain required audit logs under your retention policy, revoke source credentials and API keys, and remove unused clients. Output: a decommissioning checklist signed by security and application owners, with the disposition of source data recorded.

How the work changes by source platform

Auth0 tenants are usually read through the management API and export jobs, so the first step is confirming what your plan and tenant settings allow you to extract. The Zitadel migration guide for Auth0 describes the supported approach, but confirm these points with Auth0 and in your own tenant:

Whether user profiles, metadata and roles can be exported in full, and in what format
Whether password hashes can be exported and verified by Zitadel after import
Whether MFA factors can be carried over or must be re-enrolled by users
Which Auth0 Actions or hooks hold custom logic, and how each will be replaced in Zitadel
Client definitions, callback URLs and API audiences, which must be re-registered in Zitadel

What teams keep in-house and what they outsource

This table lists each migration part with its usual owner, the skills it needs and where a partner adds the most value, so you can see which work stays with your own teams.

Migration part	Usual owner	Skills needed	Where a partner adds value
Client settings in each application	Application owners in your organization	OIDC and SAML client setup, redirect URIs, token claims, staged secret rotation	Cross-application inventory of clients, scopes and claims. Owners still change their own settings and test them.
Instance, organization and mapping design	Identity engineers	Zitadel instance, organization and project model, mapping from Auth0 tenants or Keycloak realms	Design review of tenant mapping and role model. Your team confirms which business units map to which organizations.
PostgreSQL and hosting	Database and infrastructure staff	PostgreSQL administration across supported versions, backups, network paths, Kubernetes or Docker hosting	Repeatable deployment manifests tested in staging. Your staff keep production access, backups and change windows.
Credential handling and MFA policy	Security staff	Password hash compatibility, secret storage, export handling, MFA and passkey policy design	Documented credential path and policy test cases. Your security team approves risk acceptance and retention of export files.
User import and just-in-time migration	Identity engineers with data staff	Export handling, scripting, data validation, reconciliation of user counts and attributes	Repeatable import pipeline with dry runs and reconciliation reports. Your team confirms data quality and stale accounts.
Parallel-run testing	Application owners and QA	Test scripts for login, logout, token refresh, role checks and account linking	Parallel-run test plan and evidence log. Application teams run business acceptance tests and sign off.
User communications and service desk	Service desk staff	Support scripts, password and passkey enrollment guidance, escalation paths	Draft notices, FAQ and agent runbook. Your team sends notices and handles escalations.
Cutover and rollback	Platform owner with application owners	Freeze windows, redirect and DNS changes, rollback steps, post-cutover monitoring	Cutover runbook and rehearsal plan. Your staff approve the window and make the go or no-go call.

What usually goes wrong

Identity migrations tend to fail at the same few points. Each card names where a move to Zitadel from Auth0 or Keycloak usually breaks and the step that prevents it.

Users locked out after cutover

Password hashes, MFA enrollments and passkeys do not always move with user records, so migrated users may face resets they did not expect. Confirm in the Zitadel migration guide which password hash formats and factors can be imported from your source. Test sample accounts with each credential type before cutover, and plan the support path for users who must re-enroll.

Client settings that do not match

Redirect URIs, token audiences, claim names, SAML entity IDs and signing certificates are often re-entered by hand in Zitadel. One mismatch can stop sign-in for a whole application. Export each source client, map every setting to its Zitadel equivalent, and compare test tokens and SAML metadata in staging before traffic moves.

Dormant accounts imported without a policy

Importing every historical user brings in accounts that have not signed in for a long time, along with stale email addresses and unused credentials. Decide before import which inactive accounts migrate, which are disabled and which are archived. Confirm that the export includes last-login data so the rule can be applied, and record the decision with the business owner.

Duplicate accounts from identifier mismatches

Email case, username format and email verification status can differ between Auth0, Keycloak and Zitadel. The same person may then appear twice after a just-in-time login or a bulk import. Normalize identifiers in the export, name the attribute that is the unique key, and run a duplicate report on the imported set before users sign in.

Just-in-time migration left running indefinitely

Just-in-time migration keeps the source system in the login path until each user signs in once. Without a sunset date and a list of users who have not moved, the legacy identity provider remains a dependency, and its hosting and security obligations continue. Set the retirement date in writing, track migrated counts and decide how remaining users are handled.

No tested rollback

Without a rollback path, users can end up split between two systems if Zitadel fails after go-live. Define the trigger for rollback, the window in which changes are written to Zitadel and how those changes return to the source. Rehearse the reverse move on a staging copy, and confirm with your source vendor whether its user store can accept changes made during the window.

What the client needs to provide

Most of the schedule risk in a Zitadel migration sits in decisions and access that must exist before the build starts. Confirm these first: admin access to the source Auth0 tenant or Keycloak realm with export rights, a working inventory of every application and its owner, and a list of custom rules, hooks or Actions running on the source. Without the rules list, login logic can disappear silently at cutover, so ask the source platform team to export it rather than rely on memory.

Infrastructure inputs come next. Decide the hostname for the new Zitadel instance and have DNS and TLS plans agreed, since OIDC redirect URIs and issuer values depend on that hostname and are hard to change later. Name the hosting target: a Kubernetes cluster where the official Helm chart will run, or a Docker Compose host for a smaller footprint, with a PostgreSQL service that falls within the database versions Zitadel supports (14 through 18, per the Zitadel documentation). Confirm who operates that database and where its backups go.

Decisions that must be made before build starts: for each user population, choose between importing users up front and just-in-time migration, where credentials are verified against the old system on first login. Import moves data in one step but requires password hashes or a reset plan. Just-in-time keeps the old system alive for longer. Also agree which clients are re-registered as new Zitadel applications, since OIDC and SAML client identifiers and secrets will change, and which applications need a cutover window.

Finally, name the people who will make decisions during cutover: a business owner who approves the cutover window and accepts the rollback criteria, and a named application owner for each client who will test sign-in and update configuration in their own system. Ask the client to confirm that these owners are available for the test and cutover dates, because an unassigned application is the most common reason a cutover slips. Confirm any user-facing notices and support coverage with the business owner before the window is set.

Common questions before migrating to Zitadel

What drives the cost and effort of a Zitadel migration?

The number of applications, identity sources and custom rules drives most of the effort. Each application needs its OIDC or SAML client re-registered, tested and cut over, and each custom rule, hook or claim mapping in the source platform must be rebuilt or retired. Other factors include the number of users, whether passwords can move, how many organizations and instances the target design needs, and how much data cleanup the export requires. Costs have two parts: one-time work (analysis, build, testing, cutover) and any recurring hosting and support you add after go-live. Ask any partner for a quote that lists these items separately.

Can our own team migrate from Auth0 or Keycloak to Zitadel without a partner?

Yes, if your team has the skills and time, but most teams need to check both before deciding. The work needs people who can run Zitadel on PostgreSQL and your chosen deployment target, who understand your current OIDC and SAML clients, and who can test login flows end to end. Your team also needs a cutover plan that covers rollback. If those skills are missing or the calendar is tight, an implementation partner can take on defined parts of the work under a written scope. Assess your skills against the migration plan before you choose.

How long does a migration to Zitadel usually take?

The duration depends on the scope agreed in writing, so no fixed timeline applies to every migration. The main drivers are the number of applications and clients to re-register, the number of identity sources, the complexity of custom logic, the chosen user migration approach, and the number of test and cutover rounds your change process requires. Dependencies on your own teams, such as application owners who must approve changes, also affect the calendar. Ask for a timeline that ties each phase to a named deliverable and to the inputs you must provide.

Do our users have to reset their passwords during migration?

It depends on what the source platform exports and which migration approach you choose, and you should confirm both early. If the source can export password hashes in a form Zitadel can verify, users may keep their existing passwords. If the export does not include hashes, or your security policy requires a fresh credential, users may need to reset passwords or set up passkeys. Confirm the export options with your Auth0 or Keycloak administrators and review the Zitadel migration guide for your source before you tell users anything.

Is just-in-time migration better than importing all users up front?

Each approach has trade-offs, and the right choice depends on your constraints. Importing users up front gives you one dataset in Zitadel from the start, which simplifies reporting and removes the source dependency sooner, but it requires a complete, clean export and a larger cutover. Just-in-time migration moves each user when they first sign in, which spreads the load and lets you keep the source running, but the source must stay available and the old and new systems run side by side for longer. Zitadel's migration guides document approaches such as just-in-time migration, so review them against your user count, password export options and retirement date.

What information and access do we need to provide before migration starts?

You need to provide access, inventory and decisions before any build work begins. Typical inputs include administrator access to the source tenant or realm, an inventory of applications with their OIDC and SAML settings and redirect URIs, the custom rules and claims in use, identity provider connections, and user counts by group. You also need a target design for instances, organizations and projects, a test user set, a cutover window, and named owners on your side who can approve changes. Infrastructure access for the self-hosted target, such as Kubernetes or Docker hosts and PostgreSQL, must be agreed as well.

How DeployOpen scopes and delivers Zitadel migrations

DeployOpen plans a Zitadel migration from Auth0 or Keycloak as a written scope, starting with an inventory of users, applications and clients, then builds the import or just-in-time path inside infrastructure you control. Engagements are fixed-scope, with ongoing support available as a retainer.

How we scope

We inventory source users, roles, applications and OIDC or SAML clients on Auth0 or Keycloak before choosing an approach.
The written scope states whether users are imported up front, migrated just-in-time, or split between the two, with reasons.
Scope lists which OIDC and SAML clients must be re-registered in Zitadel, with redirect URIs, owners and cutover order.

How we build

We stand up the target Zitadel instance, organizations and projects in your environment, with PostgreSQL configured for your version.
We build the user import or just-in-time flow, mapping password handling, MFA enrollment and attributes from the source system.
We test sign-in for each re-registered client in a non-production environment before any user is moved.

How we hand over

You receive the migration runbook, the field mapping, the client registration register and the rollback steps in writing.
Handover covers cutover checks, reconciliation reports comparing source and target user counts, and known gaps agreed in scope.
Your team runs a walkthrough of the import job, the just-in-time logic and the operational steps for the cutover window.

How we support

Post go-live support, upgrades and continuous testing are available as retainers once the migration is complete.
Support can cover monitoring of the just-in-time path until the source system is retired, if that is part of the written scope.
Ask for the support boundary in writing, including who handles client issues raised by application owners after cutover.