How to Migrate Between CIAM Platforms: A Vendor-Agnostic Framework

Key takeaways

• Every CIAM migration is roughly 80% the same five phases; the 20% that differs is export friction and import capability.
• Know what does not migrate first: passkeys (re-enroll), refresh tokens and sessions (lost at cutover), custom logic (rewrite).
• Password-hash portability is the gating question; if the source will not export hashes, migrate just-in-time on next login.
• Choose the destination by what you are escaping, not by brand. The right answer differs per reason.
• Security teams judge a migration on credential security in transit, audit continuity, rollback, downtime, and residency.

Why one framework covers every pair

Whether you are moving off Auth0, Ping, Microsoft Entra External ID (Azure AD B2C), Stytch, Descope, Cognito, Firebase, or an older suite, the work is the same shape. You inventory what you have, stand up the destination, move users and credentials, run both in parallel, then cut over and decommission. The vendor-specific runbooks differ only in the import API, the hash schemes supported, and how the old platform's custom logic maps to the new one. Learn the framework once and every migration becomes a known quantity.

What migrates, and what does not

This is the table to internalize before you plan anything. Getting a surprise here is what turns a clean migration into an incident.

Item	Migrates?	What to plan
Password hashes	Sometimes	Portable only if the source exports them and the destination supports the scheme (usually bcrypt). Source-side gating is the common blocker.
Passwordless / passkeys (WebAuthn)	No	Bound to the relying-party origin. Users re-enroll on the new platform; keep a fallback method during transition.
TOTP / MFA enrollments	Sometimes	Migrate only if TOTP secrets can be exported; otherwise users re-enroll. SMS/email OTP needs no migration.
Refresh tokens and active sessions	No	Lost at cutover. Everyone re-authenticates. Communicate the forced re-login.
Custom logic (Actions, Rules, hooks, Lambdas)	No	A rewrite, not an export. This usually dominates the engineering estimate.
Social and enterprise connections (SAML/OIDC)	Reconfigure	Re-create each IdP connection and re-validate the round trip per tenant.
User profile and metadata	Yes	Export and map fields; preserve email-verified status so users are not re-prompted.
Roles, organizations, tenants	Yes, with remodeling	Map the source tenancy model to the destination's; B2B Organizations rarely map one to one.
Consent and preference records	Yes, with care	Migrate consent state to preserve compliance continuity; do not silently reset it.
Audit log history	Export and archive	Rarely importable. Export the old logs for your retention and compliance trail before decommission.

The five-phase playbook

Every migration runs these phases. Depth varies; the sequence does not.

1. Discovery and inventory. Catalog every custom Action or Rule, every connection, your tenancy structure, the claims your app consumes, and, critically, your credential-export options. Timelines track custom-logic complexity and export friction, not user count.
2. Stand up the destination. Deploy it production-grade, model tenants and applications, re-implement custom logic in the destination's extension model, and recreate identity-provider connections.
3. User and credential import. Bulk-import with hashes when the source cooperates; otherwise migrate just-in-time on next login and plan a reset for the inactive tail. Carry over metadata, roles, and verified status.
4. Dual-run and validate. Run both platforms, route a growing share of traffic to the destination, and compare token claims field by field across every critical flow.
5. Cutover and decommission. Flip the default, hold the old platform in read-only standby for a short rollback window, archive its logs, then close it.

For step-by-step depth, see the worked runbooks: Auth0 to FusionAuth, Auth0 to self-hosted, and Cognito to a managed platform.

Source-side friction: getting your data out

The hardest part of most migrations is not the destination, it is the exit. Audit these on the platform you are leaving:

• Password hashes. Bulk user export is common; hash export is often gated behind a support ticket or a paid tier. Confirm your exact plan's policy before promising a no-reset migration.
• MFA secrets. TOTP seed export is frequently restricted; assume re-enrollment unless you confirm otherwise.
• Custom logic. It is not exportable as data. Inventory it as code to re-implement.
• Audit history. Export it for your records; you will rarely be able to import it into the destination.

Destination-side capability: getting your data in

Match the exit constraints to what the destination accepts:

• Bulk import API with hashes is the smoothest path when you have the hashes and the destination supports the scheme.
• Just-in-time / connector migration validates against the old system on first login and rehashes into the new one. This is the standard answer when hashes are unavailable.
• Tenancy and Organizations modeling is where managed-to-managed and managed-to-self-hosted migrations diverge most; confirm the destination can express your B2B structure before committing.

Each vendor profile carries an migration_difficulty score for inbound and outbound moves (1 easy to 5 hard), so you can gauge both sides before you start. Read both the source's outbound score and the destination's inbound score in the vendor index.

Choose your destination by what you are escaping

There is no universal "migrate to X." The right destination is set by the reason you are leaving. Each path below links the neutral alternatives analysis that ranks the options on the same matrix.

• Escaping per-MAU cost at scale. Self-host to remove the per-user line item (FusionAuth, Keycloak), or move to per-organization pricing for B2B (SSOJet). See Auth0 alternatives and open source CIAM.
• Need B2C passwordless and simpler scale. Passwordless-first platforms fit here (MojoAuth for passwordless B2C across the 100k to 1M MAU range, Stytch for passkey-first primitives). See Firebase alternatives.
• Need budget B2B Enterprise SSO and SCIM. Enterprise-readiness layers and per-org pricing fit (WorkOS, SSOJet). See the B2B SaaS vertical.
• Need sovereignty or self-hosting. Open-source, self-hosted platforms (Keycloak, FusionAuth, Zitadel, Ory). See open source CIAM.
• Forced off an end-of-life platform (for example Azure AD B2C). Pick by whether you stay in the same cloud or leave it. See Microsoft Entra alternatives.
• Leaving an established all-in-one suite. Decide managed (a broad platform like Auth0), self-hosted (FusionAuth, Keycloak), or build in-house, and read build vs buy before choosing to build, because the unhappy paths dominate that work.

If you are not sure which reason dominates, the vendor selector narrows the field in six questions, and Start here works the full decision in order.

How security and identity teams evaluate a migration

A migration is a security event, not just an engineering one. The questions identity and security reviewers actually ask:

• Credential security in transit. How are password hashes, secrets, and PII moved between platforms? Encrypted transfer, least-privilege access, and no credentials in logs or tickets.
• Audit continuity. Is there an unbroken audit trail across the cutover? Export and archive the old platform's logs so the record survives decommission.
• Rollback. If the destination misbehaves, can you fail back? Keep the old platform in read-only standby for a defined window.
• Downtime and blast radius. Is cutover a hard switch or a gradual ramp? Canary internal users, then a percentage, then the bulk.
• Data residency and compliance. Does data stay in-region throughout the move, and does the destination hold the same attestations? Residency can be violated mid-migration if a staging environment sits in the wrong region.
• Forced re-authentication and MFA re-enrollment. Communicate it, keep a fallback method live, and watch enrollment rates after cutover.

Treat these as gates, not afterthoughts. A migration that lands on feature parity but breaks the audit trail or leaks hashes in a support ticket is a failed migration, regardless of how clean the new login screen looks.

The framework in one view

1. What migrates (and what does not) sets your hard constraints.
2. The five phases structure the work; depth varies, sequence does not.
3. Export friction and import capability decide whether users notice.
4. What you are escaping picks the destination, not the brand.
5. Security gates (credentials, audit, rollback, residency) decide whether the migration is actually done.

Learn this once and any CIAM migration, from any platform to any platform, becomes a planned, reviewable project instead of a leap.