# Migrating from Auth0: A checklist for identity, access, and rollback > Plan a migration from Auth0 around account continuity, credential portability, token validation, authorization tests, and state-aware rollback. Canonical URL: https://www.devobs.io/articles/auth0-migration-checklist/ By: Amara Okafor Published: 2026-10-12T02:59:30.502Z Updated: 2026-10-12T02:59:30.502Z Section: Identity When migrating away from Auth0, treat exporting users as one workstream—not the migration itself. Plan to preserve account identity, verify credential portability, update application and API trust, reproduce authorization behavior, and cut over in controlled cohorts with a tested rollback procedure. Use this checklist as recommended engineering acceptance criteria. Do not promise uninterrupted sessions, unchanged passwords, or preserved MFA enrollments until those paths have passed a rehearsal against the chosen destination. ## 1. Define scope and acceptable disruption Before choosing bulk import, staged migration, or a reset-based transition, agree on what the migration must preserve. - [ ] Record whether password resets, MFA re-enrollment, forced sign-in, downtime, and temporary coexistence are acceptable. - [ ] Inventory every tenant, application, API, machine client, and identity connection in scope. Include mobile clients and integrations that cannot be updated immediately. - [ ] Assign owners for identity data, application changes, authorization, communications, support, and rollback. - [ ] Establish baseline login success, recovery success, latency, token-validation failures, and support volume. Set explicit stop and rollback thresholds before rollout. **Completion criterion:** Every affected integration has an owner, and every user-visible disruption has an agreed handling plan. ## 2. Inventory application configuration and authentication logic For each integration, record protocols, SDK versions, grant types, callback and logout URLs, domains, audiences, scopes, signing configuration, token lifetimes, and external dependencies. Record secret references rather than copying secret values into a migration spreadsheet. Auth0 describes Actions as tenant-specific, versioned Node.js functions attached to triggers. Multiple Actions execute in their configured order, and triggers can be synchronous or asynchronous. Preserve those behavioral distinctions when replacing them. [Auth0 Actions documentation](https://auth0.com/docs/customize/actions) - [ ] Translate each customization into a requirement: claim enrichment, access restrictions, provisioning, account linking, notifications, or external calls. - [ ] Capture ordering, timeout behavior, retries where applicable, error handling, and whether a failure must block authentication. - [ ] Test replacement logic for duplicate execution and partial failure. - [ ] Provision replacement credentials securely; schedule revocation of obsolete credentials after the rollback window. Do not treat copying customization code as proof that the surrounding runtime behavior has been preserved. ## 3. Preserve account identity and organization boundaries Create an explicit mapping between the source tenant and user identifier, destination identifier, and canonical application account identifier. Use that mapping to verify ownership of application records—not just whether the new login succeeds. Auth0 documents Organizations as a way to represent business customers and partners, manage memberships, configure federated login flows, and offer organization-related machine-to-machine access. Inventory these separately from personal profile fields. [Auth0 Organizations overview](https://auth0.com/docs/manage-users/organizations) - [ ] Classify profile fields, metadata, verification state, linked identities, disabled accounts, organization memberships, and role assignments. - [ ] Define how source identifiers will resolve to destination accounts. Do not merge accounts solely because they share an email address. - [ ] Preserve the distinction between authentication identity, application account, and organization membership. - [ ] Test users with multiple organizations, multiple linked login methods, changed email addresses, and disabled accounts. **Completion criterion:** Each migrated identity resolves to the intended application account and organization context without creating duplicate accounts or crossing tenant boundaries. ## 4. Verify profile export and credential portability separately Auth0 documents bulk profile exports in JSON-compatible and CSV formats; its JSON-compatible files use NDJSON. The documented bulk-export feature is unavailable on the Free plan. The Management API export endpoint is `POST /jobs/users-exports`; omitting `connection_id` exports users from all connections on the tenant. Select export scope deliberately. [Auth0 bulk-export documentation](https://auth0.com/docs/manage-users/user-migration/bulk-user-exports) For CSV exports, Auth0 documents a 30-field limit and requires individual metadata fields rather than whole `app_metadata` or `user_metadata` objects. Its JSON-compatible format supports metadata as whole objects. Choose the format around the data you need to preserve. [Export limits](https://auth0.com/docs/manage-users/user-migration/bulk-user-exports) Auth0 separately documents requesting a PGP-encrypted export of password hashes and MFA secrets through a support case. That export path does not establish that a destination accepts every exported credential. [Auth0 import and export documentation](https://auth0.com/docs/manage-users/user-migration) - [ ] Confirm export access, connection scope, required fields, and operational lead time before scheduling cutover. - [ ] Validate a small export before processing the full dataset. Parse the documented format explicitly rather than treating NDJSON as a single JSON array. - [ ] Confirm which credential material is available for the actual connections and methods in use. - [ ] Verify destination support for the exact password-hash algorithm, parameters, encoding, and any additional required material. - [ ] Prove password verification with controlled test accounts before promising a reset-free transition. Choose the migration method only after those checks: - **Bulk import:** Use where the required data and credential formats have passed destination import and authentication tests. - **Staged migration:** Use only after proving the authentication handoff, synchronization, and fallback mechanisms needed for coexistence. - **Reset-based transition:** Use where password continuity cannot be established, with tested recovery controls and user communications. Auth0’s documented automatic migration flow moves users **into Auth0** from an external user store. Do not assume it supplies an equivalent mechanism for moving users out. [Auth0 migration overview](https://auth0.com/docs/manage-users/user-migration) ## 5. Plan MFA, recovery, passwordless, and federation separately Auth0 documents multiple MFA factors, including one-time passwords, push, SMS, WebAuthn, and recovery codes, with some factors subject to plan availability. General MFA support is not evidence of enrollment portability. [Auth0 MFA documentation](https://auth0.com/docs/secure/multi-factor-authentication) - [ ] For every authentication method, classify the outcome as verified transfer, re-enrollment, replacement, or retirement. - [ ] Test account recovery independently of ordinary login. Do not introduce a weaker recovery route merely to make migration easier. - [ ] Verify the treatment of recovery codes, remembered-device state, and existing MFA enrollments rather than assuming they follow the profile export. - [ ] For passkeys and WebAuthn credentials, verify relying-party identifiers, allowed origins, credential transfer requirements, and destination support. - [ ] Rehearse each social or enterprise connection, including provider registrations, callbacks, certificates or keys, upstream subject mapping, account linking, and organization routing. For federated users, require two successful outcomes: authentication at the upstream provider and resolution to the correct existing application account. ## 6. Test token contracts and session behavior Auth0 recommends established middleware or libraries for JWT validation and warns that not every library validates every claim. Keep validation enabled throughout the migration. [Auth0 JWT validation guidance](https://auth0.com/docs/secure/tokens/json-web-tokens/validate-json-web-tokens) Build a compatibility matrix for every application and API: | Contract | Required check | | --- | --- | | Issuer and audience | Accept only explicitly configured issuer–audience combinations. | | Signature and keys | Bind each issuer to approved algorithms and trusted key sources; test rotation. | | Subject | Resolve the validated issuer and subject to the intended application account. | | Scopes and custom claims | Verify names, types, meanings, and behavior when claims are absent. | | Expiration and refresh | Test expiry, renewal, revocation, and rejected refresh attempts. | | Token purpose | Reject tokens that are not valid for the receiving application or API. | - [ ] If both issuers are temporarily trusted, define each trust configuration explicitly. Do not accept arbitrary issuers or key locations supplied by an incoming token. - [ ] Test browser login state, application sessions, refresh tokens, and remembered-device state as separate concerns. - [ ] Verify login, logout, revocation, expired sessions, and old-client behavior. - [ ] Schedule reauthentication wherever continuity has not been demonstrated. **Completion criterion:** Valid traffic works, invalid traffic remains rejected, and the coexistence configuration has a defined removal date. ## 7. Validate authorization independently of login Require authorization parity tests before expanding a migration cohort. A successful login should not satisfy this gate. - [ ] Map roles, organization memberships, entitlements, and object-level relationships to the destination design. - [ ] Compare expected allow and deny decisions for representative users and resources. - [ ] Include disabled users, removed privileges, deleted memberships, expired access, and cross-organization requests. - [ ] Verify that permission changes reach the enforcement point within the required time. - [ ] Define whether claims, application data, or a permissions service is authoritative for each decision. A useful negative test is to remove a user’s access during coexistence and verify denial through both authentication paths. Include this case in rollback testing as well. ## 8. If Ory is the destination, map responsibilities by component For an Ory Network target, use Ory’s documentation to separate the following responsibilities: | Ory Network service | Documented role | | --- | --- | | Ory Identities, built on Kratos | API-first identity management, login and registration, recovery, profile and account management, and administrative APIs for importing, updating, and deleting accounts. [Kratos introduction](https://www.ory.com/docs/network/kratos/intro) | | Ory OAuth2 and OpenID Connect, built on Hydra | OAuth 2.0 and OpenID Connect services, connected to Ory Identities by default in Ory Network. [Hydra introduction](https://www.ory.com/docs/network/hydra) | | Ory Permissions, built on Keto | Fine-grained relationship-based permissions and inheritance through groups, roles, and hierarchies, based on Zanzibar design principles. [Keto introduction](https://www.ory.com/docs/network/keto) | Use this as a responsibility map, not a compatibility guarantee. Evaluate managed-service and self-hosted requirements separately. Verify Auth0 feature parity, password-hash compatibility, and MFA enrollment transfer through destination-specific documentation and migration tests rather than inferring them from component roles or generic import APIs. ## 9. Rehearse data movement and state-aware rollback - [ ] Run export, transformation, and import against representative data under restricted access. - [ ] Reconcile identifiers and record counts; inspect rejected records and explain every intentional exclusion. - [ ] Test repeat runs for duplicates, accidental account linking, and unintended updates. - [ ] Encrypt migration artifacts, limit access, define retention and deletion, and keep credentials and tokens out of logs. - [ ] Define the source of truth during coexistence for registrations, password changes, account links, permission changes, and deletions. - [ ] Test how each change is reconciled—or explicitly frozen—before rollback. Write the rollback procedure around state, not just traffic routing. For example, if a user is disabled after the initial export, require rollback to preserve that denial. If a user changes a password at the destination, define the next authentication and recovery experience before returning traffic to the source. **Completion criterion:** A rehearsal demonstrates recovery from a failed cutover without silently restoring revoked access or losing unprocessed identity changes. ## 10. Cut over by cohort and retire deliberately - [ ] Start with a small, controlled cohort that covers representative authentication methods and application types. - [ ] Monitor login and recovery success, MFA challenges, token-validation failures, authorization denials, latency, notification delivery, and support volume against the predefined thresholds. - [ ] Pause or roll back when a threshold is breached; do not compensate by weakening validation or access controls. - [ ] Expand only after reconciliation and compatibility checks pass for the current cohort. - [ ] Before retirement, resolve remaining sessions and tokens, remove temporary dual-issuer trust, revoke obsolete credentials, and complete artifact-retention and deletion requirements. The final release gate is straightforward: users must reach the correct accounts, receive only their intended access, retain a working recovery path, and remain protected if the migration has to be reversed. ## Source references - - - - - - - - -