Migrate from Firebase Auth: Credentials and Cutover
Plan a Firebase Auth migration by testing hash compatibility, identity mapping, MFA, passkeys, sessions, and rollback before promising no resets.
A Firebase Authentication migration can preserve some users' passwords when the destination supports the exported hash format and parameters. Verify that support with synthetic accounts before promising a migration without password resets.
User identifiers, social identities, MFA, passkeys and application sessions need their own migration plan. Running two identity providers does not by itself guarantee uninterrupted access.
Confirm why you want to move
List the requirements that trigger the evaluation. These can include operating cost, data processing locations, support needs or product behavior. Compare the current service with the proposed destination against the same requirements.
Firebase publishes service-specific processing information. Review the Authentication entry and the relevant contract rather than inferring identity-data location from a database region. A different hosting region does not automatically establish compliance for your application. Firebase privacy information.
Use the provider-neutral migration runbook for the complete cutover and rollback process.
Inspect an export before choosing the password path
Firebase's CLI can export accounts. Run this illustrative command only in an approved, protected workspace with the appropriate project access.
umask 077
firebase auth:export private-users.json --project YOUR_PROJECT_IDFirebase's modified scrypt configuration differs from standard scrypt. Exported password material and project hash parameters are sensitive. Firebase also documents cases where an exported account has empty password hash fields. Classify accounts by their actual export result. Firebase export and hash documentation.
An empty hash field does not prove that the account can be migrated by copying a password. Social identities and imported credentials can need a different route.
Test destination compatibility
| Question | Evidence needed |
|---|---|
| Can the destination verify this exact Firebase hash format? | A documented feature and synthetic positive and negative tests |
| Can it safely retain the required parameters? | Secret storage and access controls |
| Can it upgrade a verified password? | A documented rehash path and failure handling |
| Can it import account identifiers and status? | An explicit mapping and collision checks |
| Can it handle missing credential material? | A separate recovery or enrolment route |
Firebase's own import documentation describes supported Firebase import operations. It does not establish that another provider implements the same compatibility. Firebase user import documentation.
Choose a path for each account group
For compatible exported hashes, the destination may verify the old hash and replace it after a successful login. This is often called just-in-time or lazy migration. It depends on destination support, correct parameters and a controlled update process.
For incompatible or unavailable credentials, plan reauthentication, recovery or credential enrolment. Explain any required user action before the cutover. Keep dormant accounts in a separate group with an explicit retirement policy.
Do not test the transition by requesting users' plaintext passwords. Test with synthetic accounts that you control.
Map identities without merging accounts by email
Keep the Firebase user identifier, upstream provider identity and application account identifier in separate mapping fields. Verify the supported export information for each provider.
A matching email address alone should not trigger an account merge. Apply an explicit linking policy and require the relevant proof of account control. Handle duplicate addresses, changed addresses and provider-specific subjects deliberately.
MFA secrets, phone factors and passkeys need separate compatibility checks. Passkeys depend on the relying-party identifier and credential lifecycle. An ordinary user export is not evidence that a passkey will work at a different domain. Passkey deployment guide.
Rehearse cutover and rollback
- Create a synthetic account for each credential group.
- Record the expected application account mapping.
- Test successful and failed sign-in attempts.
- Test recovery and any MFA enrolment step.
- Check roles and organization membership after sign-in.
- Test old and new application sessions separately.
- Define a measurable stop condition for the cutover.
- Rehearse rollback with post-cutover password changes.
Rollback needs special care after the destination changes a password or creates a new account. An older export cannot reconstruct those changes. Design reconciliation before using rollback as a launch promise.
Answer user-impact questions conditionally
Will users need a password reset?
Some users may avoid a reset if their credential can be exported and the destination supports it correctly. Other accounts can require recovery or enrolment. Validate each group and communicate the expected user action.
Can the migration avoid downtime?
A rehearsed transition can reduce disruption. Availability depends on routing, session handling, credential compatibility, upstream providers and rollback. Measure those conditions in a rehearsal before describing the launch as uninterrupted.
Review destination readiness with NamoID
NamoID's primary production infrastructure runs in AWS Mumbai. Confirm the complete data path and required product behavior for your application. Firebase hash import and just-in-time rehashing are requirements to verify with the team, not published self-service migration capabilities.
Bring your user groups, required factors and launch constraints to Slack for an early response. Contact the NamoID team