Migrating from Auth0 to WorkOS: identity control trade-offs

At a glance

What this is: This is a step-by-step migration guide for moving Auth0 tenants to WorkOS, with the key finding that enterprise identity migrations are really about control trade-offs, not just data transfer.

Why it matters: It matters because IAM teams need to re-evaluate user, organization, SSO, MFA, and lifecycle governance when identity providers change, especially where B2B scale and operational predictability are the drivers.

By the numbers:

• For 96% of those connections the transition was completely seamless for end users.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.

👉 Read WorkOS's step-by-step Auth0 to WorkOS migration guide

Context

Migrating identity providers is usually framed as a platform decision, but the real problem is governance drift: the old model stops matching how users, organisations, and enterprise connections are actually managed. In B2B environments, authentication, provisioning, MFA, and auditability must move together or the migration creates new operational gaps rather than removing old ones.

For product teams, the challenge is not simply exporting records from Auth0 and importing them elsewhere. It is preserving identity continuity across users, organisations, SSO connections, and downstream access controls while changing the system that enforces them. That makes this an IAM and lifecycle migration, not just an implementation task.

Key questions

Q: How should teams handle an Auth0 migration without breaking enterprise logins?

A: Treat the migration as an identity cutover, not a file transfer. Preserve callback URLs, organisation mappings, and SSO routing, then migrate users and enterprise connections in phases where possible. The safest approach is to monitor authentication success closely, keep rollback available, and validate every customer-facing login path before decommissioning the old provider.

Q: Why do identity provider migrations often create hidden governance risk?

A: Because the provider usually contains more than authentication. It may also hold organisation structure, MFA policy, audit evidence, provisioning logic, and custom rules. When those controls are embedded in one platform, moving away from it can expose gaps in lifecycle management, recovery, and access consistency unless each dependency is explicitly mapped and rebuilt.

Q: What do teams get wrong when moving MFA between identity platforms?

A: They often assume one second factor can replace another without changing risk. SMS, TOTP, and passwordless email flows do not provide the same assurance or recovery properties, so the migration must account for user re-enrolment, support load, and policy changes. The right approach is to re-establish assurance, not just preserve login convenience.

Q: What should organisations do after switching identity providers?

A: Run a structured post-migration validation across users, organisations, SSO, MFA, audit logs, branding, and provisioning. Confirm that deprovisioning works, that login errors are monitored, and that legacy integrations are safely removed. The objective is not only successful cutover but stable governance after the old system is retired.

Technical breakdown

Exporting users and passwords without breaking identity continuity

User migration is not just a data export. Auth0 can export profiles and metadata, but plaintext passwords are not available, so the practical path is to request password hashes or plan for resets. The important technical detail is hash compatibility. If hashes can be imported, existing accounts retain continuity; if not, authentication state changes and support load rises. Mapping fields correctly matters because email, verification state, and profile attributes determine whether downstream login and account linking behave as expected.

Practical implication: verify hash format support and field mapping before cutover, or users will experience forced resets and broken account matching.

SSO connections, custom domains, and cutover mechanics

Enterprise SSO migration is the hardest part because each connection reflects a customer’s identity provider configuration, often through SAML or OIDC. A safe cutover depends on preserving routing, callback URLs, and domain continuity so login traffic can move without forcing every customer to reconfigure at once. Techniques such as phased rollout, dual-auth, and proxying reduce disruption, but they also increase the need for monitoring and rollback discipline. The technical challenge is not the protocol itself, but the transition state between two identity systems.

Practical implication: treat SSO migration as a traffic-routing exercise with rollback, monitoring, and customer coordination, not as a simple import.

MFA and enterprise feature parity after the move

Identity migrations often expose hidden dependencies on MFA methods, roles, audit logs, and provisioning workflows. In this case, SMS MFA cannot be treated as interchangeable with stronger factors like TOTP or passwordless email-based options, because factor choice affects assurance and recovery design. Directory sync, RBAC, branding, and audit logs also need explicit recreation because these are not cosmetic settings. They are operational controls that determine whether the new platform can support enterprise governance at the same level as the old one.

Practical implication: inventory every Auth0-dependent control, then re-create or redesign it deliberately instead of assuming feature equivalence.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity migration is a governance event, not a product swap. The article shows that moving from one provider to another forces teams to revalidate how users, organisations, access policies, and lifecycle controls fit together. That is a governance change because the enforcement boundary shifts, the operational dependencies change, and the failure modes move with them. Practitioners should treat provider migration as an identity programme redesign, not a lift-and-shift exercise.

Enterprise identity migrations expose the hidden cost of platform-embedded logic. When business logic sits inside authentication rules, actions, or provider-specific flows, the organisation inherits a portability problem that shows up only when change is required. That makes vendor lock-in an IAM design issue, not just a commercial one. The practitioner lesson is to keep core identity logic inspectable, portable, and separable from the provider where possible.

Bulk migration success does not remove the need for lifecycle discipline. Even if most SSO connections move cleanly, the real test is whether the organisation can still provision, deprovision, audit, and recover identities after the switch. Authentication continuity is only one part of identity control. The practitioner conclusion is that governance must follow the account, the organisation, and the connection, or the migration merely relocates risk.

Flat connection pricing changes the identity decision model, not just the invoice. Cost predictability can be a legitimate trigger for migration, but it also changes how teams evaluate enterprise connections, customer onboarding, and long-term platform dependence. That makes pricing architecture part of IAM strategy because it influences how quickly product teams scale identity features. The practitioner should assess whether the new cost model aligns with future B2B growth, not only current usage.

Directory sync and enterprise SSO are now baseline governance expectations, not add-ons. The guide reflects a wider market reality: once B2B customers expect SCIM, audit logs, and organisation-aware access, identity systems must support lifecycle automation by default. That raises the bar for programme maturity across human, machine, and partner identities. Practitioners should align identity architecture to enterprise governance requirements before customer pressure forces a rushed migration.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, and 77% of those incidents resulted in tangible damage.
• Top 10 NHI Issues provides the broader control breakdowns that make migrations riskier when identity logic is tightly coupled to one platform.

What this signals

Migration pressure is often a symptom of governance debt. When teams leave one identity provider for another, they are usually responding to cost opacity, lifecycle complexity, or enterprise feature gaps that have already accumulated inside the programme. The real question is whether the new platform reduces that debt or simply relocates it into a different control plane. For teams standardising identity operations, the migration becomes a chance to separate portable policy from provider-specific mechanics.

Connection-based enterprise models reward clearer identity boundaries. As B2B products mature, teams need cleaner separation between user identity, organisation identity, and access entitlements. That matters for both human and non-human identities because the same lifecycle mistakes tend to repeat when ownership, offboarding, and auditability are not explicit. The migration should therefore be used to simplify entitlement design, not just to modernise authentication.

Identity portability is becoming a programme requirement. If authentication rules, directory sync, and audit trails cannot be moved or recreated cleanly, the organisation is effectively locked into a control model that may not fit future scale. That creates long-term operational risk, especially where enterprise customers expect continuous login reliability and faster offboarding. Teams should assess whether their architecture can survive a second migration before they commit to the first.

For practitioners

• Map provider-specific dependencies before migration Inventory every Auth0-dependent flow, including Rules, Actions, custom domains, MFA factors, organisation logic, and audit logging. Classify each dependency as portable, replaceable, or redesign-required before any cutover plan is approved.
• Validate password hash and reset strategy early Confirm whether password hashes can be exported and imported in the supported format. If hashes cannot be preserved, define the forced reset path, support messaging, and recovery handling before you move users.
• Run SSO cutover as a controlled traffic migration Use phased rollout, dual-auth, or proxy-based routing where customer impact must be reduced. Monitor login success rates, callback behaviour, and rollback readiness during the transition window.
• Recreate enterprise governance controls deliberately Rebuild RBAC, directory sync, audit logs, branding, and verification flows as explicit controls rather than assuming feature parity. Test the post-migration system against real enterprise onboarding and deprovisioning scenarios.

Key takeaways

• Identity provider migration is really a control redesign exercise, because authentication, organisation structure, and lifecycle governance all move together.
• Enterprise SSO cutovers fail when teams treat customer connections like static configuration instead of live dependencies that need routing, monitoring, and rollback.
• Provider change is the right moment to rebuild MFA, audit, and provisioning controls so the new system matches enterprise governance requirements from day one.

Key terms

• Identity Provider Migration: The process of moving authentication, user records, and related access controls from one identity platform to another. In practice, it also shifts lifecycle logic, assurance methods, and operational dependencies, so the migration must be managed as a governance change rather than a simple technical transfer.
• SSO Connection: A configured trust relationship between an application and an enterprise identity system, usually using SAML or OIDC. It defines how login traffic is routed and how identity assertions are accepted, which means moving it safely requires preserving trust, routing, and customer-specific configuration.
• Lifecycle Control: The governance processes that create, modify, certify, and remove access as identities change over time. For migrations, lifecycle control matters because the new platform must support provisioning, deprovisioning, and audit continuity without leaving old access paths behind.
• MFA Re-enrolment: The process of requiring users to register new second factors after an identity change. It becomes necessary when the old authentication method cannot be carried forward, and it must be planned carefully because it affects assurance, recovery, and support effort at the same time.

Deepen your knowledge

Auth0 to WorkOS migration, enterprise SSO cutovers, and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are planning a provider transition or cleaning up identity dependencies, it is worth exploring.

This post draws on content published by WorkOS: How to migrate from Auth0 to WorkOS. Read the original.