Migrate from Firebase Authentication to Zitadel

Zitadel cannot import the password hashes that Firebase Authentication stores, so the migration plan has to account for that from the start. Firebase hashes use a proprietary modified scrypt algorithm with project-specific keys, and Zitadel cannot process them. The Zitadel Firebase guide therefore treats imported Firebase hashes as data to discard. Your export may still contain hash fields, and the import process should not carry them into Zitadel. Confirm this behavior against the current Zitadel Firebase guide and your chosen import tooling before you set a cutover date, because the decision affects every user record you move.

In practice, each Firebase user ends up in one of two states. Either the user sets a new password in Zitadel, or Zitadel verifies the submitted password against Firebase during a transition period. Outside those two paths, existing passwords cannot be carried over. Users who never sign in during the window will need a reset later, so support should expect that volume. Before the import, identify which accounts are active, which rely only on federated or social sign-in, and which use factors such as passkeys that the Firebase export will not describe.

The Zitadel guide offers two routes. Bulk import moves user records ahead of the cutover and requires a password reset at first login. This keeps the cutover simple, but every user passes through a reset prompt. Just-in-time migration leaves credentials in Firebase: when a user signs in, Zitadel checks the password against Firebase's REST API. The guide suggests a migration window of about 30 to 90 days for this approach. Choose a route before you build the import pipeline, because just-in-time depends on Firebase staying reachable and correctly configured for the whole window. Confirm with Zitadel what it stores after a successful check.

Before the window opens, confirm three things with your own team: how long the Firebase project, its API configuration and its user records remain available after cutover, who approves ending Firebase verification, and how the help desk will handle reset requests. Treat the 30 to 90 day figure as a starting range from the guide and adjust it to your user base. Write the window end date into the runbook, and test one account through each path in a staging environment. Extend the window if reset volume or failed verifications stay high near the planned end.

The choice comes down to whether users reset their passwords at first Zitadel login or keep their existing password, with Zitadel verifying it against Firebase at sign-in. Both paths start from the same constraint: Firebase uses a proprietary, modified scrypt algorithm with project-specific keys that Zitadel cannot process, so imported Firebase password hashes must be discarded. Zitadel's Firebase guide offers bulk import with password resets at first login, or just-in-time migration that checks credentials against Firebase's REST API, and suggests a migration window of about 30 to 90 days. Decide on three measures: how much friction users absorb, how much help desk load you accept, and how long Firebase must stay reachable and connected.

Bulk import with resets gives every account one predictable event. Users receive a reset request and set a new password at first login, so the help desk should expect a spike in the days after cutover. Test the reset email flow, the sender domain and spam filtering before any user is moved. Just-in-time migration keeps passwords unchanged, so most users notice nothing beyond a normal login. The cost shifts to failure handling. An account missing from Firebase, a password that fails, a lockout or a Firebase API error all appear as sign-in problems that support must triage. Ask the vendor guide how each case is reported and where the evidence lives, and have the support team work through those cases before the window opens.

The main operational difference is dependence on Firebase. A bulk import with resets can be cut over once the export is complete, subject to confirming the export and cutover steps in the vendor guide. Just-in-time migration keeps the Firebase project and its REST API in the sign-in path for every account that has not yet logged in. Firebase must stay available, the credentials used for those API calls must remain valid, and the connection cannot be removed until the window closes. The 30 to 90 day range in Zitadel's guide is a starting point to size against your own data. The right length depends on your user base and on how many accounts are dormant. Dormant accounts drive the decision, because users who never return keep the source connected indefinitely unless you plan a reset path for them. Confirm with the Firebase project owner which last sign-in data the project holds and how you can export it.

Many teams split the approach: they import active accounts with resets and leave dormant accounts on just-in-time migration or run a later reset campaign for them. Treat this as a design decision to confirm against the vendor guide, including whether both paths can run on the same Zitadel instance and how the sign-in logic handles each account. Get sign-off from the client's risk owners, who should decide how long the Firebase project, its API credentials and its configuration stay live, and who holds them. Record the window end date, the named owner of the Firebase project, the rule for retiring the connection, and the point at which unmigrated accounts are forced through a reset.

Most of what this migration needs from your team must be settled before DeployOpen can finalize scope, because the choice between bulk import with forced resets and just-in-time migration depends on facts only your team holds. Firebase password hashes cannot be carried into Zitadel, so the path you take depends on how many users you have, which applications sign in against Firebase, and whether you can accept a grace period in which both systems answer logins. Zitadel's Firebase guide suggests a migration window of about 30 to 90 days, and choosing the length of that window is one of the first decisions to make.

Start with access to the Firebase projects. The migration engineer needs an account with enough administrative rights to export users, read the Authentication configuration and confirm the web API key that client apps use for REST sign-in. Ask for a service account or a named administrator rather than a personal login, and confirm which projects are in scope, such as production and staging. Also list every sign-in provider enabled in each project. Google, Apple and SAML providers do not carry password hashes, so those users need separate federation planning and should not be counted with the password migration.

Next, provide an inventory of applications and their Firebase SDK usage. List each web, mobile, backend and serverless component that calls Firebase Authentication, with the SDK and version it uses, where it verifies ID tokens, and which claims or custom claims downstream services read. This inventory sets the repointing work and the token verification changes. Flag any mobile build that must pass app store review before it can change, because a late discovery of a client that cannot be updated quickly is a frequent cause of scope change.

Your team also needs to make two policy decisions and a hosting decision. Decide the password policy Zitadel will enforce for migrated users, including minimum length, complexity and whether every user must reset at first login or only those who have not signed in during the window. Name an owner for user communication, covering email notices, in-app messages, support scripts, legal review where needed and the date after which Firebase sign-in stops. On hosting, provide a Kubernetes cluster or Linux and Docker host for self-hosted Zitadel, with TLS, DNS, backups for PostgreSQL and an outbound network path to Firebase's REST endpoints during the grace period. Confirm that the PostgreSQL version you plan to use is within the supported range of 14 through 18.

Name owners for testing and cutover before the work starts. You need a testing lead who signs off test cases for sign-in, password reset, token issuance and application callbacks, a cutover lead who holds the go or no-go decision, an owner for each affected application and a security approver for changes to authentication. In return, DeployOpen reviews these inputs and provides a written scope that covers the recommended migration path, the application repointing tasks, a test plan, a draft cutover runbook and the effort that follows from these inputs. Engagements are fixed-scope, and the quote follows from that written scope. Ask for the scope to state which of these inputs it depends on, so any gap shows up before work begins.