Migrate a FlutterFlow database by exporting data from the source (Firestore Console export or pg_dump for Supabase), transforming the format to match the destination schema using a Cloud Function or script, and importing to the new database. For Firestore-to-Supabase: export Firestore to JSON, transform NoSQL document structure to relational table rows, import via Supabase SQL. Always back up first, migrate test data first, validate document/row counts, then migrate production during a maintenance window.
Plan and execute a FlutterFlow database migration safely
Database migrations are high-risk operations — a mistake during migration can cause data loss or app downtime. The safest approach is: export, transform, validate on test data, then execute on production with a maintenance window. The most common migration in the FlutterFlow ecosystem is Firestore to Supabase (often driven by the need for relational queries or lower costs at scale) and between two Firestore projects (renaming a project, separating dev from prod, or transferring to a client). Both follow the same pattern: export source data, transform the schema, import to destination, validate counts and spot-check records, then update FlutterFlow to point at the new database.
Prerequisites
- Admin access to both the source and destination database
- A backup of the source database completed and verified before starting
- Enough time to perform a test migration before the production migration — never migrate production without a successful test run
- Your FlutterFlow project's Firebase or Supabase credentials for both the old and new projects
Step-by-step guide
Export your Firestore data to JSON
Export your Firestore data to JSON
Option A (Firebase Console): In Firebase Console → Firestore Database → Import/Export → Export → select your Cloud Storage bucket and optionally limit to specific collection IDs. The export creates binary Firestore files — not directly readable as JSON. To convert to JSON, use the node-firestore-import-export npm package: npx node-firestore-import-export export -a serviceAccount.json -b backups/export.json. This creates a readable JSON file with your full collection structure. Option B (Custom Cloud Function): write a script that uses firebase-admin to iterate over every collection and document, building a JSON object, then writes it to Cloud Storage. This is more controllable for large datasets. For collections over 10,000 documents, add pagination (startAfterDocument) to avoid memory limits. Store the export JSON in Cloud Storage before downloading.
Expected result: A JSON file in Cloud Storage or locally containing your complete Firestore data structure, ready for transformation.
Transform Firestore JSON to Supabase SQL format
Transform Firestore JSON to Supabase SQL format
Firestore is a document database; Supabase is PostgreSQL. The transformation maps Firestore collections to SQL tables, document fields to column values, and DocumentReferences to foreign key IDs. Write a Node.js transformation script. For each Firestore collection (e.g., users), create a corresponding SQL INSERT statement: users collection → users table with columns id (doc ID), name, email, createdAt (converted from Firestore Timestamp to ISO string). For DocumentReferences: a Firestore order document with userId: DocumentReference('/users/abc123') becomes userId: 'abc123' (just the ID string, matched to the users.id foreign key in the users table). For arrays: Firestore arrays of primitives become PostgreSQL array columns or a join table for arrays of objects. Nested maps become JSONB columns if the structure varies, or flattened to individual columns if the structure is consistent.
Expected result: A .sql file or a series of INSERT statements ready to run against a fresh Supabase database.
Create the destination schema and import data
Create the destination schema and import data
In Supabase, go to Table Editor → New Table, or use the SQL Editor to run CREATE TABLE statements matching your transformed schema. Enable Row Level Security on all tables from the start: ALTER TABLE users ENABLE ROW LEVEL SECURITY; Add RLS policies before importing data. Once the schema is ready, import via the Supabase SQL Editor: paste and run your INSERT statements in batches (Supabase SQL Editor has a 100MB input limit). For large imports, use the Supabase CLI: psql command-line from a local terminal (if your team has CLI access) or a Cloud Function that runs the INSERT statements via the Supabase JavaScript client. After import: run SELECT COUNT(*) FROM users and compare to the Firestore document count from your export file. Check 5-10 random records by ID to verify field values are correct.
Expected result: All data from Firestore is now in Supabase with matching record counts and spot-checked field values.
Migrate between two Firestore projects
Migrate between two Firestore projects
For Firestore-to-Firestore migration (different Firebase projects): use the Firebase Export → Import feature. Export from the source project: Firebase Console → Firestore → Import/Export → Export to Cloud Storage bucket gs://source-project/export. In the destination project: Firestore → Import/Export → Import → specify the source bucket path (you need to grant the destination project's service account read access to the source bucket first). This is the cleanest path for full Firestore-to-Firestore migrations. For partial migrations (copying specific collections, not all): use the node-firestore-import-export tool with collection filtering, or write a Cloud Function that reads from the source using the Admin SDK and writes to the destination using a second Admin SDK instance initialized with the destination project's credentials.
Expected result: The destination Firestore project contains an identical copy of the source data, validated by collection and document counts.
Update FlutterFlow to connect to the new database
Update FlutterFlow to connect to the new database
After validating the destination data, update FlutterFlow's database connection. For Supabase: go to Settings → Integrations → Supabase → update the Project URL and Anon Key to the new Supabase project values. For Firebase: go to Settings → Firebase → remove the current project and reconnect to the new Firebase project with its google-services.json and GoogleService-Info.plist. After updating the connection, rebuild and test all Backend Queries in the FlutterFlow editor — verify that list pages load data correctly from the new database and that create/update/delete operations work. Run the app in Test Mode against a test user account to verify the full data flow before releasing to production users.
Expected result: FlutterFlow is connected to the new database, all pages display correct data, and all write operations persist correctly in the destination.
Complete working example
1// Transform script: Firestore JSON export → Supabase INSERT SQL2// Run locally: node firestore_to_supabase_transform.js3const fs = require('fs');45const firestoreExport = JSON.parse(6 fs.readFileSync('./firestore_export.json', 'utf8')7);89function tsToISO(ts) {10 if (!ts || !ts._seconds) return null;11 return new Date(ts._seconds * 1000).toISOString();12}1314function transformUsers(usersCollection) {15 const inserts = [];16 for (const [docId, doc] of Object.entries(usersCollection)) {17 const row = {18 id: docId,19 email: doc.email || null,20 name: doc.name || null,21 plan: doc.plan || 'free',22 created_at: tsToISO(doc.createdAt),23 };24 inserts.push(25 `INSERT INTO users (id, email, name, plan, created_at) VALUES ` +26 `('${row.id}', ${row.email ? `'${row.email.replace(/'/g, "''")}'` : 'NULL'}, ` +27 `${row.name ? `'${row.name.replace(/'/g, "''")}'` : 'NULL'}, ` +28 `'${row.plan}', ${row.created_at ? `'${row.created_at}'` : 'NULL'});`29 );30 }31 return inserts;32}3334const users = firestoreExport.__collections__?.users || {};35const sql = transformUsers(users);3637fs.writeFileSync('./supabase_import.sql',38 '-- Users migration\n' + sql.join('\n') + '\n'39);40console.log(`Generated ${sql.length} INSERT statements`);Common mistakes when migrating Your FlutterFlow Database to a New Database
Why it's a problem: Migrating production data without a successful test migration first
How to avoid: Create a test copy of the production database with a representative subset of real data (100-500 records per collection). Run the full migration process on this test data, validate the results, fix all issues, and only then schedule the production migration. The test run takes the same time as production but on a smaller dataset.
Why it's a problem: Not accounting for Firestore Timestamps during transformation
How to avoid: Explicitly convert Firestore Timestamps to ISO 8601 strings in your transformation script: new Date(ts._seconds * 1000).toISOString(). In Supabase/PostgreSQL, store as TIMESTAMPTZ columns.
Why it's a problem: Forgetting to migrate Firebase Auth users alongside Firestore data
How to avoid: Use the Firebase CLI to export and import user accounts: firebase auth:export users.json --format=JSON from the source project, then firebase auth:import users.json --hash-algo=SCRYPT --hash-key=... in the destination project. Contact Firebase support for the hash parameters from your source project.
Best practices
- Set up automated daily backups of your source database before starting any migration planning — you want at least 7 days of backups available
- Perform the production migration during your lowest-traffic window (typically 2-6am for most apps) and communicate the maintenance window to users in advance
- Use a dual-write strategy for zero-downtime migrations: briefly write to both old and new databases simultaneously while you validate the new database, then cut reads over to the new database, then stop writes to the old one
- Validate not just row counts but also referential integrity — run SQL foreign key checks on the imported data to catch broken references before going live
- Keep the old database read-only for at least 7 days after migration cutover as a safety net — if critical data issues appear, you can reference the original data
- Update your monitoring and alerting for the new database immediately after cutover — Firebase alerts on the old project will not fire for issues in the new one
- Document the migration process and schema mapping for future reference — database migrations are infrequent enough that team members forget the details by the time the next one is needed
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
I am migrating a FlutterFlow app's database from Firestore to Supabase. I have a Firestore export JSON file with a 'users' collection (fields: email, name, plan, createdAt Timestamp, profileImageUrl). Write a Node.js script that reads the export JSON, converts each document to a SQL INSERT statement for a PostgreSQL users table with columns (id, email, name, plan, created_at, profile_image_url), handles Firestore Timestamp conversion to ISO strings, and writes the SQL to a file. Include proper SQL escaping for special characters.
Help me update my FlutterFlow project to connect to a new Supabase database after migration. I need to update the Supabase Project URL and Anon Key in FlutterFlow settings, then verify all my Backend Queries work correctly with the new database. What should I test first to confirm the migration is working?
Frequently asked questions
How long does a Firestore to Supabase migration take?
The time depends heavily on data volume. A small app (under 50,000 documents) can complete the full migration — export, transform, import, validate — in 2-4 hours including testing. A mid-size app (500,000 documents) takes a day with proper tooling. A large app (millions of records) requires a carefully planned multi-day process with batch processing and parallel imports. The transformation script development is typically the longest part — plan 2-4 hours for writing and debugging the transform for a typical schema.
Can I roll back after migrating to a new database?
Yes, if you keep the old database intact and do not delete it. Keep your old Firestore or Supabase project active and read-only for at least 7 days after cutover. If critical issues appear (missing data, broken queries, performance problems), you can revert by updating FlutterFlow's database connection back to the old project. Maintain the old database until you are confident the new one is fully operational and data complete.
Will my users lose their login access during a database migration?
If you are migrating between Firestore projects and your users authenticate via Firebase Auth, they need their Auth accounts migrated separately. Firebase Auth and Firestore are separate — migrating Firestore does not migrate Auth users. Use firebase auth:export and firebase auth:import CLI commands with the correct hash parameters. If you are migrating from Firebase to Supabase Auth, users will need to reset their passwords since Supabase cannot decrypt Firebase's password hashes — plan a password reset email campaign.
How do I handle Firestore subcollections during migration?
Subcollections are not included in the standard Firestore Console export — you need to use the node-firestore-import-export tool which includes subcollections recursively. In the exported JSON, subcollections appear nested under their parent document as __collections__ objects. In your transformation script, extract and flatten these: a users/{uid}/orders subcollection becomes an orders table with a userId foreign key column pointing to the users table.
What if my FlutterFlow app has custom code that directly references Firestore collection names?
Review all Custom Actions and Custom Functions in your FlutterFlow project for hardcoded Firestore collection paths like FirebaseFirestore.instance.collection('users'). After migrating to a new project, these paths remain the same if you are doing a Firestore-to-Firestore migration. If migrating to Supabase, these Custom Actions need to be rewritten to use the Supabase client instead of the Firestore SDK — which is a significant code change beyond just data migration.
Can RapidDev help with a complex database migration?
Yes. Database migrations involving millions of records, complex relational transformations, Firebase Auth migration, zero-downtime cutover strategies, or migrating apps with active users require specialist experience to execute safely. RapidDev has managed Firestore-to-Supabase and cross-project Firestore migrations for production FlutterFlow apps. Reach out with your data volume, schema complexity, and timeline requirements for a migration plan.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation