Migrate from Auth0 to ZITADEL

Migrate from Auth0 to ZITADEL: what the move involves

Moving customer identity from Auth0 to self-hosted ZITADEL is mostly a data and integration project, and the password hashes are the item that decides whether it runs smoothly. Users can be exported in bulk with a standard job, but Auth0 does not include password hashes in that export. On paid plans, hashes come only through a support ticket, Auth0 does not guarantee a delivery date, and the option is not available on the Free tier. Start that request first, because the rest of the plan depends on what it returns. If hashes are not delivered, users must reset passwords or move through a just-in-time migration path, which changes the user experience and the support load.

The work usually falls to three groups: the platform team that deploys and runs ZITADEL on PostgreSQL 14 or later, the security team that defines password, MFA and passkey policy and signs off on how hashes are handled, and the application teams that switch their SDKs and login redirects to standard OIDC. Plan for the effort to sit mostly in rebuilding Auth0 Actions as ZITADEL actions, recreating social and enterprise connections as identity providers, and testing each application end to end. Confirm with ZITADEL which migration guide matches your Auth0 setup and which hash formats it can import, since that determines how much of the export you can use as is.

For multi-tenant B2B products, the mapping of Auth0 Organizations to ZITADEL organizations inside an instance needs its own design review, because it changes token claims and how each customer's identity provider is attached. Keep the Auth0 tenant running in read-only or parallel mode until cutover is verified, and keep the exported files under the same access controls as the production user store. The short answer is that effort and risk are driven by hash availability, the number of applications and Actions, and the count of enterprise connections, so ask for the Auth0 tenant inventory before agreeing a scope.

Which Auth0 capabilities map cleanly to ZITADEL

This table maps the Auth0 capabilities that matter in a customer identity migration to their ZITADEL equivalents and labels each row as clean, needs rework or gap. Rows marked needs rework or to verify are where the migration plan needs a decision or a vendor confirmation before cutover.

Auth0 capability	ZITADEL equivalent	Migration status
User profiles and bulk export	Users in instances and organizations, imported through the ZITADEL APIs after export from Auth0 NDJSON or CSV files	Clean for profile fields, rework for mapping custom metadata to ZITADEL user attributes
Password hashes	ZITADEL migration guide from Auth0 covers hash handling, but the hash format and import path must be confirmed for your export	Needs rework: request the hash export by support ticket on a paid plan and confirm the algorithm with Auth0 and ZITADEL before relying on it
Organizations (B2B customers)	Organizations inside an instance, where projects and users live and each can hold its own identity provider	Needs rework: map Auth0 member roles and per-organization connections to ZITADEL organization roles and grants
Social connections	Federation with Google, GitHub, GitLab, Apple and other OIDC or SAML providers	Clean for common providers, rework for client credentials and redirect URIs that must be reissued
Enterprise connections (SAML, OIDC)	Federation with Entra ID, Okta, LDAP and OpenLDAP, Keycloak and any OIDC-compliant provider, set per organization	Needs rework: rebuild each customer connection and test attribute mapping with each customer's IdP
Actions and Rules logic	No direct equivalent of Auth0 Actions is confirmed in the supplied facts; ZITADEL login flows and actions must be rebuilt	Gap to verify: export every Action and Rule, then confirm with ZITADEL which logic can be recreated as actions or must move to the application
Universal Login and branding	ZITADEL hosted login is licensed under AGPL-3.0 and can be customized; the supported theming and login hosting model must be checked	Needs rework: rebuild branding and login pages, and confirm whether you host the login UI yourself
Passkeys and MFA	Passkeys based on FIDO2 and WebAuthn with fallback to password login; MFA options to confirm against your Auth0 setup	Clean for passkeys, needs rework for MFA enrollment, since existing factors do not transfer automatically
SCIM provisioning	SCIM v2 service provider interface for standardized user provisioning and lifecycle management	Clean for standard SCIM 2.0 clients, verify each customer's provisioning connector before cutover
Tenant-level settings and custom domains	Instances, organizations and projects replace tenants, with settings that must be recreated manually	Gap to verify: list Auth0 tenant settings such as custom domains, email templates and rate limits, and confirm equivalents with the vendor

What data moves and what must be rebuilt

Auth0 user data moves through documented export jobs, but password hashes take a separate path and most of the surrounding configuration must be rebuilt in ZITADEL. The cards below separate what you can export on your own, what depends on a support request, and what your team recreates by hand.

Bulk user export job

Auth0 can export users through the Dashboard or through the Management API create export users job, which posts to the users exports jobs endpoint. The output is NDJSON or CSV, and it carries profile attributes, identities and metadata but no password hashes in the standard file. Run the export against a non-production tenant first, then compare record counts and the fields you need for ZITADEL user import, such as email, verified status and external identity links.

Password hash export by support ticket

Password hashes are not in standard exports. Paid-plan customers request them through an Auth0 support ticket, and Auth0 does not guarantee a delivery date. The option is not available on the Free tier, so confirm your plan and open the request early. Before you rely on the hashes, ask Auth0 which algorithm and format they use, then confirm with ZITADEL's migration guide whether it can verify that format on import or whether users must reset passwords.

Applications and SDK configuration

Each Auth0 application has its own client ID, allowed callback and logout URLs, and SDK settings. Auth0 SDKs use Auth0-specific endpoints, so each application must move to a standard OpenID Connect client in ZITADEL with new client credentials. Inventory every application, including mobile and server-side clients, and plan a cutover that updates redirect URIs without breaking active sessions.

Social and enterprise connections as identity providers

Auth0 social and enterprise connections do not transfer as data. In ZITADEL, each provider is recreated as an identity provider, for example Google, GitHub, Entra ID or Okta over OIDC or SAML, or an LDAP directory. Per-organization providers are possible, so map each Auth0 connection to the organization that uses it. Confirm each provider's client secret, redirect URI and attribute mapping with the upstream owner before cutover.

Actions and login flow logic

Auth0 Actions and Rules hold custom logic such as claim enrichment, role assignment and login gating. This logic does not port automatically. Document each Action by trigger, input and output, then decide which behavior ZITADEL covers through its own settings and which needs code in your application or a separate service. Test token contents for each application, because claim names may change.

SCIM and LDAP consumers

Downstream systems that read or provision users, such as HR tools, directories or applications that expect LDAP or SCIM, depend on the identity source. ZITADEL offers a SCIM v2 service provider interface and LDAP support, so list every consumer, its endpoint and its attribute expectations. Test provisioning and deprovisioning in staging, since a change in user IDs or attribute names can break a sync.

Migration sequence from inventory to decommission

This sequence moves customer identity from Auth0 to a self-hosted ZITADEL instance in stages, so each stage has a named output and a rollback path before any production user is switched. Teams that follow it in order keep Auth0 running until the new login flows have been proven.

Inventory users, connections, Actions and applications
Start by listing everything the Auth0 tenant does: user count and user sources (database connections, social logins, enterprise connections), every Action and Rule, each application and its callback URLs, and each Organization with its members and connection. Pull the user export with the bulk export job in NDJSON or CSV, and record which export options your plan allows. Write the results into an inventory register that names the owner of each item and marks which items are migrated, rebuilt or retired. The step is done when the register is reviewed by the application owners and nothing in the tenant is unaccounted for.
Request the password hash export early
Password hashes are not part of standard exports, so raise a support ticket with Auth0 for the password hash export as soon as the inventory is complete. Auth0 does not guarantee a delivery date, and the option is not available on the Free tier, so confirm eligibility with Auth0 before planning around it. Ask Auth0 which hash algorithms the export contains and whether it covers every database connection. The step is done when the hash file is in hand, stored under the same controls as the user data, and checked against a sample of test accounts.
Deploy a pilot ZITADEL instance
Stand up a pilot ZITADEL instance in your own environment, using Docker Compose for a lab or Kubernetes with the official Helm chart for anything that resembles production. ZITADEL needs PostgreSQL 14 or later, and the database versions it supports are listed in its documentation, so confirm the version you run against that list. Model your Auth0 tenants as ZITADEL instances or organizations and projects according to the inventory, and import a subset of users with their hashes. The step is done when a signed-off pilot demonstrates login, token issuance and an organization admin workflow for each application in scope.
Rebuild login flows and Actions in ZITADEL
Translate each Auth0 Action into the ZITADEL equivalent, such as a customized login flow, a token claim or a provisioning step, and mark any logic that depends on Auth0 internals for redesign rather than copying it. Recreate social and enterprise connections as identity providers, and confirm which upstream providers ZITADEL supports for each one, including OIDC, SAML 2.0 and LDAP. Test passwordless and password fallback flows with your security team. The step is done when a test matrix covering every application, connection and role passes and the security team has signed off the flows.
Run a parallel period with just-in-time migration where it fits
For users whose password hashes cannot be imported, consider the just-in-time migration approach described in ZITADEL's migration guides, where a user is verified against Auth0 at first login and then created in ZITADEL. Keep Auth0 live during this period so both systems can serve logins, and track in a dashboard how many accounts have moved. Confirm with the vendor and your own tests that the just-in-time path works for each connection type before relying on it. The step is done when the migrated share of users is tracked against the inventory and every remaining account has a named owner and a plan.
Cut over applications in waves
Move applications to ZITADEL one group at a time, starting with low-risk internal applications and ending with the customer-facing ones. Update each SDK to standard OIDC settings, change the issuer and client configuration, and keep the Auth0 client available for the same application until its wave is stable. Monitor login success rates, token errors and support tickets after each wave. The step is done when each wave has a recorded go or no-go decision and the owner of each application has confirmed normal operation.
Keep a tested rollback plan through cutover
Before each wave, write a rollback plan that names the DNS, configuration or client change needed to point an application back to Auth0, and rehearse it in a non-production environment. Define the conditions that trigger a rollback, such as login failure rates or token validation errors, and assign who makes that call. Keep the Auth0 tenant in place and its users and configuration unchanged until the rollback window for the last wave has closed. The step is done when the rehearsal records and the rollback triggers are approved by the service owners.
Decommission Auth0 and retain evidence
When all applications and users are on ZITADEL and the rollback window has passed, export a final copy of the tenant configuration and logs that your retention rules require, then disable and remove the Auth0 applications, connections and tenant. Revoke the Auth0 API credentials used by migration scripts and update the vendor list, contracts and data processing records. Store the decommission record with the inventory register and the cutover decisions so auditors and assessors can trace what happened to each user and application. The step is done when Auth0 access is closed, the final export is stored under your retention policy, and the decommission record is filed.

How to run Auth0 and ZITADEL in parallel and cut over

The safest cutover keeps Auth0 fully active until ZITADEL has proven it can verify passwords and sessions for real users. Plan the dual-running window around the password hash path first, because that is the step most likely to fail quietly. Set up a ZITADEL instance, then create the organizations and projects that mirror your Auth0 tenant: one ZITADEL organization per Auth0 Organization where you serve B2B customers, and one project per application, with roles and grants recreated inside it. ZITADEL's instance boundary gives full data isolation, so use a separate instance for production and a staging instance that imitates it, rather than mixing test users into production.

Before any traffic moves, test the password hash path with a copied set of users. Import a sample that includes accounts from each hash type you received from Auth0, sign in with known passwords, and confirm the login succeeds and the hash is upgraded on first use. Also check that MFA enrollments, verified emails and social links survive the import, and that sessions issued by ZITADEL carry the claims your applications expect. Confirm with your Auth0 support contact which hash formats the export includes, since the export depends on a support ticket and Auth0 does not guarantee a delivery date.

Switch traffic one application at a time by changing the OIDC client configuration in each application, and keep the Auth0 client available for rollback. For users who sign in during the window, decide whether ZITADEL should verify credentials on first login (just-in-time migration, as described in the Zitadel migration guides) or whether those users were already imported in bulk. Record which path each account took, because a user who changes a password on one side can diverge from the other. Keep Auth0 running until every application has passed its checks and existing sessions have expired or been re-established, and treat that retirement date as a decision to take in writing, not a calendar default.

What drives cost and duration in this migration

This table lists the factors that move the effort of moving from Auth0 to self-hosted ZITADEL, why each one matters, and how to keep it under control. Read it as a checklist to scope the work before asking for a fixed-scope quote. The main takeaway is that the largest swings come from application count, Actions logic, and the password hash request, which has a vendor-controlled lead time.

Driver	Why it changes cost or time	How to keep it down
Number of applications and SDKs	Each application needs its client configuration recreated in ZITADEL and its Auth0 SDK calls replaced with standard OIDC libraries, so effort grows with every app and framework.	Inventory every client ID and SDK version first, group apps by framework, and migrate low-risk apps in waves.
Actions logic to port	Auth0 Actions run custom JavaScript in login and token flows. ZITADEL uses its own actions and flows, so each Action must be rewritten, tested and reviewed for security impact.	List every Action with its trigger and purpose, remove unused ones, and move claim mapping into a small set of shared functions.
Number of Organizations and enterprise connections	Each Auth0 Organization must map to a ZITADEL organization with its own members, roles and identity provider. Enterprise SSO setups with customer-specific settings take individual testing.	Export the Organization list and connection settings early, group customers by identity provider type, and pilot one connection per type before bulk cutover.
Password hash export lead time	Password hashes are not in standard exports. Paid-plan customers request them by support ticket, and Auth0 does not guarantee a delivery date, so this step can set the critical path.	Open the ticket at project start, confirm the plan tier and hash format with Auth0 support, and plan a just-in-time fallback for users if hashes arrive late.
Bulk export and data validation	The export job produces NDJSON or CSV files that must be checked for missing fields, duplicate emails, custom metadata and unverified accounts before import.	Run a test export, script validation against a sample, and agree on how to handle users with no password or unverified email.
PostgreSQL and high availability setup	ZITADEL needs PostgreSQL 14 or later, and the Kubernetes Helm chart is recommended for high availability. Database sizing, backups, replicas and upgrades add recurring infrastructure and operations work.	Confirm the supported PostgreSQL version (14 to 18), decide the hosting model early, and document backup and restore tests before go-live.
Team skills and operating model	Running ZITADEL in production requires people who can operate Kubernetes or Docker Compose, PostgreSQL and OIDC security settings. Gaps add training time or outside support, which recurs after launch.	Assess current skills honestly, name owners for upgrades and incidents, and ask any implementation partner which tasks transfer to your team.

What usually goes wrong and how to prevent it

Most failed Auth0 to ZITADEL migrations break at the same few points: credentials, login access, token contents, organization membership and licensing obligations. Each card below names one risk, why it matters for this move, and the check that prevents it before users notice.

Password hashes arrive late or incomplete

Auth0 leaves password hashes out of standard user exports, and paid plans must request them through a support ticket with no guaranteed delivery date. Ask for the hash export early, confirm with Auth0 which hash algorithm and fields are included, and test a sample of imported accounts with a real password login in a staging ZITADEL instance. Plan a fallback for users whose hashes never arrive, such as a reset flow that runs on first login.

Users locked out at cutover

Users locked out at cutover is the most visible failure, usually caused by a stale user snapshot, a DNS or redirect change that lands before the new login is ready, or sessions that do not carry over. Run a final delta export close to the switch, freeze or throttle sign-ups during that window, and keep Auth0 active for a rollback period. Rehearse the full login path with test accounts, including MFA and social logins.

Token and claim changes break applications

Auth0 Actions often add custom claims, and ZITADEL issues tokens with its own claim names, audiences and role structures. An application that reads a custom namespace claim or expects a specific audience can fail even when login succeeds. Inventory every claim each client reads, map old names to new ones, and verify token contents with a test client against the ZITADEL endpoints before switching the SDK.

Organization membership mismatches

Auth0 Organizations hold members, roles and connections, and ZITADEL places users, projects and grants inside its own organizations within an instance. Membership and role grants can be lost or attached to the wrong organization if the mapping is done by name alone. Build a mapping table from each Auth0 organization ID to a ZITADEL organization, reconcile member counts per tenant after import, and confirm that each customer's identity provider and domain point to the right organization.

AGPL obligations for modified ZITADEL code

ZITADEL's core, Console and hosted login are licensed under AGPL-3.0, so customizing the login UI or the core service can trigger source disclosure duties for users who interact with the modified software over a network. Decide early which parts you will change, keep customizations in separate Apache 2.0 components where the project allows, and have legal counsel review your obligations with the vendor's license terms. Application code that only calls the APIs is generally outside this scope, which should be confirmed for your architecture.

Login flows and actions not ported

Auth0 Actions, rules, hooks and branding often hold business logic, such as blocking risky logins or enriching profiles, that does not exist in ZITADEL in the same form. Export a list of every Action and its trigger, classify each as replaced by a ZITADEL feature, rebuilt as an external service, or dropped by decision, and test each path. Record the decisions in the cutover runbook so security owners can sign them off.

How the migration differs by starting point

A small single-tenant application usually has one Auth0 tenant, one or two client applications, a modest set of users and a short list of login connections. The migration is mostly about moving the user store and switching the SDK to standard OIDC. Because the blast radius is small, the sequence can be short: stand up ZITADEL, create one instance and organization, recreate the application as an OIDC client, then run the export and import.

Inventory the tenant first: list applications, connections, custom domains and the callback and logout URLs registered for each client.
Plan the password path: confirm with Auth0 support whether password hashes are available for your plan before you commit to keeping passwords intact.
Keep the old tenant live: leave Auth0 running until login through ZITADEL has been tested with real accounts and the rollback path is written down.
Swap the SDK, not the logic: most single-application work is replacing the Auth0 SDK with a standard OIDC library pointed at ZITADEL.
Test the edge cases: password reset, MFA enrollment and sign-up emails are often missed in small projects.

Before starting, confirm with your team which users and login methods must work on day one, and whether a short period of forced password resets is acceptable if hashes cannot be moved.

Questions teams ask before moving from Auth0 to ZITADEL

How long does a migration from Auth0 to ZITADEL take?

No fixed duration can be given from the facts available, and the timeline depends mostly on the size and shape of your tenant. The main drivers are the number of users, how many Auth0 Actions and custom database scripts you run, how many social and enterprise connections must be recreated, how many applications use the Auth0 SDKs, and whether you migrate all users at once or use just-in-time migration. ZITADEL documents migration guides from Auth0 that describe these approaches, so read the guide for your version before you estimate. Ask DeployOpen for a fixed-scope plan with written milestones, and confirm the sequencing with the ZITADEL project's documentation.

What does moving from Auth0 to self-hosted ZITADEL cost?

The cost splits into components that different parties are paid for. Auth0 subscription fees end when you stop paying them, so budget for the overlap period while both systems run. ZITADEL itself is open source, so the recurring costs are infrastructure (compute, a PostgreSQL database in versions 14 through 18, load balancing and backups), the staff time to operate and upgrade it, and any support contract you choose. One-time costs include the migration project, rebuilding login flows and actions, and testing. A quote from DeployOpen follows from a written scope, and you should ask for each component to be priced separately so you can compare it with your Auth0 invoices. The ZITADEL pricing page lists the vendor's own commercial options.

Can password hashes be moved from Auth0 to ZITADEL?

Passwords can be preserved only if Auth0 releases the password hashes, and that is not part of a standard export. Auth0 excludes password hashes from its normal user exports. Customers on paid plans can 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. Start that request early and confirm its availability, format and timing with Auth0 before you plan cutover. If hashes are not released, plan for just-in-time migration or a password reset flow for users. Confirm with the ZITADEL project which hash algorithms its import path accepts.

What does our team need to provide for the migration?

Your team needs to own the business decisions and provide access to the systems that hold knowledge of your current setup. Expect to supply an owner for each application and its redirect URIs, a list of social and enterprise connections with their configuration, the Auth0 Actions and any custom database logic that must be rebuilt, and a test plan for sign-in, sign-up, password reset and MFA. You will also need someone who can make decisions on the organization model, because Auth0 Organizations must be mapped to ZITADEL organizations inside an instance. Name these owners in the written scope so timelines do not depend on informal availability.

Can our own engineers migrate from Auth0 to ZITADEL in-house?

Yes, a capable team can run the migration internally, but the work has more parts than a user export. The export job is the simplest step, and the harder work is rebuilding Actions logic as ZITADEL flows and actions, moving connections, switching application SDKs to standard OIDC, and running a self-hosted ZITADEL with PostgreSQL, high availability and backups. The ZITADEL documentation covers self-hosting with Docker Compose or Kubernetes and recommends the official Helm chart for high availability. Decide whether your team will also run ZITADEL after go-live, since that recurring work often matters more than the migration itself. DeployOpen can plan, implement, harden and document the work as a fixed-scope engagement, or support your team through it.

What does the AGPL license mean for our deployment?

ZITADEL moved its core, Console and hosted login from Apache 2.0 to AGPL-3.0 with v3.0 on 31 March 2025, while APIs, SDKs, proto definitions, documentation, Helm charts and Terraform configurations remain Apache 2.0. Running ZITADEL internally for your own users is generally a different situation from offering a modified version to others over a network, because AGPL obligations can apply to network use of modified code. Have your legal team review how your application, any modifications and any customer-facing login pages interact with the license. Confirm the terms with the ZITADEL project and your counsel rather than relying on this summary.

How do we export our current users from Auth0?

Auth0 supports bulk user export through the Dashboard or the Management API create export users job, in NDJSON or CSV format. The export covers profile and metadata fields, but it does not include password hashes, which need the separate support request described above. Test the export on a development tenant first, check that custom attributes and user metadata are present, and reconcile user counts against your Auth0 reports. Store the export securely because it contains personal data, and confirm with Auth0 any limits on export size or retention of the file.

How DeployOpen scopes and runs the migration

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted ZITADEL inside your own infrastructure, whether that is your cloud account, a data center or an air-gapped network. For this migration, the written scope should name the ZITADEL deployment method you choose (Docker Compose or Kubernetes with the official Helm chart), the PostgreSQL instance it will use (versions 14 through 18 are supported), the instances, organizations and projects that will be created, and the identity providers that will be federated. Those decisions drive most of the work, so settle them before anyone estimates effort.

Most engagements are fixed-scope. Deliverables and timelines are agreed in writing before work starts, and they typically cover the export and import tooling, the hash handling for users who keep passwords, the Organization and project mapping, the rebuilt login flows and actions, the cutover runbook, and the documentation your operations and compliance teams will need. Ask for each deliverable to name its acceptance test, such as a sample of migrated users signing in with an existing password, a token check for each application, and a restore test of the PostgreSQL backups. A quote follows from that written scope, so a vague scope produces a vague quote. Compliance readiness work is prepared by DeployOpen, but audit reports and certifications come from independent auditors and certification bodies.

After cutover, ongoing support, upgrades and continuous security testing are available as a retainer. Ask the vendor-neutral questions up front: who applies ZITADEL releases and database upgrades, who owns the Helm values and secrets, who responds when a federated identity provider changes its configuration, and how often backups are tested. Confirm the ZITADEL license terms with your legal team before you deploy, since the core moved to AGPL-3.0 with v3.0 and your use case may affect obligations. Those answers determine whether a retainer, an internal team or a mix of both fits your organization.

Migrate from Auth0 to ZITADEL