Map collections to keys
For every Firestore collection and subcollection, write the key its documents will live under and which queries become search indexes. Flag listener-driven features — they decide what can move at all.
Declare the backend in stack.json
Tables for the flattened collections, buckets for Cloud Storage, nodejs workers for Cloud Functions, and gateway routes for the API surface the app will call. Review the kernstack plan before building the release.
Export Firestore and Storage
Use Firestore export into a storage bucket, transform documents into keyed records with a script you keep, and load. Copy Cloud Storage objects into buckets and verify counts and samples.
Ship the cutover release
Release app versions that call the KERNSTACK gateway, with the account reset or re-login flow included. Run both backends until old-version traffic ends, then close the Firebase project.
Documents become records with addresses
Firestore data is documents in collections and subcollections, shaped by the queries the SDK makes easy. KERNSTACK tables want the opposite commitment: every record under an explicit key. The migration work is therefore a flattening exercise. A document path like users/{uid}/orders/{oid} usually becomes an orders table keyed by user and order id; fields the app filters on become either part of the key design or a declared text search index over the table.
Cloud Storage files are simpler: objects copy into buckets over HTTPS, and download URLs give way to presigned upload and access patterns issued by your workers. Cloud Functions are most often Node.js, and Node becomes container workers with the nodejs runtime — functions on KERNSTACK are Go WebAssembly, a distinction this guide will keep repeating because it decides where your code lands.
- Firestore security rules do not translate. Access checks move into the functions and workers that serve the data.
- Realtime Database and Firestore listeners have no direct equivalent. Features built on live listeners need a redesigned update path or stay on Firebase.
- FCM push notifications have no KERNSTACK equivalent. Keeping Firebase for push only, beside a migrated backend, is a legitimate end state.
The app release is the critical path
Server-side pieces can migrate any time; the client cannot. A shipped mobile or web app talks to Firebase through its SDK, so the cutover rides a release: the new version calls gateway routes on KERNSTACK, the old version keeps calling Firebase, and both backends run until store adoption drains the old one. Plan the migration calendar around your release cadence and app review times, not around the data export.
Accounts deserve their own plan inside that calendar. User records export, password hashes do not, so existing users meet a password reset or re-login on the new backend. Communicated early and bundled into the release notes, this is a minor event; discovered at cutover, it is the incident everyone remembers.
Resource-by-Resource Mapping from Firebase
- Firestore collections →
tables: Documents flatten into keyed records; subcollection paths usually become composite keys. Export is JSON; the transform script is yours to keep and re-run. - Firestore queries and filters →
key design + search indexes: Equality filters on known fields become keys; text search becomes a declared text index over the table. Range-scan habits need redesign, stated plainly. - Cloud Functions (Node.js) →
workers (nodejs): Callable and HTTP functions become worker endpoints behind gateway routes. Only Go code would map to KERNSTACK functions, and Firebase code rarely is Go. - Cloud Storage →
buckets: Objects copy over HTTPS. Client uploads switch from SDK resumable uploads to presigned URLs issued by your workers. - Firebase Hosting →
gateway prefix route: The built web app serves from the project; add cdn_enabled where cached delivery matters. Rewrites become route configuration. - Firebase Authentication →
gateway sign-in flow: User records and providers are re-declared; password hashes do not export. Budget a reset or re-login flow into the cutover release. - Security Rules →
checks in functions and workers: Rules become code in the handlers that read and write the tables — reviewed in diffs instead of edited in a console. - FCM and realtime listeners →
no direct equivalent: Push and live database listeners stay on Firebase or get redesigned. Many teams keep a slim Firebase project for push after the backend has moved.
Frequently asked questions
No — and any guide promising that is hiding the SDK. Data and server logic can move first, but the client reaches Firebase through Firebase libraries, so the visible cutover is an app release. What you can do is make that release boring: backend ready, rehearsed, and running in parallel beforehand.
Their records move; their passwords cannot. Firebase does not export password hashes, so users set a new password or re-login with a social provider on the new backend. Handle it as a communicated product change inside the cutover release, and it passes without drama.
Heavy reliance on realtime listeners, FCM-driven engagement, or Remote Config and A/B tooling. Those have no KERNSTACK equivalent today. Products using Firebase mainly as data plus functions plus hosting — the common case — migrate cleanly; products built on its live-sync magic should keep it.
Related capabilities, architectures, and comparisons
Ship your stack on the Software Lifecycle Cloud.
Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.