Amazon Cognito user pool limits that trigger a migration

Use one test before you accept a Cognito limit as a constraint to work around: if a required attribute, the sign-in alias model or an immutable custom attribute no longer matches how your identity model works, the fix is a new user pool and a move of every user into it. Cognito does not let you alter these settings on an existing pool, so the question is not whether the change is possible but whether the cost of rebuilding is lower than the cost of living with the old model. Write down the specific setting, the identity rule it conflicts with, and the number of applications and integrations that depend on the current pool before you decide.

The operational consequences of a new pool reach well beyond the user records. Every app client has to be recreated or re-pointed, and each client's redirect URIs, scopes and token settings need to be checked against the new pool. Lambda triggers attached to the old pool do not carry over, so their logic must be re-implemented or deliberately dropped. Tokens issued by the old pool stop being valid for the new one, which means sessions end and the sub claim that downstream services store will change unless you plan for it. Ask your team to inventory which services key on sub, which store the pool's user pool ID, and which depend on custom attributes, because those are the places where a rebuild breaks things silently.

A new pool is also the moment to ask whether a self-hosted identity provider is the better rebuild. Moving to a self-hosted provider changes who operates the identity service, where the database lives and how the cost recurs, so it deserves its own comparison rather than being treated as a pool replacement by default. The mechanics of exporting profiles, handling passwords that cannot be exported and mapping triggers are covered on the sibling pages on exporting users from Amazon Cognito and the migration guides for Keycloak and ZITADEL, so read those before you set a date. Confirm each limit against current AWS documentation for your region, since the settings that are fixed can change over time.

The most consequential limit for a rebuild is what Cognito will not release. Cognito user exports do not include password hashes, so whatever you move to a self-hosted IdP, the users' passwords do not come with them. That leaves two paths: a forced password reset for every user, or a sign-in-time migration where the new IdP checks the old credential on first login and imports it. The sibling page on exporting users from Cognito covers what the export does contain, including the paging limit and attribute list. Read it before you choose, because the answer determines how much of the user base you can move without friction.

Choose between those two paths by looking at your user population and your support capacity, not at the platform. A forced reset is simple to reason about but generates help-desk volume on cutover day and interrupts users who only signed in occasionally. A sign-in-time migration keeps users moving but requires a bridge that validates the legacy credential, usually through an event or trigger that calls Cognito while the pool still exists. Confirm with your team how long the Cognito pool can stay live during the transition, and whether the sign-in bridge can run until dormant accounts are either migrated or retired.

The limit also shapes what must be preserved. Applications often key their data on the Cognito sub claim, so the new IdP must either issue the same identifier or your applications need a mapping step before cutover. Groups, app client settings and attribute names also need a documented mapping, because none of them transfer automatically. Ask any implementation partner to write down, per application, which identifier the app stores, which claims it reads and how the cutover will handle users who have never signed in on the new platform.

Before you plan a rebuild, confirm the capabilities and limits of each candidate platform against its own documentation, not against this page. Start with the Keycloak documentation on the Keycloak site, including the server administration guide and the upgrading guide, which set out realm, client and federation behavior and the upgrade path between releases. For ZITADEL, check the ZITADEL GitHub repository and its self-hosting and organizations documentation, since its tenant model (instances, organizations and projects) determines whether your current user pool structure maps cleanly. For authentik, read the authentik pricing page to confirm which features sit in the free edition and which need an enterprise license. If you are comparing against Auth0 as well, the Auth0 bulk user exports documentation shows what that platform will and will not release.

Cognito behavior needs the same discipline. The settings this topic covers, such as required attributes, username versus alias sign-in and custom attribute definitions, are documented by AWS for the Cognito user pool API and console. Confirm them in your own account and Region rather than assuming the defaults you remember. Open the existing pool's configuration, record every attribute schema entry and sign-in option, and check whether any app client, Lambda trigger or domain setting depends on them. Ask AWS support or your account team to confirm any behavior you cannot verify in the documentation, and write down the answers, because they will drive the new-pool-versus-migration decision.

Treat the vendor documentation as a dated source. Platform versions, supported database versions and license terms change, so record the version you tested against and the date you checked it. Re-verify the specific claims your decision depends on just before any design review or contract signature, and keep the printed or exported configuration as evidence for the design record.