All posts
Security

Migrating Authentication Providers Without Forcing Everyone to Reset Their Password

By

October 26, 2026

7 min read

Moving from Auth0, Firebase, a home-grown system or anything else to Cognito or another provider: bulk import with password hashes (Cognito accepts bcrypt, scrypt, Argon2id and PBKDF2 since July 2026), lazy migration at sign-in, what cannot move, and a cut-over plan with a way back.

Authentication
Migration
Amazon Cognito
Auth0
Identity

Two ways to move users

Bulk import with hashes

Lazy migration at sign-in

How

Export users and password hashes, import them into the new provider

On each user's first sign-in, the new provider checks the password against the old system and creates the user

On Cognito

CSV import with password hashes — bcrypt, scrypt, Argon2id or PBKDF2-SHA256 — since July 2026

The user migration Lambda trigger

Pros

Done in one go; the old system can be switched off

No hash export needed; works with any old system you can call

Cons

Requires the old provider to export hashes, sometimes only on request

The old system must stay up until the long tail has signed in

Most migrations use both: bulk-import everyone whose hash you can export, keep lazy migration for the rest, and after a few months send the remaining inactive users a password reset.

Want a second opinion on this for your system?

Book a free 30-minute call. You'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.

What does not move

  • MFA enrolments — authenticator apps and SMS factors usually need re-enrolment, so prompt for it after the first sign-in on the new system.

  • Passkeys, in practice: plan for re-enrolment.

  • Social sign-in links: re-link by verified email, carefully — matching on an unverified email is an account-takeover bug.

  • Provider-specific hooks and rules: re-implement them as triggers or code in the new system, and test each.

  • Active sessions: users sign in once more at cut-over.

A cut-over plan with a way back

  1. Make your own user ID the primary key in your application, with the provider's ID as an attribute — the change that makes every future migration easier.

  2. Run the new provider in parallel for internal users and a test cohort.

  3. Bulk-import, enable lazy migration, and switch new sign-ups to the new provider.

  4. Move existing users' sign-in behind a flag, a cohort at a time, watching failure rates.

  5. Keep the old provider read-only for a rollback window; delete exported hash files once imported.

hoolco Monthly Review

Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.

As of October 26, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.