What you can export from Auth0 and what you cannot
User profiles can leave Auth0 as bulk export jobs in NDJSON or CSV, started from the Dashboard or through the Management API create export users job (POST /jobs/users-exports). Password hashes do not come out in that standard export. 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. If your renewal or pricing change lands before that request is answered, plan for users to reset passwords on the new platform. Confirm your plan tier and open the ticket early, because the hash path is the only route the vendor documents for keeping passwords.
Treat the documented paths as the boundary of what you can rely on. The bulk export covers user records, and the hash export covers the stored hashes only if Auth0 approves the request. Tenant configuration is a separate matter. Connections, applications and their callback settings, Actions and Rules logic, Organizations, roles and custom domains must be inventoried and rebuilt by hand or through your own scripts from the Management API or tenant settings. Auth0's bulk user export documentation and its data export guidance set out the supported scope, so read them against your tenant before you write migration tooling.
Build a short inventory before you commit to a date: the number of users, which connections they log in through, whether any hashes are needed, and every application and Action that depends on user claims. Ask Auth0 in writing what the hash export contains and what format it uses, since the target platform must be able to verify those hashes. Any gap you find becomes a decision to make now: accept password resets, keep a bridge that verifies logins on first use, or stay on Auth0 longer. Each choice changes the timeline, so record it in the migration plan.
Which Auth0 data exports, by method and format
This table compares the Auth0 export routes for user profile data: the create export users job through the Management API, the Dashboard export, and the separate password hash request. Read it to choose a route and to see which data each one leaves out, then check the Auth0 bulk export documentation for current field lists and limits before you plan the run.
| Export route | Formats | What it covers | Points to check before use |
|---|---|---|---|
| Create export users job (POST /jobs/users-exports) | NDJSON or CSV | Bulk user profile data as the documented bulk path for migration | Confirm field lists, job limits and retention in the bulk export documentation |
| Dashboard user export | NDJSON or CSV | Profile data for users in the tenant, run from the Auth0 Dashboard | Confirm the same field list as the API job and who in your team can run it |
| Management API user search | JSON responses | Per-user records queried through the API, useful for spot checks | Paginated reads are slower than a bulk job for full tenant exports |
| Password hash export | Support-issued export | Stored password hashes, needed so users keep their current passwords | Requires a support ticket on paid plans, is not available on the Free tier and has no guaranteed delivery date |
| Tenant configuration | Not exported by the user job | Connections, applications, Actions, Rules and Organizations must be documented and rebuilt | Plan manual or scripted recreation in the target identity provider |
What does not come out in the standard export
The bulk export moves user records, but a working tenant is more than its users. Password hashes sit behind a separate request, and much of the configuration that makes logins work is not listed as bulk-exportable. Plan for each item below before you set a cutover date.
Password hashes
Auth0's standard user export leaves out password hashes. On paid plans, you request a password hash export through a support ticket, and Auth0 does not guarantee a delivery date. The option is not available on the Free tier. Confirm early whether your plan qualifies, and ask support for the hash format and the delivery method. Without hashes, every user must reset a password after cutover, so the request should start in the first phase of the project.
Social and enterprise connections
Database, social and enterprise connections hold the OAuth client secrets, SAML certificates and attribute mappings that let users sign in with Google, Microsoft or a customer's identity provider. The user export does not carry these secrets. Record each connection's settings from the Dashboard, and ask each customer's IT team for their metadata and client registration details, since you may need to re-register the application with the upstream provider.
Applications and API definitions
Client IDs, allowed callback and logout URLs, grant types, token lifetimes and API audiences are tenant configuration, not user data. Each application's client secret is also not part of a user export. Export the list through the Management API where documented, then recreate the applications in the target realm or instance. Compare redirect URIs carefully, because a single mismatch blocks every login for that application.
Actions, Rules and hooks
Login logic written as Actions, legacy Rules or hooks runs as code inside Auth0 and is not carried over by the user export. Copy the source from the Dashboard, list the secrets and environment variables each one reads, and map each behavior to a target mechanism such as an identity provider script, a custom claim or a flow step. Treat this as a code migration with its own tests, not a copy-and-paste step.
Roles, permissions and organizations
Role definitions, API permissions and the assignment of roles to users determine what each token contains. Role-to-user assignments may appear in some exports, but role definitions and their permission sets must be read from the Management API or recreated by hand. Organization membership and per-organization connections also need their own check, because a user in the wrong organization can see another customer's application.
Branding, templates and custom domains
Login page branding, email templates, custom domains and tenant settings such as session lifetimes and MFA policies are configuration rather than data. None of these are listed as bulk-exportable in the documentation. Capture them as screenshots and API reads, then ask Auth0 support to confirm which settings can be read programmatically for your plan. Custom domain certificates and DNS changes must be planned with your own team.
The export sequence and how to verify each stage
This sequence turns a live Auth0 tenant into a set of user, configuration and password hash files that you hold in your own storage and have confirmed are readable before anything in the tenant changes. Each stage ends with a check you can run yourself.
Inventory the tenant and record its configuration
Before exporting any users, the tenant owner lists every application, API, connection, Action, Rule, role, hook and custom domain in the Auth0 Dashboard, and saves the settings for each one. Auth0 user exports carry user profiles, not tenant configuration, so this inventory is the only record of how logins were built. Keep it as a dated document in your own repository. It is complete when every application and connection has a row with its client settings, callback URLs and enabled status, and a second engineer can read the list without opening the Dashboard.
File the password hash request early
Password hashes are not part of the standard user export. On paid plans, the tenant owner opens a support ticket asking for the password hash export, and Auth0 does not guarantee a delivery date. Filing this request at the start means the hashes can arrive while you complete the other stages. Confirm with Auth0 whether your plan and tenant qualify, and ask what format the hashes are delivered in and how they are transferred to you. The step is done when you hold a written ticket reference and a confirmed delivery method. If your plan is on the Free tier, this option is not available, so plan for password resets instead.
Run the user export job in the chosen format
The tenant owner runs the bulk export from the Dashboard or starts a create export users job through the Management API at the users-exports jobs endpoint, choosing NDJSON or CSV. NDJSON keeps nested fields such as metadata intact on one record per line, while CSV is easier to open in a spreadsheet but flattens some structures. Choose the format before you start, because the downstream import tooling must read it. The job runs asynchronously, so record the job ID and the status until it completes and the file is available. The step is complete when you have a downloaded file and its job record.
Check record counts and sample fields against the Dashboard
Compare the number of lines in the NDJSON file or rows in the CSV file with the user count shown in the Dashboard for the same tenant. Then pick a sample of users, including one with metadata, one with a social connection, one with multiple identities and one with a blocked status, and compare their email, user ID, connection, creation date and last login fields with the Dashboard entries. A mismatch in count or in any sampled field means the export is incomplete or was taken before a change, so rerun the job before continuing. The step is complete when the counts match and every sampled record agrees.
Store the files encrypted in your own storage
Move the user export, the configuration inventory and, when it arrives, the password hash file into storage you control, such as an encrypted object store or a volume in your own cloud account. Encrypt each file at rest and restrict access to the named migration team. Write down the checksum of each file when it lands so you can detect corruption or tampering later. Ask your security team to confirm the retention period and deletion plan for the working copies, since these files contain personal data and password hashes. The step is complete when each file has a recorded checksum and an access list in your storage.
Confirm every export file can be read
Before the tenant is changed or any users are moved, open each file with the tooling that will perform the import. Parse every NDJSON line or CSV row, confirm that the parser reports no errors, and recompute the checksums to match the values recorded at storage. Also confirm that the password hash file, if received, has one entry per expected user and matches the hash algorithm the vendor documented for it. The step is complete when a full parse succeeds on every file and the checksums match. Keep the parse log with the migration record, because it is the evidence that the files are usable if the import has to be repeated.
How the export files map to a target platform
The NDJSON or CSV file that Auth0 produces is a staging format, not a finished migration. It carries profile attributes and identifiers, but it does not carry password hashes in standard exports, so the file alone will not let users keep their existing passwords on a new platform. Before you run the export, map each field in the file to the target: the user identifier (for example, the user_id value Auth0 assigns), the email and verification flags, the metadata objects, and the identity entries that link a user to a social or enterprise connection. Any identifier you lose here becomes a broken link to an application or a duplicate account later. Keep the raw export files under access control, because they contain personal data even without hashes.
Each target platform has its own import model, so the mapping differs. Confirm with the vendor how the target stores external identity links and whether it can verify a hash format you request from Auth0. Both ZITADEL's migration guides and the Keycloak documentation describe their own approaches, including just-in-time migration, which can verify credentials on first login instead of loading every hash up front. Decide which approach fits your user base before you request the password hash export, because the support request is the slowest step and Auth0 does not guarantee a delivery date.
The import path itself, including the scripts, field transforms and login verification tests, is covered on the sibling migration pages for ZITADEL and Keycloak. Use this section to settle the mapping decisions first: which fields move, which identifiers are kept, and which users will need a password reset because no usable hash arrives. Ask your implementation partner or platform team to document that mapping in writing and test it on a copy of a small sample of users before any production run.
What to plan before the Auth0 contract ends
Exporting users is the easy part. The decisions that cause trouble are timing, parallel running and the login changes users will notice. Each card below names one of those decisions and what to confirm with Auth0 and in your commercial terms before you commit to a date.
File the password hash request early
Password hashes are not in standard user exports. On paid plans they come through a support ticket, and Auth0 does not guarantee a delivery date. Treat that request as the longest lead item in the plan. Ask Auth0 in writing what it needs from you, how it delivers the files, and what it will do if delivery runs past your contract end. Confirm whether your plan qualifies, since the option is not available on the Free tier.
Keep the tenant live in parallel
Plan for the Auth0 tenant to keep serving logins until the target has verified users, hashes and sign-in flows. Ask what your contract says about access after the end date, including read-only access, log retention and whether the tenant is deleted on a fixed schedule. A cutover that starts before verification is complete can lock users out with no fallback.
Rebuild applications and connections
Exported users do not carry your tenant configuration. Applications, client secrets, callback URLs, social and enterprise connections, Actions and Rules, custom domains and branding must be recreated in the target. Make an inventory of every application and connection that depends on the tenant before you sign the renewal, and assign an owner to each item. Confirm which of these Auth0 can export and which you must document by hand.
Test sign-in against the target first
Before any user moves, run test accounts through every login path in the target: password, passkey, MFA, social and enterprise sign-in. Check that the tokens your applications receive carry the same claims they used under Auth0. Ask your application owners to confirm the SDK or OIDC changes they need, because a claim mismatch often appears only after cutover.
Tell users what changes
Users may see a new login domain, a new consent screen, a password reset prompt if hashes do not verify, or a re-enrolled MFA device. Draft the notice, the support script and the fallback path with your communications and help desk teams before the cutover date. Confirm whether any user data, such as profile fields or MFA enrollments, will need a manual step.
Set retention for exported data
The export files contain personal data and, if you obtain them, password hashes. Decide where they are stored, who can access them, how long they are kept and how they are deleted once the migration is verified. Apply your own retention rules rather than the vendor's default. Check your data processing terms with Auth0 for what happens to data held in the tenant after termination.
Questions buyers ask before exporting from Auth0
Can our team export users from Auth0 without outside help?
Yes, a team with Auth0 administrator access can run the export itself. Auth0 offers bulk user exports through the Dashboard or the Management API create export users job (POST /jobs/users-exports), in NDJSON or CSV format. The harder part is what surrounds the file: mapping attributes to the target system, deciding which applications and connections move, rebuilding Actions or Rules logic, and testing logins. Those tasks need engineers who know both platforms, so the question is usually whether your team has that time and skill. Check the Auth0 bulk user export documentation before planning, since the export format and job limits determine the import work.
How does export effort grow with user count and connections?
The export job itself is usually the smallest part of the effort. Effort grows with the number of users to validate, the number of applications that depend on them, and the number of connections that carry identity data. Each database connection, social login, enterprise connection and custom database script adds mapping and testing work. Organizations, custom user metadata and roles add more import logic. Ask your team to inventory tenants, applications, connections, Actions, custom domains and user metadata before requesting a quote, because those counts drive most of the cost. The export tool does not measure this for you.
Can we get password hashes on the Auth0 Free tier?
No. Auth0 does not include password hashes in standard user exports, and the password hash export is available only to customers on paid plans, requested through a support ticket. The Free tier does not offer this option. Without hashes, users cannot sign in with their existing passwords after migration, so they must reset them or the target system must import them another way. Confirm your current plan and the request process in the Auth0 export data documentation before you plan user communication.
How long does the password hash request take?
Auth0 does not guarantee a delivery date for password hash exports. The request goes through a support ticket, so the timing depends on Auth0's support process rather than on your schedule. Plan the migration so that the hash export is one dependency among several, and avoid fixing a cutover date until you have the file and have verified it in a test environment. Ask Auth0 support to confirm the expected handling for your tenant when you open the ticket, and keep your existing tenant running until the export is complete.
Do we need a consultant to migrate from Auth0?
Not always, but a consultant is worth considering when the tenant has many connections, custom Actions, or strict audit requirements. Teams with experienced identity engineers often handle small tenants in-house. Outside help usually covers planning the cutover, mapping data models, reproducing login flows, testing token claims and documenting evidence for compliance reviews. DeployOpen plans, implements, integrates and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with agreed deliverables and timelines in writing before work starts. DeployOpen does not issue audit reports or certifications.
What tenant configuration must we recreate after export?
A user export does not carry the full tenant configuration, so several items must be rebuilt in the target system. The usual list includes:
- Applications, client credentials, callback URLs and allowed origins
- Social and enterprise connections, recreated as identity providers
- Actions or Rules that enrich tokens or enforce logic
- Roles, permissions, organizations and their members
- Branding, custom domains, email templates and MFA policies
None of these items moves with the user file. Inventory each one from the Dashboard before cutover, because a missing callback URL or claim can break sign-in for every application at once.
What should a quote for this export include?
A useful quote states the scope in writing, so you can compare it with other options on the same basis. Ask for these elements:
- The tenants, applications, connections and Actions included
- Whether password hash handling and user communication are in scope
- Test environments, cutover steps and rollback plan
- Deliverables such as configuration records, runbooks and evidence
- Post-cutover support, and any retainer for upgrades
Cost components are the time for discovery, mapping, build, testing and cutover, plus infrastructure and any ongoing operations after go-live. DeployOpen does not publish a price list, and a quote follows from the written scope.
What changes for your users and your team after export
Expect some user-visible change after export. Auth0 leaves password hashes out of standard user exports, so unless you obtain the hash export through a support ticket on a paid plan, users will likely need to reset their passwords on the new platform. Auth0 does not guarantee a delivery date for that ticket, so confirm the request status early and plan the cutover around it rather than assuming hashes will arrive in time. Decide in advance how users will be told, which login method they will see first, and whether passkeys or social logins will cover accounts that never had a password. Be careful with any promise of zero disruption, because the export does not carry everything a user experiences at login.
Application teams will also have work to do. Applications built on Auth0 SDKs need to move to standard OpenID Connect flows that the target platform, such as Keycloak or ZITADEL, supports, and each client registration, redirect URI and token audience must be recreated and tested. Login pages hosted by Auth0 will not follow the users, so the team must build or configure a replacement login experience and check every flow it handles, including sign-up, MFA enrollment and account recovery. Tokens issued before cutover will stop matching the new issuer, so session lifetimes and refresh handling should be checked with the application owners.
Internal owners need to be named before the cutover. Someone should own the inventory of Auth0 tenant configuration that exports do not capture, including social and enterprise connections, Actions or Rules, custom domains, branding and email templates. Someone else should track which applications and token consumers depend on each connection and claim, and sign off on the change. Support staff need a script for password resets and locked accounts, and security staff should review how sessions and tokens from the old tenant are revoked. Ask your implementation partner or platform vendor to put these ownership decisions in writing before work starts.
How DeployOpen scopes an Auth0 exit
The engagement starts with a written scope that inventories what sits in the Auth0 tenant and ends with verified exports and a target configuration ready for the new identity platform. Each step closes with a named output so both sides can confirm progress against the agreed scope.
Inventory the Auth0 tenant
DeployOpen reviews the tenant with your team and lists what it holds: user populations, database connections, social and enterprise connections, Organizations, applications, APIs, roles, Actions, Rules, hooks, branding and custom domains. Your team confirms which applications and user groups are in production and which are retired. The output is a written inventory that becomes the basis of the scope, and it is agreed before any export runs.
Agree the scope and target platform in writing
Both parties document the target platform, whether self-hosted ZITADEL or Keycloak, the hosting location in your own infrastructure, the migration approach for users, and the items in scope and out of scope. Ask for a written quote that follows from this scope, and confirm who on your side approves the password hash request to Auth0. The output is a signed scope document with deliverables and acceptance criteria, agreed before work starts.
Run the user export and record its format
DeployOpen runs the bulk user export job from the Auth0 Dashboard or the Management API, using the create export users job (POST /jobs/users-exports) in NDJSON or CSV format, and stores the file in a controlled location within your environment. The export is confirmed to be complete when the job reports its status and the file is retrieved. The output is a dated export file with a recorded record count and the format used, which the later steps check against.
Request password hashes through support
Standard exports do not include password hashes. If your plan supports it, your team or DeployOpen raises a support ticket with Auth0 to request the password hash export. Auth0 does not guarantee a delivery date, and this option is not available on the Free tier, so confirm eligibility before planning. Where hashes are not available, the plan must use another path, such as just-in-time migration or password reset. The output is either the hash file or a documented decision to proceed without it.
Verify the exported users
DeployOpen checks the export against the inventory: record counts, required fields such as email and user identifiers, social and enterprise identity links, custom metadata, and the separation between users who have hashes and users who do not. Sample records are compared against the live tenant. Discrepancies are logged and resolved with your team before import. The output is a verification report that lists any gaps and how each was handled.
Recreate tenant configuration on the target
The items that do not travel in a user export are rebuilt on the target: applications and client registrations, scopes and roles, identity provider connections, Organizations or their equivalent, branding, and login flows that replace Actions or Rules. Each item is mapped to its target object in the written scope. The output is a configuration record that lists each Auth0 item, its target equivalent and the test that confirms it.
Test the import and sign-in paths
DeployOpen imports the verified users into a staging instance of the target, then tests sign-in for each user population, password and passwordless paths, social and enterprise logins, and token contents for each application. Your application teams confirm their OIDC integration against the new issuer. The output is a test log with pass or fail results for each path, and a cutover checklist that only moves forward when every agreed test passes.
Hand over and document the migration
DeployOpen delivers the migration record, including the export files and their handling, the verification report, the configuration mapping, the test log and the cutover notes. Your team takes ownership of the target platform, and any ongoing support, upgrades or testing are handled under a separate agreement. The output is a handover package that your auditors or security reviewers can read without the engagement team present.
How DeployOpen supports data export and exit from Auth0
DeployOpen treats the export from Auth0 as one part of a planned exit, not a single download. We scope the export jobs, the password hash request, and the tenant configuration that has to be rebuilt in the target identity platform, then deliver the work inside your own infrastructure. Engagements are fixed-scope, with the scope agreed in writing before work starts.
How we scope
- We inventory which user fields, metadata and connections your Auth0 tenant holds before choosing an export method.
- We confirm your Auth0 plan tier, since password hash exports depend on a paid plan and a support request.
- We list tenant configuration to recreate, such as applications, connections, Actions and Organizations, in the written scope.
How we build
- We run the users export job through the Dashboard or the Management API and validate NDJSON or CSV output against a record count.
- We prepare import tooling for the target platform and test it on a copy of the exported data in your environment.
- We document field mappings, hash handling and any users who will need a password reset or a fallback login path.
How we hand over
- We deliver runbooks covering each export step, the import sequence and the rollback path for your team.
- We record the export evidence and reconciliation results so your compliance and security reviewers can trace the move.
- We confirm with you which exported data is retained, where it is stored and when it is deleted after cutover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the written scope closes.
- We can support a second export pass if the tenant changes during the cutover window, as set out in the scope.
- Ask us to confirm in writing which Auth0 export limits, plan requirements and support timelines apply to your tenant.
