Guides

Migrating off Amazon Cognito: a practical checklist

July 2026

Teams rarely leave Cognito over one dealbreaker. It is usually accumulation: the hosted UI you cannot make match your product, per-user-pool limits that fight your tenant model, triggers spread across Lambda functions nobody wants to touch, and login flows that take days to change instead of minutes. Whatever the reason, the migration itself follows the same shape every time.

What moves cleanly

User attributes, emails, verification status, and group or role assignments all export through admin APIs. Your OIDC-facing configuration (client IDs, redirect URIs, scopes) maps almost one-to-one onto any other OIDC-speaking system: your applications keep doing authorization-code flows, they just do them against a new issuer.

What does not move

Password hashes. Cognito will not export them under any circumstances, and no amount of support tickets changes that. This single fact decides your migration strategy, because the alternative to handling it well is forcing every user through a password reset on the same day.

The two workable strategies

Lazy migration keeps Cognito alive behind your new system for a while. Each user's first login is verified against Cognito; on success, the new system sets its own credential record and that user never touches Cognito again. After a decided window, say ninety days, the stragglers get a reset email and Cognito is turned off. Most users never notice anything happened.

Reset-based migration moves everyone at once and sends each account a set-your-password link. It is simpler to run and reason about, and it is the right choice when your active-user count is small or an email round trip is acceptable. For products with passkeys or magic links enabled, many users can skip the password entirely and enroll something better on their first visit.

The checklist

• Inventory every app client, trigger, and identity-provider connection in the pool. The triggers are where surprises live.
• Export users and attributes; map groups onto the new system's roles per organization.
• Pick lazy or reset-based migration and write down the cutoff date before you start.
• Stand up the new issuer and point a staging app at it end to end, including logout.
• Migrate sessions by expiry: let old sessions run out rather than revoking everyone at midday.
• Keep an audit trail on both sides for the overlap window, so every sign-in is explainable.

Our recommendation