Leaving Auth0: what actually moves — and the one thing they won't hand over

Most teams don't leave Auth0 because they dislike it. They leave because the bill jumped, or because SAML and SCIM turned out to live behind a per-connection enterprise tier, and every new customer's SSO link adds to the meter. Then they look at actually migrating their identity provider, decide it sounds terrifying, and stay another year.

It's less terrifying than it looks. Here's what a real Auth0 migration involves — the boring parts, the fiddly parts, and the one genuinely hard part — so you can judge it for yourself.

What's in your Auth0 tenant

A handful of things have to land somewhere new:

• Applications → OAuth/OIDC clients. Callbacks, logout URLs, allowed origins, grant types, and the client secret. Mechanical.
• APIs (resource servers) + scopes → audiences and scopes, wired to the clients that use them (Auth0 tracks that as "client grants").
• Roles and their assignments → roles + per-user role links.
• Connections → enterprise (OIDC/SAML), social, and database connections. Enterprise OIDC maps cleanly to a federated provider; the rest you reconfigure.
• Users → profiles, metadata, and linked social/enterprise identities.

None of that is hard in principle. The nervousness comes from three specific things.

The three things that make people nervous

1. Keeping identities stable. Your users are referenced by their sub (and your apps by client_id) all over the place — refresh tokens held by downstream apps, SCIM rows in customer IdPs, user IDs stored in your own database. If a migration mints new IDs, all of that breaks silently. The fix is simple to state and essential to get right: preserve the Auth0 user_id as the sub and keep client_id verbatim. Then nothing downstream notices.

2. Passwords — the genuinely hard one. Auth0's Management API never returns password hashes. That's a deliberate Auth0 policy, not a gap in your tooling. You have two honest paths:

• Request Auth0's support-assisted bulk export, which gives you an NDJSON file with each user's bcrypt hash. Bcrypt is portable — anything that verifies bcrypt can take those hashes verbatim, and your users never reset anything.
• Or skip hashes entirely and have users set a new password on first sign-in. Nothing is "lost" — there was no hash to carry — but it's a visible step for your users.

There is no self-serve API for the hashes. Anyone who tells you a one-click Auth0 export includes passwords without that support file is hand-waving.

3. The 1,000-user ceiling. Auth0's user-listing API returns at most 1,000 users. For a bigger tenant, the bulk export file (the same one that carries the hashes) is the real, complete source of users — not the live API.

Making it one click

This is what we built into Authagonal. You point the importer at an Auth0 machine-to-machine app (read scopes only), and it:

• Runs a read-only preview first — it counts every application, API, role, connection, and user it will import and flags anything that needs attention. Nothing is written until you commit.
• Brings applications, API scopes/audiences, roles + assignments, users + metadata, and enterprise OIDC connections across — preserving sub and client_id so existing tokens and references keep resolving.
• Re-hashes Auth0's (plaintext-on-read) client secrets so your apps keep authenticating without rotation.
• Imports bcrypt password hashes verbatim if you supply the export file — and that file also lifts the 1,000-user ceiling. No export? Users set a password on first sign-in.

And because the enterprise features (SAML, SCIM, MFA, audit logs, custom domains) are included in every plan rather than metered per connection, the thing that pushed you toward the exit isn't waiting for you on the other side.

One aside on testing migrations

We test the importer against a real, seeded database, not mocks — and it earned its keep. ASP.NET Identity stores LockoutEnd as a datetimeoffset, and reading it with GetDateTime() throws on that type. A single locked-out user would have failed an entire import. You only catch that by running the real importer against real data. If you're evaluating any migration tool, ask how it's tested — "we mock the source API" is not the same as "we run it against a populated tenant."

If you're eyeing the exit

The migration is more boring than you fear — preview it, keep your IDs, decide your password path — with the one real constraint being Auth0's hash export. If you want to see what would come across from your tenant, the preview is read-only and shows you everything before you commit.

→ Migrate off Auth0