Firebase is a serverless offering from Google which includes customer identity and access management (CIAM) as well as other typical functionality needed for an application. As such, it offers authentication and authorization, a database, metrics and more.
At FusionAuth, we talk to potential customers who are interested in migrating away from Firebase because of limitations, typically of standards or data control.
Summary - How to Migrate from Google Firebase
Key Takeaways
- Seamless migration path: FusionAuth supports Firebase’s modified scrypt hashing algorithm, enabling bulk migrations without forcing password resets, minimizing user disruption during the transition process.
- Deployment flexibility advantage: Unlike Firebase’s SaaS-only model, FusionAuth offers self-hosting options and deployment flexibility, giving teams complete control over data location and infrastructure architecture.
- Migration automation capabilities: FusionAuth provides pre-built import scripts and Connectors for both bulk and drip migrations, reducing development overhead and accelerating your transition timeline.
- Enhanced standards compliance: FusionAuth supports OAuth grants (including device grant) and authentication protocols that Firebase lacks, eliminating feature limitations that may have prompted your migration.
- Transparent operational control: With FusionAuth’s single-tenant architecture, you gain comprehensive logging, testing environments, and troubleshooting capabilities that Firebase’s shared infrastructure cannot match.
- Scalable growth foundation: FusionAuth eliminates Firebase’s usage limits and throttling concerns while providing transparent pricing that scales predictably with your business growth.
Definitions
- Bulk Migration: A complete user data transfer approach where all users are moved simultaneously from Firebase to the new authentication provider, typically involving system downtime but ensuring immediate data consistency and single source of truth.
- Drip Migration: A gradual user transition strategy where users are migrated individually during their next login attempt, allowing zero-downtime migrations while maintaining two systems temporarily until migration completion criteria are met.
- Modified Scrypt Algorithm: Firebase’s customized implementation of the scrypt password hashing algorithm that requires specific compatibility in the target authentication system—FusionAuth natively supports this format to prevent forced password resets during migration.
- Firebase Connectors: Integration mechanisms that enable slow migrations by allowing the new authentication system to validate credentials against Firebase during the transition period, with FusionAuth’s Connectors providing secure, configurable authentication passthrough capabilities.
- Authentication System of Record: The primary identity management platform that serves as the authoritative source for user credentials and profile data—successful migration requires clear designation and complete transition to prevent data inconsistencies and security gaps.
Frequently Asked Questions
Q: How easy is it to migrate from Firebase to FusionAuth?
A: FusionAuth provides comprehensive migration tooling for Firebase transitions. For Firebase specifically, FusionAuth offers pre-built import scripts, native support for Firebase’s modified scrypt algorithm, and detailed step-by-step documentation. The migration process typically takes 2-4 weeks depending on complexity, with options for both bulk and drip migration strategies. FusionAuth’s architecture eliminates common Firebase limitations like geographic restrictions and OAuth grant limitations that often drive migration decisions.
Q: How do I migrate users securely between authentication providers like Firebase and maintain password security?
A: Secure migration requires preserving existing password hashes to avoid forcing user password resets. FusionAuth natively supports Firebase’s modified scrypt hashing algorithm, allowing direct import of existing password data without security compromises. For additional security, implement IP restrictions, custom headers, or client certificates during drip migrations. FusionAuth’s single-tenant architecture ensures your user data never shares infrastructure with other customers, providing superior security isolation compared to Firebase’s shared model.
Q: How do I achieve seamless authentication in microservices architectures after migrating from Firebase?
A: FusionAuth excels in microservices environments through its API-first architecture and flexible deployment options. Unlike Firebase’s rigid SaaS model, you can deploy FusionAuth instances closer to your microservices, reducing latency and improving reliability. FusionAuth supports all standard OAuth2 and OpenID Connect flows, including the device grant that Firebase lacks, enabling consistent authentication across all service endpoints. The platform’s JWT token architecture integrates seamlessly with microservices authorization patterns.
Q: Can FusionAuth be deployed using Docker or Kubernetes for better control than Firebase’s serverless model?
A: Yes, FusionAuth offers complete deployment flexibility including Docker containers and Kubernetes orchestration, providing the infrastructure control that Firebase’s serverless model cannot match. You can deploy FusionAuth on-premises, in your preferred cloud environment, or across multiple regions for optimal performance and compliance. This deployment flexibility eliminates Firebase’s geographic restrictions while maintaining the scaling benefits through Kubernetes automation and load balancing capabilities.
Q: How does FusionAuth’s single-tenant architecture enhance security compared to Firebase’s shared infrastructure?
A: FusionAuth’s single-tenant architecture ensures your authentication data runs on dedicated infrastructure, eliminating the security risks inherent in Firebase’s multi-tenant model. This approach provides complete data isolation, enhanced logging and monitoring capabilities, and eliminates noisy neighbor effects that can impact performance. You gain full control over security configurations, compliance requirements, and data residency while maintaining the operational simplicity of a managed authentication solution through FusionAuth’s streamlined architecture.
This blog post will explain why and how you might choose to migrate from Firebase to another solution for user authentication and authorization. Other aspects of a migration, such as how to export your metrics data, will not be covered.
Weaknesses of Firebase
While Firebase is a low cost auth service and a far better choice than rolling your own auth solution, it has some downsides. These include:
- There is only one deployment model, a SaaS offering.
- You can run Firebase only in certain geographies.
- Some OAuth grants are not supported, such as the device grant.
- The usage limits may throttle you.
- Testing and testing environments can be difficult to set up.
- Logging and troubleshooting is difficult.
- There is limited validation of data.
- Authentication emails are not quite as customizable as you may link.
- Billing may be confusing and take some time to get used to.
These limitations may be acceptable initially, but eventually you may need a feature not provided by Firebase, such as a unique login provider or the OAuth device grant. Or perhaps you want more control over the location of your data, or a more typical testing and deployment setup.
For whatever reason, you may decide you need to move your customer and user data from Firebase. Let’s take a look at how you might do so.
When you shouldn’t migrate
Firebase has strengths as well as weaknesses, and if your application depends on unique features or the upsides outweigh the downsides, continue to run on Firebase.
For example, if the customization is acceptable and you are using lots of Firebase features, migration doesn’t make sense. The fact that Firebase is serverless makes it easy to “set and forget” and allows you to focus on other aspects of your application. You know, the features your users want.
If you need Firebase’s messaging, analytics or the Cloud Firestore NoSQL database and are not willing to look at alternatives, migration also won’t make sense. A standalone auth provider won’t provide the breadth of functionality, and you may not want to piece together replacements for everything Firebase offers.
How to migrate
If, however, you have decided to migrate from Firebase, the first decision you’ll need to make is: “With what will I replace the other Firebase functionality I depend on?”
One option is to leave parts of your application running on Firebase.
Another is to migrate it all to an environment where you have more control. What makes sense here depends on what other Firebase functionality you use.
Such guidance is beyond the scope of this article, though there is plenty of discussion on the internet. Here’s an article about moving from Firebase to AWS and here’s a GitHub issue thread discussing alternatives.
This blog post gives general guidance on migration off of Firebase to any other auth provider. If you are looking for step by step instructions on how to migrate from Firebase to FusionAuth, please review our Firebase migration guide.
One of the critical pieces of any application infrastructure is, of course, authentication and authorization. This post will therefore focus on how to move your users’ data. In this scenario, decide if you want to migrate your users in a bulk or drip migration.
Ready to move off Firebase? Let us show you how FusionAuth can make the transition smooth and secure.
Bulk migration from Firebase
The basic steps of a bulk migration are:
- Set up the new auth system. Make sure you map user functionality and data from Firebase to the new system. Ensure the new system supports the modified scrypt hashing algorithm used by Firebase.
- Export your user data from Firebase. You can do this with the Firebase CLI:
firebase auth:export users.json --format=JSON --project your_project_id. - Massage the exported user data into a format acceptable to your new provider, using whatever data transformation tools you are comfortable with.
- Upload the user data to the new provider.
- Create configuration in the new auth system corresponding to the applications previously set up in Firebase. You should also customize the user interface, messages, MFA methods and any other specific relevant settings.
- Update your custom, COTS or OSS applications to point to the new auth system.
- Disable the sign-in methods in your Firebase application to ensure that all of your users are authenticating against the new system.
Here’s the login flow before the bulk migration:
Bulk migration login request flow before the migration.
Here’s the login flow after the bulk migration, when Firebase no longer is involved in the login process:
Bulk migration login request flow after the migration.
The benefits of a bulk migration include:
- You can move all your users at one time. Having a single source of truth for customer data is typically beneficial.
- You can test the process repeatedly before going live.
- You no longer have a dependency on Firebase for authentication; the transition is quick.
The downsides of a bulk import are:
- You’ll have to build a script to retrieve the data from Firebase, modify it, and push it to the new system. Here’s an example of such a script for a FusionAuth import.
- There may be some downtime in the migration process where users cannot log in.
- If the new system can’t support the scrypt algorithm, you can still load the users, but you will have to reset their passwords. This can be disruptive to the user experience.
Since Firebase uses scrypt to rehash user passwords at login, if a user has been imported with a different hash and never logged in, the passwordHash field will be empty. In that case, set the user’s password to a random string and force them to reset their password.
A drip migration from Firebase
With a drip, or slow, migration, users log in to the new system, provide their username and password, which is then forwarded to Firebase. This connection must be secure and should be augmented with IP restrictions, custom headers or client certificates; you don’t want anyone to be able to submit credentials and probe your list of users. If the credentials are correct, the user is logged in and their data is migrated. The new system can rehash and store the password along with other user data.
Here’s a diagram of an initial user login during a slow migration:
Slow migration initial login request flow.
After the initial login, Firebase is no longer the system of record for that user. Any changes to this user, whether made by themselves, automated processes or customer service team members, will need to be made in the new system. In subsequent logins, Firebase is never consulted.
Slow migration subsequent login request flow.
The basic steps of a slow migration are:
- Set up the new auth system. Make sure you map all user functionality and data from Firebase to the new system.
- Determine what constitutes “done” for this migration, since it is unlikely that every single user will log in and be migrated, no matter how long you run these two systems in parallel. You can see more details on how to calculate that.
- Set up a way for the new system to present user credentials to Firebase during an authentication event. The exact method will depend on new system features, with FusionAuth you use Connectors. On the Firebase side, it can be done with an API call; see this Firebase documentation for more.
- Create configuration in the new auth system corresponding to the applications previously set up in Firebase. You should also customize the user interface, messages, MFA methods and any other settings that are relevant.
- Update your custom, COTS or OSS applications to point to the new auth system.
- Wait for your users to log in and be migrated, running reports periodically to determine if you’ve migrated enough users to shut down the slow migration.
- Decide what to do with unmigrated users. Options include abandoning them, a bulk migration, or contacting them to encourage them to log in.
- Disable the sign-in methods in your Firebase application to ensure that all of your users are authenticating against the new system.
Slow migrations have less impact on your users, but more impact on your systems and employees and take more time.
For instance, if a customer service representative needs to reset a password, they will have to determine if the user has been migrated to the new system or not before they can process the request.
Conclusion
This overview of a Firebase migration covers considerations for migrating user data. No matter what the new target system is, you’ll need to decide between a bulk or slow migration, as well take specific steps to move your data and settings. You’ll also want to consider if and how to migrate any other functionality you use in Firebase.
If you are looking for step by step instructions on how to move user data to FusionAuth from Firebase, please check out our Firebase migration guide.
