How to export your data from Firebase without losing users or records
A renewal notice, a Blaze billing change or a data residency requirement is often the moment a team needs its Firebase data out. Firestore, Firebase Authentication and the Realtime Database each have a documented export path, but none of them produces a single portable archive, so the export is three separate jobs with three separate sets of gaps. Plan them as a inventory: list every collection, every user population and every database tree before anyone runs a command.
Firestore exports with gcloud firestore export gs://BUCKET and copies all documents, or the collection groups you choose, to Cloud Storage. Read the limits before relying on it: the export is not an exact point-in-time snapshot, exporting a collection group does not include its subcollections, and the export does not contain index definitions, so indexes must be recreated on the target. Security rules logic is not part of the data either, so the access model has to be rewritten separately. Auth uses the Firebase CLI command auth:export, which writes each user's UID, email, verification status, profile fields, linked providers, timestamps and phone number to JSON or CSV. Password hashes and salts come out only for accounts that use the scrypt algorithm; other accounts export with empty passwordHash and salt fields until the user signs in again, so confirm how many accounts fall into each group before promising users they will not reset passwords.
Realtime Database data leaves as JSON. Blaze projects can enable daily backups of data and security rules to a Cloud Storage bucket, which are Gzip-compressed by default, and those backups are the cleanest full copy of the tree. Cloud Functions, Dynamic Links and any OAuth sessions do not transfer in any of these exports and must be rebuilt or retired. Ask your Firebase administrator to confirm which of these paths your project has enabled, who holds the roles to read the buckets, and where the files will sit, because a copy in a Cloud Storage bucket in the wrong location can undo a residency decision. Consult the Firebase export and import documentation for the current command options before you script the job.
Which Firebase data types export, and in what format
This table compares the three Firebase data sets most teams need to take out: Firestore documents, Authentication users and Realtime Database trees. Read each row for the export method, the output format and the limits that affect whether the export is usable on a self-hosted target. The main takeaway is that each service exports differently, so the migration plan needs one path per data type.
| Data type | Export method | Format | Limits and notes |
|---|---|---|---|
| Cloud Firestore documents | Managed export with gcloud firestore export gs://BUCKET to Cloud Storage, all documents or chosen collection groups | Firestore export files in Cloud Storage, also loadable into BigQuery | Not an exact snapshot; subcollections are not included when exporting a collection group; index definitions are not included, so recreate them on the target |
| Authentication users | Firebase CLI auth:export | JSON or CSV | Includes UID, email, verification status, password hash and salt, display name, photo URL, provider links, timestamps and phone number; only scrypt-hashed passwords export hashes |
| Realtime Database data and rules | Daily automated backups enabled on Blaze projects, written to a Cloud Storage bucket | JSON, Gzip-compressed by default | Requires the Blaze plan; backs up data and security rules together; confirm retention and restore steps in your project settings |
| Authentication accounts with non-scrypt hashes | Firebase CLI auth:export | JSON or CSV with empty hash fields | Accounts imported with other algorithms export empty passwordHash and salt until the user signs in; hash parameters come from the Firebase console |
What Firebase does not export and how to work around each gap
A Firebase export moves data, but it leaves behind indexes, some nested data, password fields that depend on the hash type, and all server logic. Each card below names one gap and the step that closes it before cutover.
Firestore index definitions
A managed export holds documents, not the composite and single-field index definitions that serve your queries. On the target, recreate every index that your app queries depend on before you load traffic, or queries that worked on Firestore will slow down or fail. Compare the indexes in the Firebase console with your query list, then rebuild them in the target database and test the slowest queries against a loaded copy.
Subcollections missing from group exports
Exporting a collection group does not include its subcollections, so a partial export can look complete while whole branches of the data tree are absent. Inventory every subcollection path in your schema, export each one explicitly, and count documents per path on both sides after the load. This matters most for data that is organized by user or tenant, where a missing branch hides records from only some accounts.
Exports are not an exact snapshot
A Firestore export is not a point-in-time snapshot of a live database, so writes that happen during the export can appear in some documents and not others. Plan a write freeze for the cutover window or run a reconciliation job that compares changed documents after the export. Ask your team which collections receive writes all day, since those need the reconciliation step most.
Empty password fields for non-scrypt accounts
The Firebase CLI exports password hashes only for accounts that use scrypt. Accounts imported with other algorithms export with empty passwordHash and salt fields until each user signs in again. Before you plan the cutover, count how many accounts have empty fields in the export, decide whether those users reset passwords or sign in through another method, and tell support teams which path applies.
Hash parameters held in the console
The export gives you the password hash and salt, but not the signer key, salt separator, rounds and memory cost that the hash needs. Those parameters come from the Firebase console, so someone with project owner access must copy them before the project changes. Store them with the export in your secure backup location, and verify one test login on the target before you move the full user base.
Cloud Functions and Dynamic Links logic
Data exports carry no server code, so triggers, scheduled jobs, and Dynamic Links behavior stay behind when you leave Firebase. Dynamic Links shut down on August 25, 2025, so any link that still reaches your users no longer resolves through Firebase. Inventory each function and each link pattern, rebuild them on the target, and redirect old links to the new destinations before you retire the project.
The export sequence and how to verify each step
This sequence produces a complete, verified copy of Firestore documents, Auth user records with their password hash parameters, Realtime Database backups and Cloud Storage files, each checked against the live source before any migration begins. Work through it in order, because later steps depend on the inventory and the bucket created earlier.
Inventory collections, users and data sources
Before exporting anything, list every Firestore top-level collection and any collection groups with subcollections, every Realtime Database path, every Cloud Storage bucket, and the total Authentication user count shown in the Firebase console. Record document counts per collection where the console allows it, and note which Auth providers are in use. You do this yourself, with read access to the project. The output is a written inventory that becomes your baseline for every later check. Confirm the project ID and that you are looking at the production project, not a staging copy.
Enable Blaze and prepare the export bucket
Cloud Storage for Firebase now requires the Blaze plan, and the Firestore export and Realtime Database backups both write to a Cloud Storage bucket, so the project must be on Blaze before these steps run. Create a dedicated bucket and set its location deliberately, because it determines where your exported copy physically sits. Grant the account that runs the export the IAM roles needed to write to the bucket and to run Firestore exports. The exact role names and the required permissions change over time, so confirm them in the Google Cloud console and in Firebase's export documentation for your own project. The output is a bucket you can list and an account you have tested with a small write.
Run the Firestore managed export
Run the managed export with the gcloud CLI, pointing it at the bucket from the previous step, either for all documents or for chosen collection groups. Remember that the export is not an exact point-in-time snapshot, so freeze writes or accept the gap if you need consistency, and that a collection group export does not include its subcollections, so export them explicitly. Exports do not carry index definitions, so write those down from the console now. When the operation finishes, list the output folder in the bucket and confirm the metadata file and per-collection output exist for each collection in your inventory.
Export Auth users and record hash parameters
Run the Firebase CLI auth:export command to write users to JSON or CSV, including UID, email, verification status, password hash and salt, provider links, and timestamps. The export only includes scrypt-hashed passwords; accounts that were imported with other algorithms show empty hash and salt fields until those users sign in again, so count those accounts separately. The hash parameters (signer key, salt separator, rounds and memory cost) are not in the export file, so copy them from the Firebase console and store them with the export. The output is a user file whose record count matches the user total from step one, plus a stored parameter record.
Back up Realtime Database as JSON
If the project uses Realtime Database, enable the daily automated backup to a Cloud Storage bucket in the Firebase console, or trigger a manual backup if you need one now. Backups write data and security rules in JSON, Gzip-compressed by default. Download the backup files from the bucket and keep the security rules file alongside them, because rules are not automatically rebuilt on the target. Confirm you have a backup file dated after your last write window. Realtime Database has no Firestore-style document structure, so the JSON tree is the reference you will reshape later. The output is a readable JSON file that you can open and spot-check.
Copy Cloud Storage files to a second location
Copy the buckets listed in your inventory to your own storage, keeping object paths and metadata such as content type and custom metadata where the tool preserves them. Use a copy tool that reports per-object results and errors, and keep the Firebase Storage bucket read-only during the copy if you need a consistent set. Access to these objects follows the rules you configured in Firebase, so use an account with the storage read permission you have confirmed. The output is a copy whose object count and total size match the source listing.
Verify counts, samples and checksums against the source
Compare each export with its source before you treat it as a backup. For Firestore, match document counts per collection against the inventory and open a random sample of documents to check field types, timestamps and nested maps. For Auth, match total user records and count accounts with empty hashes. For Realtime Database, compare key counts for the top-level paths. For Storage, compare object counts and generate checksums on both sides for a sample or all objects. Record any mismatch with its cause, and rerun the affected export until the numbers agree. The finished verification log is the document you will later use to prove the export is complete.
Store exports under controlled access
Move the verified exports into storage that your organization controls, with access limited to the people who will run the migration and restricted encryption keys if your policy requires them. Keep the verification log, the Auth hash parameters, the index list and the Realtime Database security rules in the same location, so the migration team can reproduce each check. Confirm retention and access rules with your security and data protection owners, since exports contain personal data and password hashes. The output is a labeled, access-controlled archive with its verification record attached.
Why password hashes decide whether users keep their logins
Password hashes decide whether users can keep their current passwords after cutover. Firebase Auth hashes passwords with a modified scrypt algorithm by default, and the Firebase CLI's auth:export command writes each user's passwordHash and salt together with the hash parameters, but only for accounts that use scrypt. Accounts imported with other algorithms export with empty passwordHash and salt fields until the user signs in again. Run an export against your own project before planning anything, and count how many records carry populated hash fields. Those without them will need a reset flow, a magic link or a forced reauthentication step on the target.
The target platform must accept the same algorithm and parameters, or the hashes are useless. Appwrite's Users API lists Scrypt modified among the hash types it accepts on import, alongside bcrypt, Argon2, MD5, PHPass, Scrypt and SHA. Acceptance in the API reference is not the same as a working login, so confirm with Appwrite, in writing, that the signer key, salt separator, rounds and memory cost you take from the Firebase console map exactly to the fields the import expects. Then import a small test set of real exported accounts into a non-production instance and sign in with known passwords. Do the same check for Supabase Auth, which the Firebase migration path also covers, before you choose a target.
Treat the hash parameters as sensitive. The signer key is a secret that Firebase holds, and it must be copied through a controlled channel, stored with restricted access and deleted from working folders once the import is verified. The export file itself contains UIDs, email addresses, phone numbers and password hashes, so it belongs in the same access tier as the database backups it resembles. Record who ran the export, when, and where the file went, because your auditors will ask. If any user cannot be migrated with a hash, plan a communicated reset period rather than discovering the gap on cutover day.
Questions teams ask before exporting from Firebase
How long does a Firebase data export take?
The honest answer is that duration depends on what you are exporting and where it lands, and no duration figure is supplied for this page, so confirm it with Google's documentation and a test run in your own project. The main drivers are total data volume, how many collections or collection groups you export, the Cloud Storage bucket location relative to your Firestore location, and whether you run the export during or outside normal write traffic. Run a timed export of a representative subset first, then extrapolate with the team that owns the data. Ask any partner to base the schedule on that measured test, not on a generic estimate.
Does a Firestore export require the Blaze plan and specific IAM roles?
Confirm the exact requirements in the current Firebase export and import documentation before you plan, because billing and IAM rules change. In practice, the export writes to a Cloud Storage bucket, so you need a billing-enabled project for that storage and a principal with permission to start a Firestore export and write to the target bucket. Grant the narrowest roles that work, scope them to the one bucket, and remove them after the export. Document who holds those roles, because the same access pattern is what auditors will ask about.
Can a team on the free tier run a Firestore export?
Check this against current Firebase pricing and the export documentation, since eligibility for managed exports depends on the plan and the Cloud Storage requirements that apply to your project. If the export needs a Cloud Storage bucket that the free tier cannot provide, you will need to upgrade before running it. Even where the export itself is possible, the team still needs a place to store the output and a way to load it, so confirm the full path before assuming a free-tier path exists.
How do you avoid downtime and write drift during an export?
Firestore's managed export is not an exact snapshot, so writes that happen during the run can appear in some documents and not others. Plan a write freeze or a maintenance window for the collections that must be consistent, or route writes through a queue you can pause. Record the export start time, compare document counts and spot-check recent records after the load, and keep the Firebase project live until reconciliation passes. Ask any partner how they will detect and resolve drift in your data model before cutover.
Can our own engineers export the data without outside help?
Yes, a team with Firebase project access can run the managed export with the gcloud command and copy the output to storage they control. The harder work follows the export: the output is in Firestore's own format, indexes are not included and must be recreated, subcollections of collection groups need separate handling, and the target schema, such as Postgres tables or Appwrite collections, has to be designed. Auth users and Realtime Database data use different export paths with different gaps. Decide early which of these steps your engineers will own and which the partner will cover.
What are the cost components of exporting from Firebase?
There are four components to budget. Cloud Storage holds the exported files, and you pay for the storage while the copies exist. Network egress applies when you move data out of Google Cloud to another location, and it depends on volume and destination, so check the current pricing for your route. Operator time covers scripting, validation, reconciliation and document updates, which recurs for each test run and the final cutover. Finally, the migration and any target platform work is a one-time project cost. Ask for each component to be priced separately in a written quote so you can see which parts repeat.
What should we ask a partner to include in a written export scope?
Ask for a written scope that names every service in the export, including Firestore collections and collection groups, Auth users with their password hash parameters, Realtime Database JSON backups, and Cloud Storage files. The scope should state who holds the Google Cloud roles, where the exported data is stored and how it is encrypted and deleted afterward, how write drift is handled, which validation checks prove the copy is complete, and what is excluded, such as indexes, Cloud Functions or extensions. Ask for named deliverables, acceptance criteria and a timeline agreed before work starts. DeployOpen agrees scope, deliverables and timelines in writing before fixed-scope work begins, and provides a quote from that written scope.
What to plan before the Firebase contract or Blaze billing ends
Exporting data is the last step of a Firebase exit, and the decisions that make it safe come first. The cards below cover lifecycle deadlines, where exports land, residency constraints, target selection and rehearsal, so the export runs once in a planned way rather than under pressure at cutover.
Confirm the Extensions shutdown date
Firebase Extensions shuts down on March 31, 2027, after which deployed extensions can no longer be updated, reconfigured or uninstalled. List every extension in each Firebase project, note which ones write data, send email or run triggers, and record who owns each one. Extensions that hold data or triggers should be mapped to a replacement before the exporter removes access.
Check for retired Firebase services
Dynamic Links shut down on August 25, 2025, so any link resolution or deep link flow still pointing at Firebase will already be broken. Search mobile apps, email templates and marketing material for Dynamic Links domains. Identify any other Firebase service in use that your export plan does not cover, and treat those dependencies as part of the inventory rather than as leftovers.
Store exports in a bucket you control
Firestore managed exports write to a Cloud Storage bucket, and Realtime Database backups also go to a bucket in your project. Create or designate a destination bucket that your team administers, restrict write and delete permissions to a small group, and set retention rules that match your policy. Confirm that the export identity can write and that no one can silently delete or overwrite the archive before migration is verified.
Record US-only Auth processing
Firebase Authentication processes data only in the United States, even when Firestore uses a European location. Record this in your data inventory and residency assessment, and note which user fields (email, phone, provider links, timestamps) are exported as part of the user record. Ask your privacy and compliance owners to decide where the exported user data will be held and processed during the transition.
Fix the target and region early
A Cloud Firestore database's location cannot be changed after it is provisioned, so the export must match the region your new platform will serve from, not the region you hoped to move to later. Choose the target platform (Supabase, Appwrite or PocketBase) and its hosting region before scheduling exports, and confirm that the chosen region meets your residency and latency requirements.
Rehearse the export before cutover
Schedule a dry-run export into a non-production target and compare document counts, Auth user totals and file counts against the source. Remember that Firestore exports are not exact snapshots and do not include index definitions, so plan to recreate indexes on the target and retest queries. Record each run's findings and set the cutover date only after two consecutive clean rehearsals.
Where exported data can land on a self-hosted target
The target design decides how useful your export is, so decide it before you copy anything. For Supabase, Firestore exports become Postgres tables, Auth users can be imported into the auth schema using the project's scrypt parameters, and Storage files can be moved with the community scripts in the supabase-community firebase-to-supabase repository, which Supabase documents for Firestore data, Auth users and Storage files. For Appwrite, the Migrations feature imports Firebase projects, and its Users API accepts several imported hash types, including Scrypt modified. PocketBase has no documented Firebase importer, so any move there means writing your own transform. In every case, confirm the current tooling and the supported hash formats with each vendor's documentation and test with a copy of your data before planning a cutover, because these scripts and APIs change between releases.
Self-hosted Supabase runs as a single project, and its Studio does not support multiple organizations or projects. If your Firebase setup separated environments or tenants by project, plan how those map onto separate deployments rather than assuming one instance will hold them. Appwrite's Helm chart documentation says its built-in PostgreSQL, Redis, ClickHouse and object storage each run a single replica without replication or failover, so an archive or production dataset kept only on those built-in datastores has no failover path. Decide early whether the target will use managed databases or operators with replication, and whether backups will be taken from the target itself, since Supabase lists managed backups and point-in-time recovery as unavailable when self-hosting.
Ask your DeployOpen team or the vendor to confirm three things for your target: which migration path covers each Firebase service you use, how the hash parameters for your Auth users will be supplied, and where the backup copies of the Firestore export and Realtime Database JSON will be stored and restored from. Keep the original export files in a bucket you control, with the same retention rules you applied to the source, until the target has passed your restore test.
How DeployOpen scopes and delivers a Firebase data export
DeployOpen plans and runs Firebase data exports as fixed-scope work inside your own cloud accounts or data centers. We agree the scope in writing first, then export, verify and document each service's data so your team can see what moved, what was left behind and what still needs rebuilding.
How we scope
- Inventory which Firebase services hold data: Firestore, Auth, Realtime Database and Cloud Storage
- Agree in writing which collections, collection groups, user records and buckets are in and out of the export
- Confirm the Firebase project permissions and Cloud Storage destination your team will grant for each export
How we build
- Run Firestore managed exports to a bucket you control, and record the export scope and timestamp for each run
- Export Auth users with password hashes and the scrypt parameters the Firebase CLI reports, then list accounts that lack hashes
- Test a restore into a non-production target, checking document counts, index recreation needs and user login behavior
How we hand over
- Deliver a written gap register covering indexes, subcollections, Realtime Database data and users without exportable hashes
- Document each export command, its permissions, its output locations and the checks used to confirm completeness
- Walk your engineering and security teams through the runbook so they can repeat or audit the export themselves
How we support
- Support is available as a retainer for repeat exports, re-runs before cutover and questions after handover
- Ongoing support, upgrades and continuous testing can be added to the written scope as a retainer
- Ask any provider, including DeployOpen, to state in the quote which export steps and checks are included
