Scale-out & Migration

Move the workloads that outgrew Firebase. Keep the rest.

Firebase is an excellent place for most of an app and a poor place for some of it. The mature move is rarely "all in" or "all out" — it is knowing which workloads have outgrown Firebase primitives and moving exactly those, with the discipline to prove nothing broke.

Hybrid scale-out

The common pattern: the app stays on Firebase Auth, Firestore, and Hosting, while a specific hot path moves to purpose-built infrastructure.

  • Cloud Run for request paths that need concurrency, long execution, WebSockets, or a runtime Functions can't offer — still inside the GCP project, still speaking to Firestore and Auth.
  • Cloud SQL for relational workloads that fight Firestore: reporting queries, multi-entity transactions, anything your team keeps writing client-side joins for.
  • BigQuery for analytics — usually via the Firestore-to-BigQuery extension or a change-data stream — so analysts stop running aggregation queries against the production database at production prices.

We design the seams: how the moved workload authenticates Firebase users, how data flows between stores, and what stays consistent versus eventually consistent.

Full migration off Firebase

Sometimes the right answer is leaving — an acquisition mandates a different cloud, compliance demands capabilities Firebase doesn't offer, or the economics stopped working. We plan and execute these as incremental cutovers, never big-bang rewrites:

  1. Inventory and dependency map — every Firebase service in use, every client SDK call site, every security rule encoding business logic that must be reimplemented server-side.
  2. Strangler cutover — workload by workload, with dual-writes or change streams keeping old and new stores in sync during the transition.
  3. Parallel-run verification — reconciliation checks that prove the new path produces the same answers before any traffic commits to it.
  4. Auth migration last — user migration (password hashes export, token compatibility windows) is the highest-risk step and gets the most rehearsal.

What to expect

Migration work is billed hourly by senior US engineers; scope and sequencing are agreed up front and revisited at each cutover milestone. If an assessment concludes you should stay on Firebase and fix the model instead, we will say exactly that — it is the cheaper finding, and it is often the correct one.

We will tell you which workloads should move, which should stay — and if the answer is "fix the model and stay", you will hear that too.
Outgrowing part of your stack?