Migrating from Auth0 to Casdoor: what exports, what does not, and how to cut over

Auth0 migrations usually start with a bill. Per-MAU pricing plus per-enterprise-connection fees is fine at 10,000 users and painful at 500,000; teams that hit the second number start looking at open-source or flat-priced options. Casdoor's comparison with Auth0 covers the pricing side; this guide covers the move.

The good news: Auth0 lets you export your user data. The hard part is passwords, and the second hard part is everything that is not a user.

What Auth0 exports

Auth0's bulk export runs as an asynchronous job, started from the Dashboard or with POST /jobs/users-exports on the Management API. You can export the whole tenant or one database connection, pick fields, and get the result as NDJSON or CSV.

Limits worth knowing before you plan:

• Bulk export is not available on the Free plan.
• CSV exports are capped at 30 fields and cannot contain whole metadata objects.
• Job data is deleted after 24 hours, and download links expire after 60 seconds (you can request a new link within the job window).

That is the profile data. Password hashes and MFA secrets are a separate export — Auth0 documents them separately from the profile export, and the availability depends on your plan. Do not assume a profile export contains what you need to keep users signed in.

What Casdoor can import

Casdoor has syncers for Keycloak, Okta, Azure AD, Active Directory, LDAP, databases, SCIM and several workplace tools. There is no Auth0 syncer, because Auth0 is a SaaS with no database you can read directly. The paths are:

1. Spreadsheet import. Casdoor's Upload Users accepts an XLSX/CSV of users. This is the simplest path, and its limitation is important: the importer treats the password column as plaintext and hashes it on save. You cannot put a pre-hashed password in the spreadsheet and expect it to work.
2. API import. A script that reads the Auth0 export and calls Casdoor's user API one user at a time. This gives you control over passwordType, so pre-hashed credentials can be attached if the hash format matches a scheme Casdoor verifies (bcrypt, pbkdf2, argon2id and others are supported). This path needs testing with a real sample before you trust it.

For most teams the practical answer is: import the profiles, then reset the passwords. See the next section for the options.

The password problem, honestly

There are four strategies, in increasing order of effort:

• Reset everyone. Import profiles with a random password and send a reset email. Clean, simple, and the support load is a spike for a week.
• Reset lazily. Import with a flagged state and force a password reset at the next sign-in. Users who never come back never cost you a ticket.
• Import hashes. Export password hashes separately from Auth0, verify that the hash format matches something Casdoor accepts, and write the credentials through the API. Test with ten users, including a wrong password, before doing ten thousand.
• Federate during the transition. Keep Auth0 as an upstream identity provider and have Casdoor accept "sign in with Auth0" while you move applications one by one. This avoids a mass reset but keeps the Auth0 bill until the last application moves.

Whichever you pick, decide it before the cutover. Discovering that hashes do not import on the migration weekend is the classic failure.

What has to be rebuilt

Auth0 configuration does not export in a form another identity provider can import:

• Applications. Recreate each Auth0 application in Casdoor with the same callback URLs. The client IDs change, so every application's configuration changes too.
• Connections. Recreate the social and enterprise connections as Casdoor providers: Google, GitHub, Microsoft, SAML and OIDC connections all have equivalents, but each needs its own credentials again.
• Rules and Actions. Auth0 runs JavaScript during login. There is no drop-in equivalent; each rule's effect has to be reproduced in Casdoor's flow configuration or in your application.
• Organizations and roles. Casdoor has organizations, roles and permissions, but the model is not one-to-one. Map deliberately instead of recreating every Auth0 artifact.
• MFA enrollments. Users re-enroll their second factor; phone numbers and TOTP secrets do not migrate cleanly.
• Custom domain and Universal Login branding. The domain can be repointed with DNS, but the branded pages are rebuilt in Casdoor.

A cutover plan that can be rolled back

1. Export and clean. Run the Auth0 bulk export, remove stale accounts, decide which fields matter.
2. Stand up Casdoor with its own database and an organization for the migrated users.
3. Import a sample of 50 users, including a user whose password you know, and test every connection type you actually use.
4. Pick the password strategy and run it on the sample before the full import.
5. Move one application to Casdoor and keep Auth0 running. Watch sign-in failures for a week.
6. Move the rest application by application. Keep Auth0 read-only as a rollback path.
7. Cancel Auth0 after the rollback window and a final data export.

The migration is a sequence of small cutovers, not one big switch. That is also how you keep the support queue manageable.

Why Casdoor

Casdoor is Apache-2.0 and self-hostable, with OIDC, SAML 2.0, CAS, SCIM and LDAP, and no per-user or per-connection fees. The hosted version starts at $9 per month with unlimited MAU, which is the number to compare against an Auth0 quote at your user count.

Related reading: Auth0 alternatives and the Casdoor vs Auth0 comparison.