In your Cognito User Pool Lambda triggers settings, attach your Lambda function to the User migration trigger.
Your Lambda receives an event with triggerSource set to UserMigration_Authentication (sign-in attempt) or UserMigration_ForgotPassword (password reset for unknown user); branch your logic accordingly.
For UserMigration_Authentication, validate the credentials from event.userName and event.request.password against your legacy user directory; if valid, populate event.response.userAttributes with at minimum email and email_verified.
Set event.response.finalUserStatus to CONFIRMED to allow immediate sign-in without an email verification step, or to RESET_REQUIRED to force a password reset.
For UserMigration_ForgotPassword, verify the user exists in the legacy directory without checking their password, populate userAttributes, and allow Cognito to send the password reset flow.
After migration completes, Cognito creates the user in the pool; subsequent sign-ins will not trigger the migration Lambda for that user.
Known gotchas
The migration Lambda also has a hard 5-second Cognito-enforced timeout; any legacy directory call (LDAP, external API, legacy database) must complete within that window or the migration fails and the user cannot sign in.
If you set finalUserStatus to CONFIRMED, the user's password is immediately set to whatever they provided; if you do not want to expose passwords to your Lambda (e.g., for LDAP with one-way comparison only), you cannot use this status safely.
Users who have already been migrated will be found in Cognito on their next sign-in attempt and the migration Lambda will not be invoked; ensure your legacy system is not decommissioned before all active users have signed in at least once.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp