Migrate from Auth0 to Zitadel: what the move involves
Teams that run Auth0 tenants and want their identities in infrastructure they control can move users and applications through documented paths, and Zitadel's Auth0 migration guide covers both. Password credentials are the gating item, because they decide whether users keep their existing passwords or must set new ones. Effort depends mainly on how many users and applications are in scope, how many tenants sit behind them, and how much custom logic in Auth0 Actions or other extensions must be rebuilt or retired. A single tenant with a few applications and a clean user inventory is a contained project. Several tenants with many applications, enterprise connections and bespoke login flows need a longer plan, and the duration should be set from a written scope.
Auth0 does not include password hashes in standard exports, so the first decision is how to handle passwords. The Zitadel guide describes two paths. You can open an Auth0 support ticket to download the hashes in bcrypt format, which lets users sign in with their existing passwords after import. Or you can import users without hashes and require a new password at first login. Start the support request early, because its turnaround is outside your control. Ask Auth0 which export format it will provide, whether your plan or contract covers the request, and how long the files remain available. Then agree on a reset path for users who never return during the transition, along with who answers their questions, before the first batch is imported.
Structure mapping is the next design task. Zitadel organizes tenants as instances, places users and projects inside organizations, and groups applications, roles and grants within projects. Decide how each Auth0 tenant maps to these levels, and whether tenants that must stay isolated should become separate instances. Each Auth0 application needs a matching Zitadel application, with redirect URIs, grant types and token settings recreated and checked one by one. Auth0 roles and permissions have to be rebuilt as Zitadel roles and grants, and any custom claims added by Actions must be reproduced or removed. Inventory connections as well. Social and enterprise connections in Auth0 need matching identity providers in Zitadel, and each one should be confirmed as supported before the project is scoped.
These inventories drive the effort and the quote. Your organization pays for Auth0 licensing during any period when both systems run, for the Auth0 support request, for the infrastructure that hosts Zitadel and its PostgreSQL database, and for internal staff time on application testing. A DeployOpen engagement is fixed scope, so the quote follows from a written list of users, applications, tenants, connections, custom logic and cutover approach. Export, mapping, batch import, application repointing and testing are one-time work. Hosting, patching, upgrades and any support agreement recur. Zitadel's core moved to the GNU Affero General Public License 3.0 with v3.0, so have counsel confirm the obligations that apply if you modify the software. Ask every provider to price each of these items separately.
Before requesting a quote, produce three lists: users by tenant with password status, applications with redirect URIs and grant types, and connections with any custom logic attached. These lists also set the batch plan. Imports should run in batches sized to your team's test capacity, and each batch should be checked against a sample of real sign-ins before the next one starts. Repointing applications comes last, and each application should have a tested rollback path that returns it to Auth0 without user data loss. Schedule the Auth0 subscription end date only after every application has run in Zitadel for a period your team agrees is sufficient.
Which Auth0 concepts map to Zitadel and which need redesign
This table pairs each Auth0 concept with its closest Zitadel counterpart and marks where the move is a redesign rather than a direct copy. Read the rows as a checklist: the mapped concepts are where your existing setup carries over, and the redesign rows are where your team needs decisions before importing anything. Treat Actions and rules as the main open item until each one is inventoried.
| Auth0 concept | Zitadel counterpart | What to plan |
|---|---|---|
| Tenant tied to applications | Instance, with organizations inside it | Zitadel instances give full data isolation, so decide whether one instance or several fits your tenancy model before mapping applications. |
| Applications and connections | Projects that group applications, roles and grants | Map each Auth0 application to a Zitadel project and application, then confirm which identity providers each one may use. |
| Users and their metadata | Users within an organization, with custom metadata to confirm | Confirm which user attributes and metadata fields your applications read, then check how each one is stored and imported in Zitadel. |
| Password hashes | No direct equivalent carried over by default | Hashes are not in standard exports. Request bcrypt hashes from Auth0 support or plan forced resets, as described in the password section of this page. |
| Roles and permissions | Roles and grants on projects | Rebuild Auth0 role assignments as Zitadel project roles and grants, and confirm how each application reads role claims in tokens. |
| Actions and rules | Rebuilt logic, such as Zitadel actions or application code, to confirm | Inventory every Action and rule, classify each as token enrichment, login flow or data sync, and confirm the Zitadel mechanism for each before cutover. |
| Enterprise connections | Identity provider federation over OIDC, SAML, LDAP or other supported protocols | Each customer organization can use a different identity provider, so map connections per organization and verify attribute mapping with each provider. |
| Universal Login customizations | Hosted login with its own branding and flow settings | Login pages, branding and custom prompts need redesign and retesting, since templates and hooks do not transfer one to one. |
Documented migration paths and export options
Zitadel documents its own path for moving from Auth0, so that guide is the starting point for every decision on this page. The cards below cover the migration methods, the export and import interfaces, the merge and batching tool, and the API work that connects them.
Zitadel's Auth0 migration guide
Zitadel publishes a migration guide for Auth0, and it should be the first document your team reads. Compare its steps, prerequisites and ordering against your Auth0 tenant, your identity needs and the Zitadel version you plan to run. Record every step the guide assumes you have already done, such as creating the Zitadel instance, organizations and projects, so nothing is discovered mid-cutover. Check the guide again on the day you plan, because migration docs change between releases.
Bcrypt password hashes from Auth0
Standard Auth0 exports do not include password hashes. The Zitadel guide says you can open an Auth0 support ticket to obtain them in bcrypt format, which lets users keep their existing passwords. Start that request early, because the turnaround depends on Auth0, not on your project plan. If support does not provide the hashes, users must set a new password at first login, so plan the communication and help desk load for that case.
Just-in-time migration
Zitadel lists just-in-time migration among its documented migration methods. Users are moved to Zitadel as they sign in, which spreads the load over time and avoids a single bulk cutover. Confirm from the guide whether this method needs the Auth0 tenant to stay active, which credential checks it performs, and how it handles users who never return. Decide whether your applications can tolerate a mixed period where some users are in Auth0 and others are already in Zitadel.
Export and import interfaces
The guide describes the export and import interfaces used to move user records. Map each exported field to its Zitadel counterpart before you export anything, including profile attributes, email verification status, custom metadata and any roles. Note which data cannot move in the same form, such as enrolled multi-factor methods, and decide whether users re-enroll. Test a small export end to end on a staging instance so field gaps surface early.
Merging exports and batching imports
The guide references a migration tool for merging exports and batching imports into Zitadel. Use it to combine partial exports and split large user sets into manageable imports, which makes failed batches easier to rerun. Before you plan around it, confirm its current name, version and expected input format in the Zitadel guide, since these details change. Record which batch sizes and error outputs you observed on staging so the production run has a baseline.
Scripting imports and repointing with APIs
Zitadel's APIs are the supported way to script imports and to repoint your applications from Auth0 to Zitadel. Scripts give you repeatable runs, logs and a clear record of what changed. Use a service account with only the permissions the import needs, and design scripts so they can be rerun without creating duplicate users. Confirm the exact API calls against the current Zitadel API documentation for your version, and test the repointing steps against a staging copy of each application.
Why Auth0 password hashes decide the migration approach
Auth0 password hashes are not included in a standard user export, and that gap determines how you move users to self-hosted Zitadel. The migration guide documents two paths. In the first, you open an Auth0 support ticket to request the password hashes in bcrypt format, which lets users keep the passwords they already use. In the second, users are imported without hashes and must set a new password at first login. Decide between these paths before you schedule any import, because the choice changes the user communication, the support plan and the fraud controls you need for the cutover.
For your users, the difference is visible on the first day. With retained hashes, a user signs in to the new Zitadel login with the same password and notices little beyond a changed login page. With forced resets, every user must complete a reset flow before they can work, and the reset email or verification step becomes the most common point of failure. If you have a large or mixed user base, including customers who sign in rarely, plan for users who never complete the reset and decide how long their accounts remain available or how they recover access.
Support load follows the same split. Forced resets concentrate tickets in the first days after cutover: users who cannot find the reset email, mistyped addresses, expired links and accounts locked by repeated attempts. A retained-hash path shifts the load to the request phase, where the ticket to Auth0 must be raised, answered and tracked against your cutover date. Auth0 support processes, response times and any plan conditions that apply to exporting hashes can change, so confirm the current process directly with Auth0 before you commit to a date or a user notice. Do not treat a support answer you received in an earlier project as current.
Fraud exposure is the risk that most often goes unplanned. A forced reset is a password change, so attackers who hold stolen credentials or who target recently migrated accounts can use the reset flow to take over accounts. Retained hashes avoid the reset but still deserve review: the exported hash file is sensitive and must be handled, stored and deleted under your data controls, and imported users should be monitored for unusual sign-in patterns in the first weeks. Whichever path you choose, agree on rate limits, multi-factor expectations for high-risk accounts and an incident contact before the first batch runs.
Before you commit, write down three answers: whether Auth0 will provide bcrypt hashes for your tenant under your current plan, how long that request takes in your region, and what your users will be told at each stage. If the answer to the first question is unclear, plan the forced-reset path as the fallback and keep the choice open until the Auth0 response is in writing.
Migration sequence from inventory to decommission
This sequence moves users, applications and password handling from Auth0 to self-hosted Zitadel in controlled stages. It ends with Auth0 decommissioned after a retention period your organization sets, with reconciled identity records and a documented cutover.
Inventory tenants, connections and applications
Build the inventory with your Auth0 administrators and application owners. List every tenant, connection (database, social and enterprise), application, custom Action and user count. For each application, record its owner, login methods, redirect URIs and the claims it reads, then map it to a Zitadel instance, organization, project and application. Each custom Action needs a decision: re-create its logic in Zitadel or retire it with the owner's agreement. The step is done when application owners have signed off the inventory and every item has a target and a disposition.
Pilot with a small application set
Choose a few low-risk applications and a group of test users who represent each login method in the inventory. Import only that group into Zitadel and configure the pilot applications against it. Test password login, passkey enrollment where it applies, token contents, role assignments and sign-out behavior. Log every defect with its cause and fix it before widening the scope. The step is done when the pilot sign-in and claim checks pass for each pilot application and the open issues are recorded with owners.
Decide and request the password credential path
Auth0 password hashes are not included in standard exports. Zitadel's Auth0 guidance describes two paths: open an Auth0 support ticket to download hashes in bcrypt format, or require every user to set a new password at first login. The security owner chooses the path, confirms that bcrypt meets your password policy, and records the decision. If you choose the support path, submit the request early, since its turnaround is set by Auth0 and not by your project. The step is done when the decision is documented and any request is confirmed in writing.
Import users in batches and reconcile
Merge the Auth0 exports with the migration tooling described in Zitadel's Auth0 guide, then import in batches rather than in a single run. After each batch, reconcile the counts against the inventory: total users, users per connection, email addresses, external identifiers and rows that failed. Investigate every mismatch and fix the source data before the next batch. Keep the reconciliation reports as evidence. The step is done when each batch's counts and identifiers match the inventory and every exception has a recorded resolution.
Repoint applications and run a parallel period
Change each application's configuration to use Zitadel while Auth0 stays active, so that users can authenticate against either system during a defined parallel period. Compare sign-in success, error rates, token claims and session behavior between the two systems for each application. Confirm that users who have not yet moved to Zitadel can still sign in through the existing Auth0 path. The step is done when every application has passed functional tests on Zitadel and the parallel-run results are reviewed and accepted by its owner.
Cut over with a tested rollback plan
Announce the cutover window, freeze configuration changes and switch the remaining applications to Zitadel. Before the window opens, document how to revert each application to Auth0, which settings change back, and who decides to invoke the rollback. Rehearse the rollback on the pilot applications so the steps are known to work. Monitor sign-in errors and support volume after the switch. The step is done when all applications authenticate through Zitadel, the rollback plan has been rehearsed, and the cutover is signed off by the business owner.
Decommission Auth0 after the retention period
Keep Auth0 in a read-only state for the retention period your organization sets, which should reflect records, audit and legal obligations you confirm with your compliance team. At the end of that period, export the final logs and configuration you are required to keep, remove API credentials, disable connections, delete Actions and close the tenant. Record each decommissioning action in a checklist with a named approver. The step is done when the checklist is signed and Auth0 no longer accepts sign-ins or holds active credentials.
What drives the cost and duration of an Auth0 migration
The table lists the factors that change how much work an Auth0 to Zitadel move takes, marks which ones are paid once and which recur, and names what to request in a written quote. Use it to compare your environment against each driver before asking for a scope.
| Driver | Why it changes cost or effort | What to ask for in a quote |
|---|---|---|
| Users and password hashes | Volume sets export, merge and import time. Whether Auth0 support provides bcrypt hashes decides if users migrate silently or must reset passwords at first login. | Confirm the user count, whether a hash request to Auth0 support is in scope, and the fallback plan for users without hashes. |
| Applications and OIDC or SAML settings | Each client needs its redirect URIs, grant types, token settings and secrets mapped to a Zitadel project and application. SAML service providers need separate metadata work. | A per-application inventory with protocol, grant types and owner, and the count of OIDC versus SAML integrations. |
| Auth0 Actions and rules | Custom login logic has no direct import path. Each Action or rule must be read, rewritten as Zitadel behavior or an external step, and tested. | The number of Actions and rules, their triggers, and which ones call external services. |
| Enterprise connections | Each SAML or OIDC enterprise connection must be rebuilt as a Zitadel identity provider, and each customer organization may need its own mapping and attribute checks. | A list of connections with protocol, customer owner, and whether the customer must update its own identity provider settings. |
| Multi-tenant customer organizations | Auth0 organizations map to Zitadel organizations inside an instance. Membership, roles and per-tenant login rules must be recreated and verified per tenant. | The tenant count, membership volume, and whether tenants need separate identity providers or branding. |
| Branding and hosted login | Custom login pages, themes and domains must be rebuilt for the self-hosted login UI, and each brand adds review and testing time. | The number of brands, custom pages, and whether custom domains and email templates are included. |
| Integrations reading Auth0 user data | Systems that call the Auth0 Management API for profiles, roles or metadata must be repointed to Zitadel APIs or to a replacement store. | An inventory of services that call Auth0 APIs, with the data each one reads and writes. |
| Compliance evidence | Access reviews, change records, configuration exports and sign-in logs need to be collected from both the old and new platforms. Evidence needs widen the scope of testing. DeployOpen prepares evidence but does not issue audit reports. | The control frameworks in scope, the evidence list, and who the independent auditor is. |
| Parallel run length (recurring until cutover) | Running Auth0 and Zitadel side by side means two platforms are operated, monitored and kept in sync for the length of the run. Running cost depends on the length of the run and the infrastructure you control. | The planned length of the parallel run, the sync method for changes made during it, and who owns the old tenant after cutover. |
What usually goes wrong in Auth0 to Zitadel moves and how to prevent it
Auth0 to Zitadel moves tend to fail at the edges: password hashes, identifiers, claims, and the Auth0 pieces nobody remembers. Each card below names one failure pattern and a single prevention step to take before cutover. Work through them in order, because several depend on decisions made during the export and mapping phases.
Password hashes requested late or not at all
Auth0 does not include password hashes in standard exports. Zitadel's Auth0 guide says the hashes must be requested from Auth0 support in bcrypt format, or users must set a new password at first login. Open the support request at the start of planning, not the week before cutover, and confirm the format and delivery method in writing. If the hashes do not arrive in time, decide now which user group will be forced to reset passwords.
Users locked out at cutover
Users who cannot sign in on cutover day generate most of the support load in an identity move. Lockouts usually come from missing password hashes, unverified email addresses, or accounts that were imported but not linked to the right organization. Run a full sign-in test with a sample of real accounts from each user group on the staging instance. Agree a rollback path with the application owners before the production switch.
Mismatched user identifiers
Auth0 user IDs, such as those prefixed with the connection name, do not map automatically to Zitadel user IDs. Applications that store the Auth0 subject claim in their own databases will fail to match users after the move. Build a mapping table from the Auth0 export to the Zitadel IDs during import, and decide whether applications will key on email, an external ID, or a new subject. Test that mapping against one application before the rest.
Claims and roles that differ
Auth0 roles, permissions and custom claims are often added through rules, Actions or Auth0 authorization extensions, and their names and shapes do not carry over unchanged to Zitadel. Zitadel organizes access through projects, roles and grants, so a role that worked as a flat claim in Auth0 may need a different grant structure. Export a token from every application in Auth0, compare its claims with the token issued by Zitadel, and document each difference before development starts.
Forgotten Auth0 Actions
Auth0 Actions often run logic at login, such as enriching tokens, syncing profiles to a CRM or enforcing terms acceptance. These run inside Auth0 and do not move with the users, so their behavior can disappear silently after cutover. Inventory every Action, trigger and enabled flow in the tenant, then assign each one a owner and a replacement in Zitadel, or document why it is retired.
Redirect URI and token audience errors
Applications registered in Auth0 use redirect URIs and API audiences that must be recreated exactly in Zitadel. A trailing slash, a changed hostname or a missing audience produces login loops or tokens that resource servers reject. Build a table of every client, its redirect URIs, logout URIs, and API audience, then verify each one against the Zitadel configuration and a live token inspection in staging.
Decommissioning Auth0 too early
Teams sometimes cancel or disable the Auth0 tenant as soon as the import succeeds, which removes the fallback path during the parallel run. Keep Auth0 active, with logins still possible for at least the period agreed in the plan, until discrepancies in sessions, claims and password resets are closed. Confirm with the business owner the exact condition that allows decommissioning, and record it in the cutover runbook before the parallel run begins.
What changes for your users, developers and support team
The most visible change for end users is the sign-in step. Auth0 password hashes are not included in standard exports. The Zitadel migration guide describes two routes: open an Auth0 support ticket to download the hashes in bcrypt format, so users keep their current passwords, or accept that users must set a new password at first login. Confirm which route your Auth0 tenant and contract allow, how long the support request takes, and how many accounts would fall into the forced reset group, because this decision sets the size of your reset workload. Tell users before cutover that the sign-in page and possibly the domain will change, and that accounts without imported hashes will be asked to create a new password. Check that branding, languages and sign-up screens configured in Auth0 have equivalents in Zitadel.
Passkeys are the main way to reduce the reset burden. Zitadel supports passkeys based on FIDO2 and WebAuthn and falls back to password login, so you can offer passkey enrollment without removing the password for users who are not ready. A practical approach is to prompt for passkey registration after a successful password sign-in, so the cutover itself stays predictable. Decide in advance whether administrators must use a passkey or second factor, whether users may skip enrollment, and how existing Auth0 MFA enrollments and login conditions will be recreated. Confirm that your browsers, managed devices and corporate authenticator policies support WebAuthn, and test the fallback path, because a user who loses a passkey still needs a supported way back into their account.
Developers change more than the client identifier. Each application needs the new issuer URL, client credentials, redirect and logout URIs, and the scope and audience values that Zitadel expects. Token validation is where regressions usually appear. Libraries that pin the Auth0 issuer or key endpoint will reject Zitadel tokens until they are updated, and custom claims added through Auth0 Actions or rules must be rebuilt, either as role claims tied to projects and grants in the target organization or through the customization mechanism your Zitadel version provides. Confirm refresh token lifetimes, session timeouts and logout behavior in each application, and run a staging test with an account from every role. Keep the Auth0 tenant reachable until each application has been verified in production.
The support desk needs runbooks written against the new system before the first user calls. Agents should know which organization and project a user belongs to, how to tell an account imported with a password from one waiting for a forced reset, and what to do when a reset email fails or lands in spam. Cover passkey lockouts, lost second factors, email address changes and users who sign in through a federated identity provider and therefore have no local password. Define escalation to the platform team for failed imports, mismatched user identifiers and token errors reported by applications. Record the migration batch each user came from, since that answers many questions quickly. Ask your team to confirm the administrator console access model, audit log retention and who is permitted to reset credentials before the scripts are written.
Questions buyers ask before moving from Auth0 to Zitadel
How much does an Auth0 to Zitadel migration cost?
The cost depends on the written scope, and DeployOpen does not publish a price list, so the quote follows from the scope you agree before work starts. The main components are discovery of your Auth0 tenants, applications, rules or actions and custom logic; export and transformation of users, roles and organizations; deployment of Zitadel in your infrastructure; repointing each application to Zitadel; testing; and cutover support. Most of this is one-time project work. Recurring costs sit outside the migration itself: hosting, PostgreSQL operations, and any support agreement or retainer you choose. Costs rise with the number of applications, the amount of custom login logic, the number of users who need a special password path, and the number of environments. Ask for a quote with line items per phase, stated assumptions, who performs each task, exclusions, and recurring costs shown separately.
How long does an Auth0 to Zitadel migration take?
The duration is set by the scope, and no fixed timeline applies to every tenant, so ask for a schedule as part of the written scope. The main drivers are the number of applications and how many need changes to their login code, whether password hashes can be moved (which decides whether users reset passwords at first login), the number of Zitadel organizations you need to model, and how many environments must be built and tested before cutover. Access also matters. Requests to Auth0 support, approvals for a production change window, and the availability of your application owners can add elapsed time that the project team does not control. Ask for a plan that lists phases, dependencies, and the points where your team must act, and confirm which steps run in parallel.
Can Auth0 password hashes be moved to Zitadel?
Auth0 password hashes are not included in standard user exports, so you cannot move them by exporting users alone. Zitadel's migration guide for Auth0 says you can open an Auth0 support ticket to download the hashes in bcrypt format, and the import can then keep existing passwords. If Auth0 does not provide the hashes, users must set a new password at their first login, which needs a communication plan and a way to handle users who never return. Confirm the support ticket route and its outcome with Auth0 before you commit to a timeline, because the answer determines the user experience and the cutover plan. The guide also describes just-in-time migration as an approach, so check its steps and whether it fits your tenant and applications.
What does an Auth0 migration need from our team?
The work needs named owners on your side, and the schedule depends on their availability. Typical inputs include an identity owner who approves the user model, organization design and cutover; an owner for each application who confirms redirect URIs, token claims and roles; platform engineers who provide hosting, network access, backups and secrets handling for Zitadel; a database administrator for PostgreSQL; and a security approver for data handling and the production change. Someone must hold Auth0 tenant admin access and own the support ticket for password hashes. You also need test users in each environment, a sign-off process for test results, and a cutover window that application teams can support. Ask the partner to list these roles by name in the written scope.
Can our in-house team migrate from Auth0 to Zitadel alone?
Yes, if your team has the skills and capacity, and the documentation covers the main path. Your engineers need working knowledge of OpenID Connect and OAuth 2.0, the ability to run PostgreSQL and a Docker Compose or Kubernetes deployment, and experience changing application authentication code. The hardest parts are usually the password hash decision, repointing each application without breaking sessions or tokens, handling users who do not complete a reset, and planning rollback at cutover. Estimate the effort by inventorying applications and custom Auth0 logic first, then compare that list with your team's available hours. A split model also works, where your team changes the applications and an outside team handles the migration tooling and hardening. Ask any partner to show which parts it would hand over and which it keeps.
Do Zitadel hosting and support plans change the migration plan?
They can change the deployment and support scope, but they do not replace the migration work. Zitadel documents self-hosting on Linux and macOS binaries, Docker Compose and Kubernetes, and recommends Kubernetes with the official Helm chart for high availability, so your choice affects how the environment is built and operated. Zitadel's pricing page lists a Free plan at US$0 per month and a Pro plan at US$100 per month for its cloud service, while the Enterprise plan has custom pricing for self-hosted or cloud deployments. The Enterprise plan includes custom support agreements and technical account management. Confirm with Zitadel which terms apply to your deployment, what the support scope includes, and how a support plan affects your cutover and post-cutover operations. Also check licensing with your counsel, since Zitadel's core moved to AGPL 3.0 with v3.0 on 31 March 2025.
How does DeployOpen scope a fixed quote for this migration?
DeployOpen scopes the migration in writing before work starts. Most engagements are fixed-scope, so the quote follows from the agreed scope, deliverables and timeline. The scope usually starts with an inventory: your Auth0 tenants and environments, applications and their login flows, custom rules or actions, user count and how users are split across organizations, the password hash decision, and the cutover approach. Those findings become the work breakdown, with the responsibilities for your team written beside those for DeployOpen. Ask for the quote to list deliverables, assumptions, out-of-scope items, how change requests are handled, and recurring costs for hosting and support. A fixed scope is only as firm as its assumptions, so review each assumption before you sign.
How DeployOpen scopes and delivers an Auth0 to Zitadel migration
DeployOpen plans and delivers Auth0 to Zitadel migrations as fixed-scope engagements inside infrastructure you control. The written scope fixes the user population, applications, password handling and cutover approach before any import runs.
How we scope
- Inventory Auth0 tenants, applications, connections, rules or actions, and custom domains to define what moves.
- Confirm with Auth0 support whether bcrypt password hashes can be downloaded, since standard exports omit them.
- Record the fallback path, forced password resets at first login, for any user whose hashes cannot be obtained.
- Agree in writing how Auth0 organizations and roles map to Zitadel instances, organizations and projects.
How we build
- Stand up self-hosted Zitadel and its PostgreSQL database on the deployment method your platform team selects.
- Merge the Auth0 user exports with the password hash data using the migration tool, then validate record counts and fields.
- Import users in batches and reconcile each batch against the source before the next one starts.
- Repoint each application to Zitadel endpoints and test sign-in, token claims and role grants in a staging environment.
How we hand over
- Document the migration runbook, batch logs, reconciliation results and rollback steps for your team.
- Walk through the Zitadel configuration, including instance, organization and project structure, with your operators.
- Deliver the cutover plan with the sequence for repointing applications and monitoring sign-in errors.
- Record open items, such as users awaiting first-login resets, so your team owns them after the engagement closes.
How we support
- Support after cutover is available as a retainer, covering troubleshooting, upgrades and configuration changes.
- Confirm with the vendor which Zitadel release line and support terms apply to your deployment before you commit.
- Ask for the support scope, response expectations and escalation path in the written quote.
- Plan Zitadel upgrades and PostgreSQL version alignment as recurring work, not one-time tasks.
