Migrate from Auth0

Migrating an identity provider is the kind of project that goes smoothly only if you respect the moving parts. This tutorial is a playbook from doing it a few times — what to map, what to migrate, and what to leave for the cutover. We assume you currently have a working Auth0 setup and want to move to IntelliAuth without disrupting users.

It is not a one-click migration; nothing in identity ever is. But the path below is well-trodden, and most teams complete it in a week or two of part-time work.

Before you begin

Read access to your Auth0 tenant
Admin access to a fresh IntelliAuth tenant
A plan for handling user passwords (covered below)
A cutover window you control (DNS or feature-flag rollback path)

Concept map

The big-rocks correspondence between Auth0 and IntelliAuth:

Auth0	IntelliAuth	Notes
Tenant	Tenant	Same word, same meaning
Application	Application	Same: OAuth client, has client_id, optional client_secret
Connection	Federation connection	Auth0's "Database" connection has no IntelliAuth equivalent — IntelliAuth treats users as native if not federated
Rules / Actions	Pipeline steps	Custom JS that runs during sign-in
Hooks	Webhook subscriptions	Event-driven, post-fact
Roles	Groups	RBAC primitive
Permissions	Scopes	Already a scope concept; mostly 1:1
Organizations (B2B)	Organisations	Multi-tenant grouping; IntelliAuth's notion is the platform-level org, slightly different
Universal Login	The IntelliAuth sign-in page	Brandable in both
Account Linking	Federation linking	Same idea: one user, multiple identities

The mental model differences:

No "database connection". Native IntelliAuth users are just users. You don't pick a "Username-Password-Authentication" connection at sign-up.
Pipelines vs Rules. Auth0's Rules and Actions both map roughly to IntelliAuth's Flows + Actions, but in IntelliAuth this surface is web-driven only — your tenant admin configures them in the IntelliAuth admin console. The mental model is similar enough to translate by hand; see the authentication pipelines concept.
Organisations are slightly different. Auth0's B2B Organizations are customer groupings inside a single Auth0 tenant. IntelliAuth's organisation sits one level up — it's your platform-level parent that owns the tenant. For app-level B2B (where one of your tenants serves multiple customer companies), model each customer as IntelliAuth groups + application metadata, not as separate IntelliAuth orgs.

Phase 1 — Inventory (½ day)

Don't migrate what you don't use. Open your Auth0 tenant and write down:

Active applications (those with traffic). Skip dormant ones.
Active connections. Note which are social, which SAML, which DB.
Rules + Actions in use. For each, decide: keep, drop, or rewrite.
Custom claims your apps depend on. These have to land in the IntelliAuth tokens too.
Hooks / extensions. These map to webhooks.
User volume + last 30-day active count.

Most teams find 30% of what they have is dormant. Cutting it now saves migration effort.

Phase 2 — Stand up IntelliAuth alongside (1–2 days)

For each Auth0 application you keep, register a counterpart in IntelliAuth (see Applications API or the admin console). Match the redirect URIs and allowed origins exactly.

For each social connection, create the matching IntelliAuth federation connection. The OAuth provider's side (the Google / GitHub / Microsoft / Apple developer console) needs to be updated to allow the IntelliAuth callback URL.

For SAML connections, set up a parallel SAML connection in IntelliAuth and ask the IdP-owning organisation to add IntelliAuth's metadata. Both can coexist during the migration window.

At this point, IntelliAuth is parallel to Auth0 — same applications, same connections — and your code is still using Auth0.

Phase 3 — Migrate users (the hard part) (2–3 days)

Three classes of users; each migrates differently.

Easy. Their credentials live with the federation provider, not Auth0. Once they sign in via IntelliAuth's matching federation connection, they appear as IntelliAuth users automatically (JIT provisioning).

Action: nothing migrates ahead of time. Just make sure the federation connections are configured correctly on IntelliAuth.

Native users with passwords

Hard. Auth0 stores user passwords as hashes; the hashes are NOT portable in the general case (Auth0 uses bcrypt, IntelliAuth uses argon2 — different hash format).

Three strategies, pick one:

Bulk import with password reset on next sign-in. Export user records (email + name + metadata) from Auth0; bulk-import into IntelliAuth with password_must_be_reset: true. Every user is forced to set a new password on first sign-in via IntelliAuth. Most painful for users; cleanest migration.
Live migration via Auth0 verification. Stand up a small "migration broker" as an Auth0 application that exposes Auth0's Authentication API. Your tenant admin configures a custom Action on the sign-in flow (IntelliAuth admin console → Authentication → Flows → Actions, on the pre-credential-check trigger) that calls your broker. If Auth0 verifies the credentials, IntelliAuth provisions the user record and proceeds. Less painful for users; transient extra hop until the user is migrated.
Just-in-time on next sign-in. When a user lands on IntelliAuth's sign-in for the first time and is not found, fall back to Auth0; on successful Auth0 sign-in, provision in IntelliAuth + force password reset. Hybrid of the above.

The first is the default recommendation for tenants with < 10K users; the second for larger tenants where user UX matters more than implementation effort. Decide and commit.

Internal admin / service accounts

Migrate by hand. There aren't many; getting them right matters more than throughput.

Phase 4 — Migrate auth flow customisations (1 day)

For each Auth0 Rule / Action, decide if it stays.

"Add custom claims to the token" — translates to a custom Action on the login.post-success trigger, configured by your tenant admin. The Action decorates the user record before the token is issued.
"Block by email domain" — translates to a custom Action on the login.pre-credential-check trigger. Your tenant admin sets that up in the IntelliAuth admin console; the Action's logic is short.
"Sync to CRM" — webhook subscription on user.signed_in. This one's pure integrator territory; you build the receiver.
"Multi-factor enforcement" — IntelliAuth's authentication policy in the tenant admin console (no code).

Map each one; rewrite where needed; test before cutover.

Phase 5 — Migrate hooks → webhooks (½ day)

For each Auth0 Hook (post-login, pre-user-registration, etc.), pick a webhook event:

"Post user registration" → user.signed_up webhook subscription.
"Pre user registration" → a custom Action on the registration flow's pre-create trigger, configured by your tenant admin in the admin console (synchronous; can block).
"Post change password" → user.password_reset_completed webhook.

Hooks were inline (could block sign-in); webhooks are async (after-fact). For inline behaviour your tenant admin configures Actions on the relevant flow; for after-fact you subscribe to webhooks. Match each Hook to the right mechanism.

Phase 6 — Migrate the frontend code (½ day per app)

For each application:

Swap @auth0/auth0-react for @intelliauth/react-sdk (or the equivalent for your stack). The APIs are similar but not identical — see the React SDK overview.
Update environment variables: AUTH0_DOMAIN → INTELLIAUTH_TENANT_URL, AUTH0_CLIENT_ID → INTELLIAUTH_CLIENT_ID.
Test the sign-in flow against IntelliAuth.

Per-method swap reference:

Auth0	IntelliAuth
`useAuth0()`	`useIntelliAuth()`
`loginWithRedirect()`	`loginWithRedirect()`
`getAccessTokenSilently()`	`getAccessToken()`
`logout()`	`logout()`
`user`	`user` (similar shape)
`isAuthenticated`	`!!user`
`isLoading`	`loading`

The id-token claim names are standard OIDC, so sub, email, name, etc. are unchanged. Custom claims your Auth0 Rules added under https://app.example.com/... namespacing should be re-emitted by your IntelliAuth pipeline steps with the same names — your downstream code doesn't have to change.

Phase 7 — Migrate the backend code (½ day per service)

Swap your backend's Auth0 JWT verification for IntelliAuth's:

The token format is JWT in both. Verification means fetching the JWKS and validating signature + claims.
For Node: use @intelliauth/node-sdk's Express middleware.
For Go / Python / Ruby: use a standard JWT library + JWKS fetcher, pointed at IntelliAuth's /.well-known/jwks.json.

The endpoints your backend hits (/oauth2/token, /oauth2/userinfo) have the same shape as Auth0's. The only semantic change is the issuer — make sure your iss validation accepts the IntelliAuth tenant URL.

Phase 8 — Cutover (1 day)

You have parallel Auth0 + IntelliAuth running. Time to flip.

A safe rollout:

Internal accounts first. Switch the staff sign-in flow to IntelliAuth. Live on it for a few days; shake out the bugs.
A small % of customer traffic. Use a feature flag or A/B; route 5% to IntelliAuth. Monitor signup + sign-in success rates.
Ramp up. 25%, 50%, 100% over a week.
Turn off Auth0. Leave the parallel deployment in place for a week or two as a fallback, then decommission.

DNS-level cutover (point the existing auth domain at IntelliAuth) works if you control DNS, but means a less granular rollback. Feature-flag is safer.

Common gotchas

Auth0's sub is auth0|userid; IntelliAuth's is the user ID directly. Your code probably parses sub somewhere; make sure it works with both formats during the migration.
Auth0's namespaced claims. If your app reads https://app.example.com/roles, your IntelliAuth pipeline step must emit the same claim name (with namespace) until you've updated your app to read the IntelliAuth-native claim.
Refresh token rotation behaves slightly differently. Both rotate; the precise schedule and reuse-detection rules differ. Test your "long-running session" path explicitly.
Branding parity. The IntelliAuth sign-in page is brandable but starts from a different default. Spend a few hours on branding before cutting traffic.
MFA enrolment doesn't transfer. Users who had Auth0 MFA enrolled need to enrol again in IntelliAuth. Communicate ahead of time.

After cutover

Monitor the audit log for "user.signed_in.failed" spikes. The first few days are when the long-tail "weird Auth0 config" cases show up.
Watch your support queue. Identity migrations always produce a small bump of "I can't sign in" — most are unfamiliar UX, not bugs.
Decommission Auth0 in a deliberate way. Tear down the Auth0 applications, then the connections, then close the tenant. Keep your Auth0 export available for 90 days in case you discover something you missed.