IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
User migration — moving users without resets
A company is retiring its old identity system and moving 1,000,000 customers to a new one. The lazy plan is to email everyone: "Please reset your password." That loses customers. Your goal: move accounts so quietly that nobody notices.
- A password hash cannot be turned back into a password.
- Bulk import moves hashes you trust. Lazy migration moves the rest at first login.
- Keep both systems in sync, check the data, and plan a rollback.
- Avoid mass reset emails. They look like phishing.
What has to move
An account is more than a password. It is a record: email, name, phone, a verified-email flag, saved choices, and the hard part, the password hash. A hash is a one-way scramble of the password. The old system never stored Maya's real password. It stored only a hash to compare at login. You cannot turn a hash back into a password.
So how can users keep signing in with the password they know, when you must not know it either?
Two ways to carry passwords across
📦 Bulk hash import
You know the old hashing method, for example bcrypt at a certain cost. You export the hashes and import them as they are. When Maya types her password, the new system hashes it the same way and compares. It works on the first login. The catch: you must know and trust that method.
🐢 Lazy migration
Also called just-in-time migration. You import everything except the hashes. At Maya's first login, the new system quietly checks her password against the old system. If it matches, the new system hashes the password into its own store. It never asks the old system about her again.
Most real migrations use both. Bulk-import the hashes you can trust. Use lazy migration for hash formats you cannot import safely. The same trick upgrades a weak hash at the next login.
a kirana shop moving from an old credit book to a new one. Pages the owner can read are copied on a quiet night. That is bulk import. Pages in an odd shorthand wait. When that customer next walks in, the owner opens the old book, checks the page and copies it over. That is lazy migration.
What does Maya see? Nothing. She types her usual password and gets in. That is the goal.
Cutover, sync and a safety net
The cutover is the moment traffic switches to the new system. Four choices decide whether it is boring (good) or a headline (bad).
| Decision | The point |
|---|---|
| Trickle or big bang | A trickle cutover moves a small share of users at a time, so problems stay small. A big-bang cutover flips everyone at once. It is faster, but every bug hits every customer together. |
| Keep both in sync | During the window, both systems are live. A password Maya changes in one must reach the other. If not, she gets locked out. |
| Check the data | Count records in and out. Spot-check profiles. Confirm that the verified-email flags survived. |
| Plan a rollback | If the new system misbehaves, you must be able to send traffic back to the old one without losing data. |
A flood of "reset your password" emails looks exactly like a phishing campaign. It teaches customers to click such links. Avoid mass resets. If you must email, send people to your own site and never put a login link in the mail.
A migration is a chance to fix your account lifecycle. A clean import follows the same steps as SCIM provisioning: move the record, keep it in sync, and check that it arrived. It is also the joiner-mover-leaver lifecycle on fast-forward. Prune the dormant accounts instead of carrying them along.
Go deeper: Upgrade weak hashes while you migrate
OWASP's Password Storage cheat sheet prefers Argon2id, then scrypt. It says bcrypt is only for legacy systems, with a work factor of at least 10. Most bcrypt code reads only the first 72 bytes of a password, so set a matching maximum length. The usual way to upgrade is to hash the password again with the new method at the next successful login. Store the method and its settings with every hash, so old and new hashes can live side by side. For very old hashes such as MD5 or SHA-1, OWASP suggests expiring the password. Then the old hash is useless to a thief. You can wrap an old hash inside a stronger one. Replace it with a direct hash at the next login.
Go deeper: Renumbering an apartment block
Think of renumbering a whole apartment block while everyone sleeps. Big bang means changing every door number at 3 a.m. and hoping. Trickle means one floor a night. Lazy migration is smoother still: you fix a door only when someone walks up to it. If the new key does not turn, you check the old lock and cut a new key right then. By morning every home works.
🧪 Interactive lab — enable JavaScript to play with this one.
Just moved to a new identity system? Grade the new issuer's logout and revocation setup with Logout Check. Confirm that the sessions it hands out are hardened with Cookie Check.