The reason teams leave Firebase Authentication is almost always the same: their users are in India, their data isn't, and a compliance review or an RBI requirement just made that a problem. The reason they don't leave is fear of one thing — passwords. Migrating auth feels like it must end in a mass "please reset your password" email that tanks your login rate and floods support.

It doesn't have to. Firebase lets you export its password hashes, and a destination IdP that can verify those hashes lets your users keep logging in with the passwords they already have — while you move them over invisibly, with zero downtime. This is the playbook: what to export, the trickle-migration pattern that avoids resets, the cutover sequence, and the gotchas that bite if you're not expecting them.

Why teams move off Firebase Auth

The driver is usually residency. Firebase Authentication processes data only in the US and isn't a region-selectable product, so your Indian users' identity data leaves the country. For a fintech under RBI's payment-data localization rules that's a gap today; for a company facing DPDP accountability it's a loss of control over breach response, data-principal rights, and the audit trail. None of this is a knock on Firebase's engineering — the DX and free tier are excellent — it's that a US-only identity layer is the wrong fit for Indian users you're accountable for under Indian law.

Whatever the trigger, the migration mechanics are the same.

The thing everyone fears: passwords

You can't migrate passwords by reading them — they're hashed, and a good system can't reverse them. So the question is: can your new IdP verify a password against the old system's hash? If yes, users keep their passwords and never notice. If no, everyone resets.

Firebase makes "yes" possible because it lets you export its password hashes along with the parameters needed to verify them. The destination IdP just has to speak Firebase's hashing scheme.

Firebase's hashing: a forked scrypt

Firebase uses a modified version of scrypt. When you run the export (firebase auth:export users.json via the Firebase CLI), each user record includes their passwordHash and salt, and the project's hash parameters come separately:

base64_signer_key (the project signer key)
salt_separator
rounds
mem_cost

With those four parameters plus a user's salt, a system can recompute Firebase's scrypt hash for a submitted password and check it against the stored passwordHash. That's the whole trick: the destination verifies the Firebase hash at login, so the password the user types still works.

Two migration strategies

Lazy / trickle migration (recommended). Import every user into the new IdP carrying their Firebase hash and parameters. The first time a user logs in, the new IdP verifies the submitted password against the Firebase hash; if it matches, it transparently re-hashes the password with its own algorithm (bcrypt or Argon2) and stores that going forward. Each user is silently upgraded on their next login. No reset emails, no downtime, and after a while most active users are fully migrated. Dormant accounts keep their Firebase hash until they return.

User logs in ──> new IdP has a Firebase hash for them?
                   │ yes → verify with Firebase scrypt params
                   │        match? → re-hash with bcrypt/argon2, store, log them in
                   │ no  → verify with native hash (already migrated)

Bulk migration. Import everyone up front and verify against Firebase hashes from day one, same as above but without waiting for logins. Use this when you need a hard cutover date rather than a gradual drain.

Most teams want the trickle pattern: it turns a scary big-bang into a background process.

The zero-downtime cutover

Export users from Firebase (firebase auth:export) and record the project hash parameters.
Import the users into the new IdP — emails, hashes + params, email-verified status, and any custom metadata — mapped to the new schema.
Switch new logins to the new IdP, which verifies against Firebase hashes for not-yet-migrated users and native hashes for migrated ones.
Trickle-upgrade passwords on login automatically.
Decommission Firebase Auth once your active base has migrated and you've handled the long tail (a final forced reset for the handful of never-returning accounts, if you want to fully retire it).

During steps 3–4 both systems can coexist; there's no moment where users can't log in.

Gotchas that bite

Social-login users have no password. Google/Facebook/Apple sign-ins migrate by re-linking the same provider on the new IdP, not by hash import. Map them by verified email or provider subject.
MFA and phone enrollments don't always export cleanly. Plan to re-enroll second factors, ideally nudging users to stronger factors (passkeys or TOTP) during the move.
Carry the email-verified flag. If you drop it, migrated users get re-prompted to verify — exactly the friction you're trying to avoid.
Custom claims / roles need an explicit mapping to the new IdP's model; they won't come across by themselves.
Rate-limit the import. Bulk-creating thousands of users can trip protections on either side; batch it.

Handle these and the migration is genuinely invisible to the people who matter — your users.

Why NamoID for the destination

The whole plan hinges on the destination IdP doing two things: keeping the data in India, and verifying Firebase's hashes so nobody resets. NamoID is built for exactly this migration — an India-resident OIDC issuer that imports your Firebase users with their scrypt hashes and runs the trickle pattern, re-hashing to its own algorithm on first login. You get the residency that triggered the move and a cutover your users never feel. We'll help you map the Firebase export to the import and plan the long tail.

If residency is the reason you're moving, this is the move that fixes it without the reset email everyone dreads.

FAQ

Will my users have to reset their passwords? No — with the trickle pattern, Firebase's exported scrypt hashes are verified at login and upgraded transparently. Only fully dormant accounts you choose to retire at the end might need a reset.

Is there downtime? No. Both systems coexist during the cutover; logins route to the new IdP, which handles migrated and not-yet-migrated users alike.

What about users who signed in with Google or Apple? They have no password to migrate — you re-link the same social provider on the new IdP and match them by verified email.

How long does it take? The import is fast; the trickle completes as users log in over the following weeks. You decide when to force-migrate the remaining dormant tail.

Move the data home without moving the user

Auth migrations are scary for exactly one reason, and Firebase's hash export removes it. Export the users and parameters, import them into an IdP that can verify Firebase's scrypt, trickle-upgrade on login, and run both systems side by side until you're done — no resets, no downtime.

NamoID is the India-resident destination for that move: it verifies your Firebase hashes, keeps your users' identity data in India, and gives you an OIDC issuer with a DPDP-ready audit trail on the other side. Start your migration with us — we'll map your export and plan the cutover with you.