Migrating From Firebase Auth to Clerk, Step by Step

Migrations fail on things nobody wrote down. Before exporting anything, list:

• Every sign-in method in use: email and password, each social provider, phone, anonymous, and custom tokens minted by your own server.
• Every custom claim you set (roles, plan, organization IDs) and every service that reads them.
• Every place the UID appears as a foreign key in your own database, in Firestore rules, in storage paths or in third-party tools.
• Every backend that verifies Firebase ID tokens, including workers, webhooks and mobile apps that are slower to update.
• Email templates and action links for verification and password reset.

The UID list matters most. Plan to keep the old UID as an external identifier on the new user record so existing foreign keys keep working while you migrate.

Export users with the Firebase CLI or Admin SDK, which gives you emails, verification state, provider links, metadata and, for password users, a hash and salt. Firebase's password hashing uses a modified scrypt with project-specific parameters, so importing hashes only works if the target accepts that algorithm and you supply the parameters. Check Clerk's current import documentation before you assume it does.

If hashes can't be imported, you have two fallbacks. You can email password-reset links to every password user, which is simple but produces churn. Or you can migrate lazily: on login, verify the password against Firebase, then create or update the user in Clerk with the password the person just typed. Lazy migration keeps people signed in smoothly, but it means running the Firebase check longer, and inactive users never migrate. Social-login users are easier, since they re-authenticate with the same provider and match by email.

The safest path is dual verification, where your backend accepts either a Firebase ID token or a Clerk session token during the window. A sequence that works:

1. Add a token verification layer that inspects the issuer and routes to the right verifier, returning the same internal user object either way.
2. Backfill the mapping table from Firebase UID to Clerk user ID before any client changes ship.
3. Move claims into the new system: roles and plan fields become organization roles or public metadata, and your authorization code reads them through one helper.
4. Ship the new sign-in UI to a small share of traffic or an internal group first, and watch error rates on login and token verification.
5. Roll out to web, then mobile, keeping the Firebase path live for app versions that haven't updated.

Keep webhooks in mind. If you sync users to your own database when they sign up, point that at Clerk's events and make the handler idempotent, so a user created by import and by webhook doesn't duplicate.

The failures that hurt are predictable:

• Case and whitespace differences in email addresses causing duplicate or orphaned users during import.
• OAuth redirect URIs registered only for the old provider, so social sign-in breaks on cutover day.
• Security rules or row-level policies that reference the Firebase UID claim and silently deny access to migrated users.
• Sessions: users signed in on Firebase have no Clerk session yet, so decide whether the first visit shows a quiet re-login.
• Deleting the Firebase project too early. Keep it read-only for at least one full billing cycle.

Write the rollback before the cutover. The minimum: a feature flag that flips clients back to the Firebase sign-in, a backend that still accepts Firebase tokens, and a rule that no user data is deleted from Firebase until you've run cleanly for a set period.

One catch is password changes made during the window. If someone resets a password in Clerk and you then roll back, Firebase has the old one. Freeze password changes during the cutover window or tell affected users. For your related authentication decisions, see multi-tenant authentication architecture and the Clerk vs Auth0 comparison for B2B SaaS.