Migrating from AWS Cognito: A 2026 Practitioner's Guide

Key takeaways

• Cognito's strengths (AWS-native, low cost at low scale) are real; its weaknesses (user pool quirks, limited B2B Org model, slow feature velocity) drive migrations as the product matures.
• Common destinations: Auth0 (mature, expensive), Microsoft Entra External ID (price-competitive, strong M365 fit), Stytch / Clerk / MojoAuth (modern DX), self-hosted Keycloak / Ory (cost ceiling).
• The migration mechanics matter most: password hashes (Cognito stores them but doesn't always export cleanly), MFA enrollments, federated identities, custom attributes.
• JIT migration (verify-on-next-login + write to new system) is the standard pattern; bulk migration is rarely all-or-nothing.
• Plan the cutover in phases: identity migration, application code migration, federated provider re-binding, monitoring, fallback path.

Why teams leave Cognito

Cognito remains a reasonable choice for AWS-locked teams at single-digit-thousand MAU. The migrations covered here are for teams who've outgrown that profile.

Where teams go

The 2026 migration paths fall into four buckets:

Mature managed CIAM. Auth0 (now Okta) is the most common destination, feature-complete, well-supported, expensive at scale. Microsoft Entra External ID is price-competitive and strong for teams already on M365.

Modern managed CIAM. Stytch, Clerk, MojoAuth for passwordless-first / passkey-first stacks; better DX than Cognito with stronger feature velocity.

B2B-specialized CIAM. Frontegg, WorkOS, Auth0 Organizations, SSOJet when the migration is driven by B2B SSO and SCIM requirements that Cognito's User Pool model handles poorly.

Self-hosted open source. Keycloak, Ory, FusionAuth, Zitadel for cost-sensitive, sovereignty-sensitive, or AWS-decoupling migrations.

For the build-vs-buy framework that informs which destination fits, see the build-vs-buy guide.

The five things to migrate

A Cognito migration has five moving parts:

1. User identities. Email, phone, custom attributes, group memberships.
2. Credentials. Passwords, MFA enrollments, passkeys (if any).
3. Federated identity bindings. Google, Facebook, Apple, SAML federation.
4. Application integration. SDK swap, token validation, callback URLs.
5. Operational integration. Logs, monitoring, alerts, CI/CD.

Each has its own pattern; the order matters.

Identity export

Cognito provides:

• ListUsers API for paginated user export with attributes
• AWS-managed export to S3 for User Pool snapshots (limited fields)
• Custom attribute export via AdminGetUser per user

Standard pattern: use ListUsers with attribute pagination for the user record core (email, sub, custom attributes, status); preserve the Cognito sub as a foreign-key reference if downstream systems use it.

User identifiers (the Cognito sub) typically need to be either preserved as a custom attribute in the new system or mapped via a translation table. Database foreign keys to cognito_sub will break otherwise.

Password migration: JIT pattern

Cognito stores password hashes in a managed format that does not cleanly export. The standard 2026 migration pattern:

1. Pre-migration: import user records (without password hashes) into the destination CIAM. Mark each as "needs migration."
2. At next login: the new CIAM's authentication endpoint receives the credential. If the user is "needs migration," it calls Cognito's AdminInitiateAuth to validate against Cognito's hash. On success, it writes the new hash (using the new CIAM's algorithm, bcrypt, argon2, or vendor-managed) and clears the migration flag.
3. Long tail: users who don't log in within 30-90 days get a forced password reset email. Account access continues via the reset flow.

Auth0, Stytch, MojoAuth, and most modern CIAM ship "custom database" or "import hooks" that automate this verify-against-source pattern. The migration is largely transparent to users.

MFA migration

TOTP secrets ARE stored client-side (in the user's authenticator app). The Cognito-side state is minimal: "this user has TOTP enabled" plus the secret. Most CIAM cannot import the existing TOTP secret (it's a shared secret with the user's app, and re-importing it doesn't align with vendor security practices). Standard pattern:

1. Mark MFA-enrolled users in the new system without the secret
2. At next login prompt the user to re-enroll MFA in the new system
3. Brief the customer that MFA re-enrollment is required as part of the migration

For SMS MFA, the phone number is a regular attribute and can be imported; the user re-enrolls SMS-as-MFA on the new system.

Federated identity rebinding

Users who signed up with Google / Facebook / Apple have a federated identity binding in Cognito (provider + provider-specific subject identifier). The new CIAM has its own federation configuration; the binding needs to be re-established.

Typical pattern: at next login via the federated provider, the new CIAM creates the federation binding fresh. The application matches the federated email to the imported user record by email address. For users with multiple federated providers, each gets re-bound on its first post-migration use.

Application code migration

Code changes typically include:

• SDK swap. AWS Amplify Auth → vendor-specific SDK (auth0-react, @stytch/react, @mojoauth/web, etc.).
• Token validation. Cognito JWTs use AWS-managed JWKS; replace with the new CIAM's JWKS endpoint. Audit all token verification call sites.
• Callback URLs. Update redirect URIs in the new CIAM's app configuration.
• API Gateway authorizer. If using Cognito as an API Gateway authorizer, swap to a JWT authorizer pointing at the new JWKS or to the new vendor's authorizer.
• User management APIs. Replace AdminCreateUser, AdminUpdateUserAttributes, etc. with the new vendor's user management APIs.

The application code migration is typically the longest phase, 2-6 weeks for a mid-complexity codebase.

Cutover plan

A safe cutover sequence:

1. Set up parallel systems. Both Cognito and the new CIAM running, application configured to call both for read operations.
2. Migrate writes. New users created in the new CIAM; existing user updates flow to the new CIAM. JIT migration kicks in at login.
3. Monitoring. Track migration rate, login success rate on each side, error rate. Two-week observation window.
4. Cut writes off Cognito. All user management operations target the new CIAM only.
5. Read-only Cognito for the JIT bridge. Cognito remains live for the JIT password validation flow only.
6. Wind down. Once JIT migration completes (usually 30-60 days for active users, plus the forced-reset long tail), Cognito can be retired.

Anti-patterns

• Big-bang migration without JIT. Forces all users to reset passwords on day one, generates massive support volume and damages user trust.
• Skipping the federated rebinding plan. Users discover their Google sign-in doesn't work post-migration; support tickets follow.
• Underestimating the application code surface. Token validation, authorizer logic, custom claim handling all need to migrate; missed call sites cause intermittent failures.
• No fallback path. If the new CIAM has issues, the team needs a documented rollback before cutover, not invented during incident response.

Vendor-specific notes

• Auth0: "Custom Database" migration with the Cognito verify hook is the standard pattern; well-documented.
• Stytch / Clerk: import APIs plus JIT verification hooks; mature for Cognito source.
• MojoAuth: import + JIT verification with passwordless-first nudge, many migrations seize the moment to introduce passkeys.
• Keycloak / Ory / Zitadel (self-hosted): import via REST APIs; JIT verification implemented as a custom authentication SPI.

For the related migration guide, see migrating from Auth0, and for the build-or-buy framework that informs the choice, see build vs buy CIAM.