← Back to guides

Migrate from Auth0 to Own Auth

To migrate from Auth0 to Own Auth, export user profiles, request any eligible password-hash export through Auth0's protected support process, and plan a verified account claim for credentials that cannot be imported safely. Auth0 access tokens, refresh tokens, connections, and tenant sessions do not become Own Auth sessions.

Auth0 migration is an identity cutover. Inventory users, login methods, application foreign keys, active sessions, organisations, and recovery flows.

Export and inventory Auth0 users

  1. Export user profiles through Auth0's bulk export or Management API.
  2. If password hashes are required, follow Auth0's separate PGP-encrypted support process and confirm eligibility before scheduling the cutover.
  3. Merge profile and credential exports only in an encrypted offline workspace keyed by the Auth0 user ID.
  4. Inventory database connections, social connections, organisations, roles, blocked users, MFA enrolments, and application metadata.

Account transition

Own Auth creates new passwords with Argon2id and verifies only its documented hash formats. Do not copy an arbitrary provider password digest into Own Auth tables. The portable default is to create a passwordless user, verify control of the email address with a single-use magic link, and let the user set a new password through the password-reset flow.

  • A normal Auth0 profile export does not provide every password hash or MFA secret.
  • Auth0 connection names and user IDs are application mappings, not Own Auth account records.
  • MFA enrolments and recovery factors require a deliberate re-enrolment policy.
  • Auth0-issued JWTs and refresh tokens must expire or be revoked on the Auth0 side.
scripts/import-users.ts
await auth.createUser({
  email: exportedUser.email,
  name: exportedUser.name ?? undefined,
  metadata: {
    migrationSource: "auth0",
    legacyUserId: exportedUser.id,
  },
});

Run imports through a server-only script with an idempotent legacy-ID mapping. Do not call this from a public route. Reconcile source and destination counts, duplicate emails, disabled accounts, and failures before sending any claim links.

Move application ownership safely

Keep the old provider ID in an application-owned mapping table until every foreign key and background job uses the Own Auth user ID. A matching email string is not enough to attach billing records, private content, or organisation membership. Require a verified claim before transferring access.

  1. Create Own Auth tables in the staging and production databases with the official migration command.
  2. Import disabled or deleted status separately so blocked accounts do not regain access.
  3. Create an explicit legacy-provider-ID to Own-Auth-user-ID mapping.
  4. Send claim links in controlled batches and rate-limit the claim endpoint.
  5. Transfer application records only after the claim succeeds.
  6. Keep an audit record of imported, claimed, skipped, and failed accounts without logging tokens or passwords.

Session replacement

Auth0 applications validate tokens issued by an Auth0 tenant. Own Auth sessions are created and verified inside the application backend. Keep Auth0 token verification isolated to the migration path, require a successful account claim, and then issue an Own Auth session. Do not make both issuers permanent authorization authorities.

Use different cookie names during a short parallel window. Validate each cookie only with the system that issued it. Never accept an old provider token as an Own Auth session token, and remove the legacy validation path after the announced migration window.

Cutover and rollback

  1. Freeze authentication configuration changes while taking the final export.
  2. Run the idempotent import and reconcile counts.
  3. Enable Own Auth sign-in and recovery for a small internal cohort.
  4. Monitor sign-in failures, claim completion, email delivery, and support requests.
  5. Switch new sign-ins to Own Auth while retaining a time-limited rollback path.
  6. Revoke old provider sessions and credentials only after the cutover is stable.
  7. Delete encrypted working exports according to the migration retention plan.

The successful end state is not two permanent auth systems. Auth0 becomes read-only during the transition, Own Auth becomes the only issuer of new sessions, and the legacy path is removed after account recovery and data reconciliation are complete.