Migrate Off Auth0 Without Downtime

Leaving Auth0 without downtime is a coexistence problem, not a big-bang cutover. You run Auth0 and your new provider side by side, migrate users lazily or in bulk, keep bcrypt password hashes intact where you can, and shift traffic gradually behind stable routing. Done right, no user is forced to reset a password and no login window goes dark. This guide walks the practitioner path end to end.

Why teams leave Auth0

Most teams leave Auth0 because the bill grows faster than the user base, and the honest answer is that not everyone should leave. Auth0 prices on monthly active users (MAU), so a consumer app with seasonal spikes or a fast-growing free tier pays for accounts that generate no revenue. Enterprise connections, tenant isolation, and advanced attack protection sit behind higher tiers, so the line item you signed for is rarely the line item you renew. Lock-in is the quieter cost: Rules, Actions, and Auth0-specific extensibility do not port to another vendor, so the longer you stay, the more custom logic you have to rewrite later.

Here is the gut check before you spend a quarter on this. If your MAU curve is flat, your Auth0 bill is predictable, and you lean on Organizations, fine-grained authorization, or the Auth0 marketplace, migrating may cost more in engineering time than it saves. Leave when pricing scales against you, when you need data residency Auth0 will not give you, or when you are consolidating identity onto a platform you already run. Do not leave because of one renewal conversation. Model three years of MAU first, then decide.

For the vendor decision itself, this guide does not rank alternatives. See the full comparison in Auth0 alternatives, the broader Top CIAM solutions list, and the research roundup New IAM providers 2025. If CIAM as a category is new to you, start with What Is CIAM.

What is portable and what is not

User records and password hashes are portable; your Auth0-specific logic is not. You can export the user profile fields, email verification state, identities, and in most cases the bcrypt password hash. What does not travel is anything that encodes Auth0's own runtime: Rules, Actions, Hooks, tenant settings, connection configuration, and the Management API tokens your systems rely on. Those must be rebuilt in the destination, not copied. Custom database scripts (the "Import Users to Auth0" and custom-database connection scripts) are Auth0 constructs; the credentials behind them are portable, the scripts themselves are not.

Treat the table as a scoping tool. Everything in the "No" column is engineering work you schedule, not data you move.

Trickle versus bulk migration

Choose trickle migration when you cannot export password hashes, and bulk when you can. Trickle (also called lazy or just-in-time migration) verifies each user's password against Auth0 the first time they log in to the new system, then stores the credential in the destination and stops calling Auth0 for that user. Users migrate themselves, one successful login at a time, with zero forced resets. It is the safest default and the only clean option when hashes are locked.

Bulk migration exports every user and their hash in one batch and loads them into the destination up front. It fits when you have the hashes, when you need every account present on day one (for admin search, billing reconciliation, or compliance), or when a large share of your base is dormant and will never trigger a lazy login. Most real migrations are a hybrid: bulk-load the users and hashes you can, and keep a trickle path running for the accounts that fail import or belong to federated connections. Auth0 documents both the bulk user import job and the lazy-migration pattern at auth0.com/docs; read the import job limits before you size the batch.

Password-hash export realities

Bcrypt hashes can move, but the export is a support-gated process, not a self-serve download. Auth0 stores database-connection passwords as bcrypt hashes, and you can request an export of those hashes through Auth0 support (documented under user-migration and password-hash export at auth0.com/docs). Once you have them, most destinations that also use bcrypt can import the hash string verbatim, so users keep their existing passwords and never notice. This is the single biggest lever for a silent migration.

The limits are real. The export is not instant or always available on every plan, so open the request early. Social and enterprise-connection users have no local password to export; they re-federate through OIDC or SAML at the destination instead. If your algorithm or work factor differs from what the destination accepts, or you cannot get the export in time, fall back to forced reset: migrate the profiles, flag the credential as unset, and send a password-reset email on first login. It is not elegant, but scoped to the accounts that actually log in, the blast radius is small. Never store or log exported hashes in plaintext channels; treat the export file as a credential.

Rules, Actions, and tenant remapping

Rules and Actions do not migrate; you rebuild their intent as destination-side logic. Inventory every Rule and Action first and sort each into one of three buckets: identity claims (adding roles or metadata to a token), access decisions (allow or deny at login), and side effects (calling an external API, syncing a CRM). Claims map to the destination's token-customization hooks; enrich the JWT at issuance the way your Rule enriched the Auth0 token. Access decisions become pre-login or post-login hooks. Side effects usually belong in your own backend behind a webhook, not in the identity provider at all, which is a good chance to move that logic somewhere you can test it.

Tenant and Organization structure needs an explicit remap table. Auth0 user_id values carry a connection prefix, so any foreign key in your app that stores auth0|abc123 must be remapped to the destination's identifier during import. Keep a translation table from old ID to new ID and run your app's user references through it. Rebuild roles, RBAC assignments, and organization membership from your own source of truth rather than trusting the export to carry them cleanly. If you are adding enterprise SSO during the move, Add SSO to Your B2B SaaS covers the connection setup and SCIM provisioning that pairs with it.

A zero-downtime cutover

Zero downtime comes from running both providers at once and shifting traffic gradually, never from a timed switch. Stand the new provider up in coexistence: it holds migrated users and, during the trickle phase, calls back to Auth0 to verify passwords it has not seen yet. Put a routing layer in front of login (a reverse proxy, a feature flag, or your gateway) so you control which provider handles a given request without a code deploy.

Shift traffic in stages. Start with internal users, then a small percentage of real logins, then ramp. Because login lives behind stable routing and not a raw vendor URL, DNS and callback URLs stay pointed at your own domain the whole time, so you are flipping a config value, not waiting on DNS propagation. Keep MFA enrolment continuous across the shift: if a user's factor cannot be exported, prompt re-enrolment at first login on the new provider rather than dropping the factor. Auth0 stays live and paid until the last cohort is verified. The pattern mirrors the one in Migrate Off Akamai Identity Cloud; the coexistence principle is provider-agnostic.

Validation and rollback

Validate against real login flows before each traffic increase, and keep rollback to a single config change. At every stage, confirm four things: users authenticate with existing passwords, tokens carry the same claims your app expects, MFA challenges fire correctly, and downstream systems accept the new user identifiers. Compare token payloads from Auth0 and the destination side by side for a sample of accounts; a missing claim breaks authorization silently, which is worse than a failed login.

Because Auth0 is still running, rollback is routing, not restore. If error rates climb, point the routing layer back at Auth0 for the affected cohort and investigate with no user impact. Hold that safety net until you have run at 100 percent traffic on the new provider through at least one full billing and reporting cycle, then decommission the Auth0 tenant and revoke its Management API credentials. Migrating identity is a slow, reversible ramp by design. The moment it stops being reversible, you have moved too fast.