---
title: "How Much Does It Cost to Migrate From Firebase to Custom Code?"
author: "Nate Laquis"
author_role: "Founder & CEO"
date: "2028-07-06"
category: "Cost & Planning"
tags:
  - migrate from Firebase cost
  - Firebase alternatives
  - Firebase to custom backend
  - cloud migration planning
  - Firebase vendor lock-in
excerpt: "Firebase gets you to market fast, but the bills and limitations compound just as quickly. Here is what it actually costs to migrate from Firebase to a custom stack, and how to decide if the move is worth it."
reading_time: "13 min read"
canonical_url: "https://kanopylabs.com/blog/how-much-does-it-cost-to-migrate-from-firebase"
---

# How Much Does It Cost to Migrate From Firebase to Custom Code?

## Why Teams Outgrow Firebase

Firebase is a phenomenal prototyping tool. You can stand up authentication, a real-time database, file storage, and serverless functions in a single afternoon without writing a line of backend code. For hackathons, MVPs, and apps with fewer than a thousand users, nothing else comes close to that velocity. The problem is that Firebase was designed to remove complexity, not to scale with it.

The first cracks usually appear in the Firestore bill. Firestore charges per document read, write, and delete. That pricing model is invisible at low volume, but it becomes painful fast. A dashboard that loads a list of 200 items, lets the user filter and sort, and then loads details on click can easily generate 500 to 1,000 reads per session. At $0.06 per 100,000 reads, a single user running 20 sessions a day costs almost nothing. But scale that to 10,000 daily active users and you are looking at $3,000 to $6,000 per month in read charges alone, before you account for writes, deletes, storage, or bandwidth.

![analytics dashboard showing usage metrics and cloud cost data for a growing application](https://images.unsplash.com/photo-1551288049-bebda4e38f71?w=800&q=80)

The second issue is query limitations. Firestore does not support full-text search, aggregation queries across subcollections, or joins of any kind. You end up denormalizing data aggressively, which means maintaining multiple copies of the same data through Cloud Functions triggers. That pattern works until it does not. When a trigger fails silently or retries cause duplicate writes, you have data consistency problems that are brutally hard to debug in a system with no SQL shell and no transaction log you can inspect.

Then there is vendor lock-in. Firebase Authentication, Firestore, Cloud Functions, Firebase Storage, Firebase Hosting, Remote Config, and Analytics are all proprietary Google services with proprietary APIs and proprietary data formats. There is no standard protocol, no portable query language, and no way to run the stack locally for development (the Firebase emulator suite is close but not identical to production). Every feature you build on Firebase ties you deeper to Google's ecosystem, and the switching cost grows with every line of code.

The final trigger is often technical. You need a relational data model for a feature that Firestore cannot express. You need a background job that runs longer than Cloud Functions' 9-minute timeout. You need WebSocket connections that stay open for hours, not seconds. You need to run a machine learning model on your own infrastructure. At that point, you are fighting the platform instead of building your product, and it is time to evaluate a move.

## What You Are Actually Replacing

Firebase is not a single service. It is a bundle of eight to twelve services depending on how deeply you have integrated. Before you can estimate migration cost, you need to map every Firebase service you use to its replacement. Here is the full inventory, because most teams undercount.

**Firebase Authentication to a custom auth system or Auth0/Clerk.** Firebase Auth handles email/password login, OAuth providers (Google, Apple, GitHub), phone number verification, anonymous auth, and session management. If you are migrating to a custom backend, you have two options: implement auth yourself with a library like Passport.js, NextAuth, or Lucia, or adopt a managed auth provider like Auth0, Clerk, or Supabase Auth. Rolling your own saves monthly fees but takes 2 to 4 weeks of careful engineering. Password hashing, token rotation, rate limiting, and account recovery flows all need to be airtight. A managed provider costs $25 to $500/month depending on user count but takes days instead of weeks to integrate.

**Firestore to PostgreSQL, MySQL, or MongoDB.** This is the core of the migration and the biggest source of engineering work. Firestore's document model needs to be translated into a relational schema (if moving to Postgres/MySQL) or restructured for a different document database (MongoDB). The schema design phase alone takes 1 to 2 weeks for a non-trivial application because you are undoing all the denormalization that Firestore required. Every collection, subcollection, and document reference needs a corresponding table, column, or relation in the new database. For teams that want a faster path, [Supabase is the closest drop-in replacement](/blog/supabase-vs-firebase) for Firebase with a Postgres backend, real-time subscriptions, and a similar developer experience.

**Cloud Functions to a Node.js/Python API server or serverless platform.** Firebase Cloud Functions are Google Cloud Functions with Firebase-specific triggers (Firestore document changes, Auth events, Storage uploads). On a custom stack, you replace these with API endpoints on your backend server and event-driven workers. Background triggers that respond to database changes become database triggers, message queue consumers (using Redis, RabbitMQ, or SQS), or application-level hooks. HTTP-triggered functions map directly to Express/Fastify/Django routes.

**Firebase Storage to S3, Cloudflare R2, or a similar object store.** Firebase Storage is a wrapper around Google Cloud Storage with Firebase-specific security rules. Migrating files is straightforward: download everything from Firebase Storage, upload to S3 or R2, and update your application to use the new URLs. The complication is Firebase Storage security rules, which need to be reimplemented as middleware or presigned URL logic on your backend.

**Firebase Hosting to Vercel, Netlify, or a custom CDN.** If you are hosting a static site or SPA on Firebase Hosting, the migration is trivial. Push to Vercel or Netlify, point your domain, and you are done. If you are using Firebase Hosting with Cloud Functions for SSR, you need to migrate the SSR logic to your new platform's serverless functions or a dedicated server.

**Realtime Database and Firestore listeners to WebSockets or SSE.** If your application relies on Firestore's real-time snapshot listeners for live updates, you need a replacement. Options include a WebSocket server (using Socket.io or the ws library), Server-Sent Events, or a managed real-time service like Supabase Realtime, Ably, or Pusher. This is often the most underestimated migration task because real-time sync is deeply embedded in client-side code.

**Firebase Analytics and Crashlytics to PostHog, Mixpanel, or Sentry.** These are usually the easiest to migrate because they are client-side SDKs with no data dependencies. Swap the SDK, update your event tracking calls, and you are done. Historical data stays in Firebase's console but does not affect the new system.

## Migration Cost by Complexity Tier

We have migrated enough Firebase applications to know that costs cluster into three tiers based on how deeply the app uses Firebase's proprietary features. These estimates cover engineering labor, infrastructure setup, data migration, testing, and a two-week stabilization period. They do not include ongoing monthly hosting costs.

### Tier 1: Simple App ($10,000 to $25,000)

A simple Firebase app uses Authentication, Firestore with fewer than 15 collections, and maybe Cloud Functions for a handful of HTTP endpoints or email triggers. The frontend is a React or Vue SPA hosted on Firebase Hosting. There are no real-time listeners, no complex security rules, and the Firestore database is under 5 GB. Think a B2B SaaS dashboard, an internal tool, or an early-stage consumer app.

At this tier, a single senior full-stack engineer can handle the migration in 3 to 5 weeks. The work includes designing a Postgres schema from the Firestore collections, building a Node.js or Python API to replace Cloud Functions, integrating a managed auth provider (Clerk or Supabase Auth), writing a data migration script to transform Firestore documents into relational rows, deploying to Vercel or Railway, and setting up a CI/CD pipeline. Most of the cost is engineering labor at $150 to $200/hour.

### Tier 2: Medium Complexity ($25,000 to $60,000)

Medium complexity means 20 to 50 Firestore collections with subcollections, multiple Cloud Functions triggers (Firestore onCreate, onUpdate, onDelete), real-time listeners on the client, Firebase Storage with user-uploaded files, and custom security rules that encode business logic. The database is 5 to 50 GB and the app serves 5,000 to 50,000 monthly active users. Staging and production environments both need to be migrated.

This tier takes 6 to 10 weeks with a team of two: a backend engineer and a frontend engineer who can refactor the client-side Firebase SDK calls. The additional complexity comes from replicating Firestore's real-time behavior with WebSockets or SSE, converting denormalized document structures into a normalized relational schema without losing data, rebuilding Cloud Functions trigger logic as event-driven workers, migrating files from Firebase Storage to S3 with URL rewriting, and reimplementing security rules as backend middleware. Data migration at this scale also requires more careful planning. You cannot just dump and restore. You need incremental migration scripts with validation checks.

### Tier 3: Complex App ($60,000 to $150,000)

Complex Firebase apps are the ones that went all-in on the ecosystem. They use Firestore with 50+ collections and deeply nested subcollections, hundreds of Cloud Functions, Firebase Extensions (like Stripe payments or Algolia search sync), the Realtime Database alongside Firestore, Firebase ML, Remote Config, Dynamic Links, and App Check. The database exceeds 50 GB, the app serves 100,000+ monthly active users, and downtime during migration has a direct revenue impact.

This tier takes 12 to 20 weeks with a team of three to four engineers. Beyond the technical migration, you are rebuilding significant portions of the application architecture. Cloud Functions that relied on Firebase-specific triggers need to be redesigned as a proper event-driven system with message queues and dead-letter handling. Firebase Extensions need custom replacements. Real-time sync patterns need to be re-architected from scratch. The data migration alone can take 3 to 4 weeks because of the volume, the complexity of the document-to-relational transformation, and the need for zero-downtime cutover using change data capture.

## Monthly Costs After Migration: Firebase vs. Custom Stack

The migration is a one-time investment. Whether it pays off depends on your monthly cost savings and how long you plan to run the product. Here are real comparisons for three application profiles.

**Small app (1,000 MAU, light read/write volume):**

- Firebase (Blaze plan): $50 to $150/month (Firestore reads, Cloud Functions invocations, Auth, bandwidth)

- Custom stack (Railway or Render): $30 to $70/month (app hosting $7 to $25, Postgres $7 to $15, Redis $0 to $10, auth provider free tier)

- Monthly savings: $20 to $80

At this scale, the migration does not make financial sense. You would need 10+ years to recoup even a Tier 1 migration cost. The reasons to migrate at this size are technical, not financial.

**Medium app (20,000 MAU, moderate Firestore usage):**

- Firebase: $800 to $2,500/month (Firestore reads scale non-linearly as features grow, Cloud Functions at scale, Firebase Storage bandwidth, paid auth tier)

- Custom stack (AWS or Railway): $200 to $500/month (ECS or Railway pro $50 to $150, RDS or managed Postgres $50 to $100, S3 $10 to $30, auth provider $50 to $100, monitoring $30 to $50)

- Monthly savings: $500 to $2,000

This is the sweet spot for migration ROI. At $1,000/month in savings, a $40,000 Tier 2 migration pays for itself in 3 to 4 years. But the real value is not just cost savings. It is the removal of Firestore query limitations, the ability to use SQL for reporting, and the flexibility to add features that Firebase's data model could not support.

![dashboard showing cost analytics and savings projections for cloud infrastructure migration](https://images.unsplash.com/photo-1460925895917-afdab827c52f?w=800&q=80)

**Large app (100,000+ MAU, heavy Firestore and Cloud Functions usage):**

- Firebase: $5,000 to $15,000/month (Firestore per-operation pricing compounds at scale, Cloud Functions compute, egress bandwidth, Firebase Storage, premium support)

- Custom stack (AWS): $1,000 to $3,000/month (ECS Fargate cluster $300 to $800, RDS r6g.large Multi-AZ $250 to $400, ElastiCache $100 to $200, ALB + CloudFront $80 to $150, S3 $50 to $100, monitoring and logging $100 to $200)

- Monthly savings: $4,000 to $12,000

At this scale, the migration pays for itself in 6 to 12 months even at the Tier 3 price point. The math is unambiguous. If your Firebase bill exceeds $5,000/month and is growing, the question is not whether to migrate but how fast you can execute it. For more context on planning a move between cloud providers, [our cloud migration guide](/blog/how-to-migrate-cloud-providers) walks through the general process and risk management strategies.

## The Firestore Data Migration Problem

Data migration is the hardest part of leaving Firebase, and it deserves its own section because teams consistently underestimate it. Moving data from Firestore to a relational database is not a straightforward export and import. It is a data model transformation that requires deep understanding of both your current document structure and your target schema.

**Exporting from Firestore is clunky.** Firestore does not have a pg_dump equivalent. Your options are the Firebase CLI export (which produces a binary format only importable back into Firestore), the Google Cloud Console managed export (same binary format, stored in a Cloud Storage bucket), or writing a custom export script that reads every document in every collection and subcollection and writes it to JSON or CSV. For most migrations, you end up writing the custom script because you need to transform the data during export anyway.

**Document-to-relational transformation is non-trivial.** Firestore encourages patterns that are hostile to relational databases. A Firestore document might contain nested maps, arrays of objects, references to other documents (stored as string paths), and denormalized copies of data from other collections. Translating this to a normalized Postgres schema means creating junction tables for many-to-many relationships that were stored as arrays, extracting nested maps into separate tables, resolving document references into foreign keys, and deduplicating data that was intentionally copied across collections for query performance.

Here is a concrete example. In Firestore, you might have a "users" collection where each user document contains an "orders" subcollection, and each order document contains an embedded "items" array with product name, price, and quantity. In Postgres, that becomes four tables: users, orders, order_items, and products, with foreign keys linking them. The transformation script needs to extract products from the embedded objects, deduplicate them, assign IDs, and create the order_items join records. For a database with 100,000 user documents, each with an average of 15 orders, you are processing 1.5 million order documents and potentially 10 million embedded items.

**Incremental migration for zero downtime.** If your app cannot afford extended downtime, you need to run the old Firebase app and the new custom app in parallel during the transition. This means setting up a change data capture pipeline: a Cloud Function that listens to Firestore writes and replicates them to your new Postgres database in near-real-time. This is technically challenging because you need to handle ordering, deduplication, and conflict resolution. The alternative is a scheduled cutover with a short maintenance window (1 to 4 hours), which is simpler but requires coordinating with your users.

**Validating data integrity post-migration.** After the migration, you need to verify that every document in Firestore has a corresponding row (or rows) in Postgres, that all field values match, and that relationships are intact. This means writing validation scripts that compare document counts, spot-check random records, and verify aggregate values (sum of all order totals, count of users by status, etc.). Budget 2 to 3 days just for validation on a medium-complexity migration. Skipping this step is how you end up with phantom data bugs that surface weeks later when a customer reports that their order history is missing three entries.

## When You Should Not Migrate

Not every Firebase app should be migrated. In some cases, the cost and risk of migration outweigh the benefits, and the smarter move is to optimize what you have or wait for a natural inflection point.

**Your bill is under $500/month and not growing fast.** If Firebase costs you $200/month and your user growth is modest, the migration math does not work. A Tier 1 migration at $15,000 would take over 6 years to pay back in cost savings. Your engineering time is better spent building features that drive revenue, not reimplementing infrastructure you already have.

**Your team has no backend experience.** Firebase's value proposition is that frontend developers can build full-stack apps without backend expertise. If your team is entirely frontend engineers, migrating to a custom backend means either hiring a backend developer ($120,000 to $180,000/year salary) or outsourcing the migration and ongoing maintenance. Factor in the ongoing operational cost, not just the migration cost. A custom backend needs someone to manage deployments, monitor uptime, apply security patches, and handle database maintenance.

**You are pre-product-market-fit.** If you are still iterating on your core product, Firebase's speed advantage matters more than its cost disadvantage. Migrating before you have validated your market is premature optimization. Build on Firebase, find your customers, prove the business model, and migrate when the cost or technical limitations actually constrain your growth.

![developer working on laptop evaluating code and making strategic technology decisions](https://images.unsplash.com/photo-1517694712202-14dd9538aa97?w=800&q=80)

**You only need to fix one or two pain points.** Sometimes the problem is not Firebase itself but a specific limitation. If Firestore queries are too slow, adding Algolia or Typesense for search might solve the issue without a full migration. If Cloud Functions are too slow to cold-start, switching to Cloud Run (still in the Google ecosystem but with more control) can help. If your Firestore bill is high because of excessive reads, restructuring your data model and queries can cut costs by 50 to 80% without leaving the platform. Exhaust the optimization options before committing to a migration.

**The hybrid approach.** You do not have to migrate everything at once. Some teams start by moving their heaviest workload off Firebase (usually the database) while keeping Firebase Auth and Hosting in place. You can point your frontend at a new custom API that reads from Postgres while keeping Firebase Auth for user management. This reduces risk, spreads the cost over months, and lets you validate the custom stack before committing fully. It is a pragmatic middle ground that works well for teams with limited engineering bandwidth.

## How to Decide and What to Do Next

Here is the framework we use when advising teams on whether to migrate from Firebase. It comes down to three questions.

**First, is Firebase limiting your product?** If you are building workarounds for Firestore's query limitations, hitting Cloud Functions timeouts, or struggling with data consistency across denormalized collections, the technical debt is compounding. Every workaround you build is code that will need to be rewritten anyway. The sooner you migrate, the less throwaway code you write.

**Second, is Firebase costing you more than the alternative?** Pull your Firebase billing dashboard and project your costs at 2x and 5x your current user base. Firestore's per-operation pricing means costs scale linearly (or worse) with usage. A custom stack on Postgres with fixed-price compute scales much more predictably. If your projected Firebase bill at 5x users makes you uncomfortable, start planning now. Migrations take 2 to 5 months, and you do not want to be executing one under financial pressure.

**Third, does your team have the capacity?** A migration is a 2 to 5 month project that pulls engineers away from feature work. If you are a two-person startup shipping features every week, you probably cannot afford to stop for three months. If you have a team of six and can dedicate two engineers to infrastructure, the migration is manageable alongside feature development. For teams that need to migrate but cannot afford to stop shipping, [outsourcing the migration to a specialized team](/blog/how-much-does-it-cost-to-migrate-from-heroku-to-aws) is often the most cost-effective option.

If you answered yes to at least two of those questions, the migration is worth pursuing. The next step is a concrete scoping exercise: inventory every Firebase service you use, estimate the complexity tier, choose your target stack, and build a phased timeline.

We run these assessments for teams every week. We will look at your Firebase console, review your codebase, estimate the migration cost within a $5,000 range, and recommend a target architecture. The call is free, takes 30 minutes, and you will leave with a clear plan whether or not you work with us. [Book a free strategy call](/get-started) and let's figure out the right path forward for your product.

---

*Originally published on [Kanopy Labs](https://kanopylabs.com/blog/how-much-does-it-cost-to-migrate-from-firebase)*