Migrate from AWS Cognito to Stytch: A 60-Day Playbook

Migrations from Cognito are common in 2026, see the Cognito migration guide for context. This playbook covers the specific path to Stytch, one of the modern destinations that ships strong import APIs and a passwordless-first stack. The same pattern applies with minor variations to migrations toward Auth0, MojoAuth, Clerk, or Descope; the playbook calls out vendor-specific notes where they matter.

Phase 1, Discovery and parallel setup (7 days)

Before touching production, map the surface area and bring up Stytch in parallel. Most migration failures come from underestimating the application code surface, token validation, federated providers, custom claims, that the team hasn't audited. The first week is inventory plus parallel infrastructure setup. No production changes yet.

Cognito inventory. User Pool size, custom attributes, federated providers (Google, Facebook, Apple, SAML), MFA configuration, password policy, Lambda triggers (pre-signup, pre-token-generation, post-confirmation). Document every customization.

Application code inventory. Where does the code call Cognito SDKs? Where does it validate Cognito JWTs? Where does it call AWS Amplify Auth? Where does API Gateway use Cognito as authorizer? Each call site needs a migration counterpart.

Stytch project setup. Provision the Stytch project. Configure auth methods (email magic link, OAuth, passkeys, TOTP) matching Cognito's current scope plus modernizations the team wants. Configure callback URLs, JWKS endpoint, custom claims schema.

Migration playbook decision. Stytch's import API supports bulk import with verify-on-next-login (JIT) for password validation. Confirm the team understands the JIT pattern: passwords aren't migrated in bulk; they're verified on first sign-in via Stytch calling back to Cognito.

Phase 2, User import and JIT verification hook (14 days)

Bulk import the user records into Stytch with verify-on-next-login configured for password validation.

User export from Cognito. Use ListUsers API with attribute pagination to export the full user record set. Preserve the Cognito sub as a custom attribute (cognito_sub) so application database foreign keys remain resolvable.

Bulk import to Stytch. Stytch's import API accepts user records in batches. Map Cognito attributes to Stytch user fields: email, phone, custom attributes. Mark each imported user with a migration_state: "pending" flag.

JIT verification hook. Configure Stytch's password verification webhook to call Cognito's AdminInitiateAuth for users still flagged pending. On successful Cognito verification, Stytch hashes the password with its own algorithm (argon2id by default) and clears the pending flag. The user experience: identical sign-in; the migration is invisible.

MFA flag carry-over. Mark users with TOTP enrolled. Stytch cannot import the TOTP secret (it's a shared secret with the user's authenticator app), so the user re-enrolls TOTP on next sign-in via a one-time prompt.

Federated identity prep. Configure Stytch's OAuth providers (Google, Facebook, Apple) with the client IDs/secrets that match Cognito's. Federated users will re-bind on next federated sign-in by email match.

Phase 3, Application code migration (21 days)

The longest phase. Replace AWS Amplify Auth and Cognito SDK calls with Stytch SDKs.

SDK swap. aws-amplify/auth → @stytch/react (web) or @stytch/vanilla-js (frontend), stytch (Node backend). Refactor sign-in, signup, sign-out, password reset, MFA challenge, federated sign-in, account management. The Stytch SDK is generally more compact than Amplify; the surface area shrinks.

Token validation. Cognito JWTs use AWS-managed JWKS; replace with Stytch's JWKS endpoint. Audit every API endpoint that validates a token, middleware, route guards, GraphQL context, gRPC interceptors. Update the JWKS URL, audience claim, and issuer claim.

API Gateway authorizer. If using Cognito User Pool authorizer, swap to a JWT authorizer pointing at Stytch's JWKS. The authorizer Lambda (if custom) needs the same swap; alternative is to use API Gateway's native JWT authorizer with a Stytch JWKS configuration.

User management APIs. Replace AdminCreateUser, AdminUpdateUserAttributes, AdminAddUserToGroup, etc. with Stytch's users and roles APIs. Application admin flows that touched Cognito need to redirect to Stytch.

Lambda trigger equivalents. Cognito Lambda triggers (pre-signup, pre-token-generation, post-confirmation) map to Stytch webhooks or custom claims hooks. Re-implement the business logic against Stytch's webhook contract.

Test coverage. Update integration tests to point at Stytch test environment. Confirm sign-in, signup, password reset, MFA, federated, and admin flows all pass against Stytch.

Phase 4, Cutover and observation (14 days)

With the parallel system ready and code migrated, cut over to Stytch as the primary auth.

Staged rollout. Direct a small percentage (5-10%) of new sign-ins to Stytch first. Monitor for errors: token validation failures, JIT verification failures, federated sign-in issues. Two-day observation, then ramp to 50%, then 100%.

Existing session handling. Users with active Cognito sessions can continue until their tokens expire; on next sign-in, they hit Stytch and JIT migration kicks in. Alternatively, force re-sign-in by invalidating Cognito sessions, faster migration but worse UX.

Monitoring. Track migration progress: percentage of users migrated, JIT success rate, JIT failure rate (broken Cognito accounts, suspended users), sign-in success rate end-to-end. Dashboards visible to engineering, product, and support.

Fallback path. Document the rollback in case Stytch issues emerge. Realistically, after Phase 3 completes, full rollback is impractical; keep targeted feature-flag switches for hot fixes.

Phase 5, Long-tail forced reset and Cognito retirement (4 days)

Two weeks after cutover, JIT migration has covered active users, typically 80-90%. The remaining users haven't signed in since cutover.

Forced reset campaign. Email the remaining users explaining the migration and offering a password reset link via Stytch. The reset establishes their Stytch credential without needing Cognito.

Cognito decommission. Once the long tail is addressed:

• Stop Cognito JIT calls (Stytch no longer queries Cognito for password verification).
• Snapshot Cognito User Pool for archive.
• Delete the User Pool when retention policy allows.
• Remove AWS Amplify dependencies from package.json.
• Cancel Cognito-specific monitoring.

Post-migration audit. Compare pre-migration and post-migration auth metrics: sign-in success rate, support ticket volume, MFA enrollment rate. Document the result.

Anti-patterns to avoid

• Big-bang migration without JIT. Forces all users to reset passwords at cutover, generates massive support volume.
• Skipping Lambda trigger re-implementation. Cognito Lambda triggers often encode business logic the team has forgotten about. Audit and re-implement before cutover.
• No federated rebinding plan. Users discover Google/Apple sign-in is broken post-migration. Re-bind via email match in JIT.
• Underestimating token validation surface. Every API endpoint, every microservice, every middleware needs to migrate. Skipping any leaves intermittent failures.
• No fallback path documented. Cutover incident response improvises rollback during the worst moment.

What success looks like at day 60

• Stytch is the primary auth system. All new sign-ups and active sign-ins go through Stytch.
• 80-90% of active users migrated via JIT in the first 30 days post-cutover.
• Long tail addressed via forced password reset campaign.
• Cognito User Pool retired or archived, AWS bill reduced.
• Modernizations adopted, many migrations seize the moment to add passkeys, magic links, or stronger MFA.

For the Cognito migration framework, see the Cognito migration guide. For the post-migration optimization, see the passkey rollout playbook.