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
SOCIAL SHARE CARD GENERATOR