AWS Cognito Support
Migrating users to Amazon Cognito with a Lambda trigger.
Cognito cannot import password hashes, so a CSV import forces every user to reset their password. The user migration Lambda trigger avoids that: on first sign-in it checks credentials against your old system and creates the user in Cognito. We build it carefully so it is secure and temporary.
When You Need This
The situations where this work pays for itself.
Signs it is time
- You are moving from a home-grown, Auth0-style or legacy user database to Cognito
- You do not want to email every user a password reset
- Some users are inactive and may never log in
- You need to keep user attributes and verification status
- A CSV import was rejected or forced resets
What you get
- The migration Lambda with tests
- User pool and app client configuration in infrastructure as code
- An attribute mapping document
- A migration progress report and decommission plan
How we do it
A clear, safe process you can follow along with.
1. Inventory the source users
We review the legacy store: identifiers, email, phone, attributes, verified flags, password hashing and any MFA. This decides the attribute mapping and whether a trigger is workable.
2. Create the user pool and schema
We define the pool, sign-in attributes, required and custom attributes and password policy. Standard attributes cannot be changed once created, so we plan them first.
3. Build the migration Lambda
The trigger receives the username and password on first sign-in. It calls the old system to verify them, then returns userAttributes and a finalUserStatus, and messageAction SUPPRESS if you do not want a welcome message. On a forgot-password event it looks up the user without a password.
4. Enable the right auth flow
The first sign-in must use a flow that sends the password to Cognito, such as USER_PASSWORD_AUTH, enabled on the app client. We check current documentation for flow support and update the client app.
5. Secure it
The Lambda calls your old system over TLS with least-privilege credentials, never logs passwords, handles lockouts and rate limits, and returns generic failures. Passwords flow through it, so we restrict who can change it.
6. Migrate the rest and clean up
We track migrated users, bulk import or email the long tail who never log in, and after a defined cutoff remove the trigger and the connection to the old system.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Logging the password
The trigger sees plaintext passwords. Never log the event.
Leaving the trigger on forever
It keeps a link to the old system and extends the attack surface.
Mapping unverified emails as verified
Setting email_verified wrongly can enable account takeover through recovery flows.
Changing schema late
Standard attributes cannot be removed or changed after creation.
Frequently Asked Questions
Can I import password hashes into Cognito?
No. Cognito does not accept existing hashes, so you either migrate on first sign-in with a trigger or require password resets.
What happens to users who never log in?
They are not migrated by the trigger. You can bulk import them with a CSV, without passwords, and prompt a reset, or archive them.
How long should the migration trigger stay enabled?
Long enough for most active users to sign in, typically a period you choose from login patterns. Then remove it.
Want Help With Migrating users to Amazon Cognito with a Lambda trigger?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required