Migrate from Auth0

Move an Auth0 tenant to Authdog without forcing a mass password reset. This guide covers inventory, user export, identity mapping, password strategy, application cutover, and retiring Auth0. For product positioning, see the Migrate from Auth0 overview.

Prerequisites

• An Authdog tenant, project, and environment for the migration rehearsal (usually a staging environment first).
• Auth0 Management API access with permission to read users, connections, clients, roles, and organizations (if you use Auth0 Organizations).
• A list of every application that currently validates Auth0 tokens or redirects to Auth0 Universal Login.
• Agreement on the cutover window and rollback criteria with the teams that own those applications.

Migration shape

Treat migration as four controlled phases:

1. Inventory and export — capture Auth0 configuration and user data.
2. Map and import — recreate connections, roles, and users in Authdog.
3. Parallel run — validate Authdog sessions while Auth0 still serves production.
4. Cut over and retire — switch apps, then disable Auth0 callbacks and credentials.

Do not switch production URLs until a rehearsal environment passes acceptance checks on user counts, identity links, roles, and sign-in paths.

1. Inventory the Auth0 tenant

Document everything that production depends on before you export users:

Export custom claim transforms from Actions so you can recreate the same claims your APIs already expect — or plan a coordinated claim rename with those APIs.

2. Export users

Use the Auth0 Management API or the User Import/Export extension. For each user, retain at least:

• user_id (for example auth0|…, google-oauth2|…)
• Email and email_verified
• Name / profile fields you surface in the product
• Linked identities[] (provider, user_id, connection)
• user_metadata / app_metadata your app reads
• blocked / disabled state
• Last login and created timestamps (for audit and cohort planning)
• Password hash material only if your Auth0 plan and export path can provide it

Store the Auth0 user_id as an external identifier on the Authdog user so downstream databases that keyed on Auth0 IDs keep working. See Users for how Authdog links identities by verified email.

Password strategy

Pick one strategy before import:

• Compatible hash import — when Auth0 can export hashes your Authdog environment accepts, import them so users keep their passwords.
• Progressive migration — when hashes are unavailable, create the Authdog user without a password. On the user's next sign-in, verify the password against Auth0 once, then set it in Authdog and stop calling Auth0 for that user.
• Forced reset — acceptable for small cohorts or admin-only accounts; avoid for large consumer bases.

Never log or persist raw passwords. Keep hash exports encrypted at rest and delete them after cutover.

3. Recreate Authdog configuration

In the target Authdog environment:

1. Enable the same sign-in methods you need (password, social, enterprise SSO, MFA). See Sign up & sign in.
2. Recreate social and enterprise connections with new callback URLs pointing at Authdog. Keep Auth0 callbacks live until cutover.
3. Define roles and permissions that match (or intentionally improve on) Auth0 RBAC. Map Auth0 role names to Authdog roles before assigning users.
4. If you used Auth0 Organizations, model B2B customers as Authdog organizations and plan membership import or invite flows.
5. Replace Auth0 Actions that mint custom claims with either application-side logic after session validation or Authdog metadata/roles your tokens already expose. See Sessions & tokens.

Use a dedicated staging environment for the first full import. Promote configuration to production only after rehearsal.

4. Import users and map access

Import users into Authdog through the console bulk import or the REST Directory API (/v1/... users endpoints). For each record:

1. Create or upsert the user with email, profile, and verification state.
2. Set the Auth0 user_id as the external identifier.
3. Attach metadata your app still needs.
4. Assign roles / organization memberships from your mapping table.
5. Suspend users that were blocked in Auth0.

Identity linking

Authdog links identities on verified email. Users with multiple Auth0 identities (for example database + Google) should import as one user with linked providers when the emails match and are verified. Test account linking explicitly for:

• Same verified email across providers
• Unverified emails (must not claim an existing account)
• Enterprise SSO users created just-in-time after cutover

5. Update applications

For every client that used Auth0:

1. Install the Authdog SDK or components for that stack (quickstarts).
2. Replace Auth0 domain / client ID configuration with the Authdog environment public key (pk_...).
3. Point login, callback, and logout URLs at Authdog.
4. Validate sessions with Authdog on the backend instead of Auth0 JWKS. See Backend requests.
5. Update any code that read Auth0-specific claims (https://…/roles, namespaced custom claims) to the Authdog session shape.

During the parallel-run window you can accept either token issuer in a thin compatibility layer, but keep that layer temporary and instrumented.

6. Cut over in stages

Recommended sequence:

1. Rehearse import + sign-in against staging Authdog with a copy of production users.
2. Move internal / dogfood applications first.
3. Move one user cohort or one production application at a time.
4. Monitor failed logins, support tickets, and webhook / event volume.
5. When a cohort is stable, stop sending new traffic for that cohort to Auth0.
6. After all apps cut over, disable Auth0 application callbacks, rotate Auth0 secrets, and decommission the tenant on your schedule.

Rollback for a cohort means pointing that app back at Auth0 while you fix mapping or connection issues — which is why external IDs and dual-run matter.

Before you call production migration done:

• User counts match within expected deltas (filtered test / blocked accounts).
• Auth0 user_id values are stored as external identifiers.
• Password or progressive-migration path verified for database users.
• Social and enterprise connections succeed end-to-end.
• Roles / permissions / org memberships match the mapping table.
• Every callback, logout, and web-origin URL is registered in Authdog.
• Backend session validation no longer depends on Auth0 JWKS.
• Actions/Rules behavior reimplemented or explicitly retired.
• Auth0 credentials revoked after the soak period.

Related

• Migrate from Firebase
• Migrate from WorkOS
• Migrate from Supabase
• Users
• Deployments
• Integrations
• Migrate from Auth0 (overview)