Firebase → Appwrite
Move application data, authentication, authorization, storage, functions, triggers, realtime behavior, indexes, clients, and backups from Firebase into Appwrite with an explicit exception ledger and evidence-based cutover.
Should you make this move?
Both platforms have a case. Compare what you gain with what you give up before scheduling the cutover.
Firebase
- Authentication, realtime data, hosting, and mobile tooling enable very fast product delivery
- Managed infrastructure removes a large amount of operational work
- NoSQL modeling, usage-based costs, and Google-specific APIs can be difficult to unwind
- Platform-specific services can create architectural lock-in
Appwrite
- Open-source authentication, databases, storage, and functions provide an integrated backend
- Managed infrastructure removes a large amount of operational work
- Its data model, runtime services, and operational maturity require careful production evaluation
- Platform-specific services can create architectural lock-in
Appwrite: Open-source authentication, databases, storage, and functions provide an integrated backend. This removes a major source-side concern: NoSQL modeling, usage-based costs, and Google-specific APIs can be difficult to unwind.
What you lose: Authentication, realtime data, hosting, and mobile tooling enable very fast product delivery. What you inherit: Its data model, runtime services, and operational maturity require careful production evaluation.
Jump to a section
Know the shape of the move.
This timeline assumes
- Up to one million records, 100,000 users, 100 GB of files, and 100 functions
- Application owners can ship coordinated client and server releases.
- A production-shaped dataset and identity cohort are available for rehearsal.
- The source remains authoritative until final consistency and security checks pass.
- The migration team records evidence for every blocking verification check.
What survives the move.
“Partial” and “manual” are not footnotes. They are work that must be scheduled and verified.
| Item | Outcome | Impact | What happens | Mitigation |
|---|---|---|---|---|
| Application data, identities, storage objects, functions, and client configuration | partial | critical | Core application data, identities, storage objects, functions, and client configuration can move, but Firebase and Appwrite use different models, limits, identifiers, and import behavior. | Pilot every feature class, preserve source IDs, and reconcile accepted, transformed, rejected, and excluded items. |
| Authorization, realtime, offline behavior, triggers, managed services, and operational history | manual | critical | Firebase-specific runtime configuration and historical evidence do not become native Appwrite behavior through the core data transfer. | Inventory every active dependency, approve its destination disposition, and test the replacement before source writes stop. |
| Primary application data | partial | critical | Records can move while source and destination data models, types, identifiers, and constraints differ. | Design the target schema and preserve stable source IDs. |
| Nested data and relationships | partial | critical | Document nesting, references, joins, and cascade behavior require explicit transformation. | Model relationships and verify orphan, duplicate, and cascade behavior. |
| Authentication users | partial | critical | Accounts may move while password hashes, providers, MFA, verification, and sessions require separate handling. | Choose a supported rolling or one-off identity strategy. |
| Authorization and security rules | manual | critical | Source rules do not execute as destination database or storage policy. | Translate into least-privilege policies and test every role. |
| File and object storage | partial | critical | Objects, metadata, signed URLs, paths, and access policies require separate copying. | Copy with checksums and verify authorized and anonymous access. |
| Serverless functions and triggers | manual | critical | Runtime APIs, triggers, regions, retries, and secrets differ. | Port and integration-test every function and failure path. |
| Realtime subscriptions | partial | high | Event ordering, payloads, filters, reconnects, and delivery guarantees differ. | Rewrite clients and test concurrency, disconnect, and replay behavior. |
| Offline behavior and local cache | lost | high | Source client SDK persistence does not automatically exist in the destination stack. | Choose and test an explicit offline and conflict strategy. |
| Indexes and query behavior | manual | critical | Query planners, indexes, limits, and transaction semantics differ. | Benchmark representative queries against production-shaped data. |
| Analytics, crash reporting, and messaging | lost | high | Adjacent platform products do not follow database data. | Keep, replace, or retire each service explicitly. |
Where each thing goes.
| Source | Destination | Method | Notes |
|---|---|---|---|
| Firebase project | Appwrite project | manual | Record regions, environments, owners, and billing. |
| Collection, document, or record | Destination table and row | transform | Preserve source IDs and types. |
| Nested object or reference | Column, JSON, or relation | transform | Choose explicit relational semantics. |
| Authentication user | Destination auth user or federated identity | transform | Preserve verification and provider identifiers where supported. |
| Security rule | Destination authorization policy | manual | Translate and test every role and path. |
| Storage object | Destination storage object | transform | Preserve path, metadata, checksum, and access. |
| Function or trigger | Destination function, hook, or scheduled job | manual | Port retries, idempotency, and secrets. |
| Realtime listener | Destination subscription | transform | Rewrite payload and reconnect handling. |
| Index and query | Destination index and query | manual | Benchmark production-shaped workloads. |
Make the move recoverable.
Create the source-of-truth backup
Preserve Firebase data, configuration, and operating evidence before any destination write.
- Export Firebase data, schema, identities, security rules, storage, functions, indexes, configuration, and logs.
- Record counts, checksums, sizes, auth states, policies, and query baselines.
- Capture client versions, SDK configuration, integrations, backups, and recovery procedures.
- Hash raw exports and transform working copies only.
Proof to capture: A signed manifest reconciles every scoped record class, runtime dependency, export file, count, and hash.
Target schema and identity map
Translate records, relationships, users, and stable IDs.
- Inventory source values and exceptions.
- Define explicit destination mappings.
- Reject unmapped critical records.
Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.
Policy and client compatibility layer
Preserve authorization and support controlled client rollout.
- Normalize encoding, dates, identifiers, and blanks.
- Run a representative pilot.
- Reconcile accepted, rejected, and transformed rows.
Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.
The things most likely to hurt.
These are operating limits. Treat every “Stop if” condition as a blocked migration, not a suggestion.
Data-model transformation changes meaning
Nested values, identifiers, timestamps, or relationships differ after import.
- Consequence
- Applications read incorrect or incomplete data.
- Mitigation
- Use deterministic transforms and record-level reconciliation.
Stop if: Any critical invariant fails.
Authorization is weaker than the source
A destination role can read or write unauthorized rows or objects.
- Consequence
- Sensitive data is exposed or changed.
- Mitigation
- Default-deny and test every policy with real client identities.
Stop if: Any unauthorized operation succeeds.
Old and new backends both accept writes
Client versions or triggers write to different systems.
- Consequence
- Data diverges permanently.
- Mitigation
- Use version gates, a write freeze, or an approved dual-write reconciliation design.
Stop if: Unreconciled writes appear in either system.
Do the work in this order.
- Days 1–3 · inventory
Inventory and decisions
6–12 hours active2–3 days elapsedOwner review waiting- Inventory Firebase data, features, users, domains, and integrations.
- Approve scope, owners, mappings, and exclusions.
Depends on: Firebase and Appwrite administrator access
Stop / go checkpointExport?
Go when: Every critical item has an owner and disposition.
Stop when: Consent, billing, access, or system ownership is unclear.
- Days 3–5 · backup
Backup and reconcile
5–10 hours active1–3 days elapsedExport processing waiting- Create immutable exports and configuration evidence.
- Reconcile counts, totals, and hashes.
Depends on: Approved inventory
Stop / go checkpointTransform?
Go when: Source totals and export manifests agree.
Stop when: Any critical dataset or configuration is absent.
- Days 5–12 · pilot
Map and pilot
10–35 hours active3–8 days elapsedDestination processing and review waiting- Configure Appwrite and transform representative data.
- Run a pilot containing normal records and every critical edge case.
Depends on: Verified backup
Stop / go checkpointScale?
Go when: Pilot mappings, behavior, access, and evidence pass.
Stop when: Any critical check fails or produces unexplained variance.
- Days 10–20 · cutover
Final delta and switch
5–25 hours active1–5 days elapsedDNS, import, or sync propagation waiting- Freeze production writes in Firebase.
- Apply the final delta, switch ownership, and run blocking checks.
Depends on: Passed pilot and approved rollback
Stop / go checkpointOpen production?
Go when: Counts reconcile and one destination system owns production.
Stop when: A source writer remains active or a blocking check fails.
- Days 12–40 · observe
Observe and close
3–18 hours active3–10 days elapsedOperating-cycle evidence waiting- Monitor one complete operating cycle.
- Sign the verification report and close rollback only after stability.
Depends on: Verified cutover
Stop / go checkpointClose rollback?
Go when: No trigger occurs during the agreed observation period.
Stop when: Data, access, delivery, routing, or business results regress.
Cut over with a way back.
Cutover
Make Appwrite the only production system without losing the final Firebase delta.
- Freeze production writes and scheduled actions in Firebase.
- Export, transform, and reconcile the final delta.
- Apply the approved delta to Appwrite.
- Switch domains, forms, integrations, sending, or sync ownership as applicable.
- Run every blocking verification check and keep the source intact.
Proof to capture: Appwrite owns production, totals reconcile, and every blocking check has durable evidence.
Rollback
Return production ownership to Firebase without losing destination-era changes.
- Stop new writes and scheduled actions in Appwrite.
- Restore the prior Firebase routing, forms, integrations, sending, or sync ownership.
- Export the Appwrite post-cutover delta.
- Review and apply safe destination-era changes to Firebase.
- Run the same blocking checks against the restored source.
Proof to capture: Firebase again owns production with current data and no duplicate destination action.
- Unexplained critical count or value variance
- Missing or exposed critical data
- Duplicate production action
- Failed access, routing, delivery, or integration check
- A critical feature has no safe destination replacement
Prove the migration worked.
Every blocking check must pass. Capture the evidence before cleanup begins.
| Pass | ID | Check | Method | Expected result | Evidence |
|---|---|---|---|---|---|
V-01Blocking | Record reconciliation | Compare counts, checksums, aggregates, and stratified records. | Every scoped record is accounted for. | Data ledger. | |
V-02Blocking | Types and relationships | Test constraints, identifiers, nulls, dates, arrays, and cascades. | All critical invariants hold. | Schema report. | |
V-03Blocking | Authentication states | Test every provider, verification, reset, MFA, and session path. | Users can authenticate only as approved. | Auth matrix. | |
V-04Blocking | Data and storage policy | Run allowed and denied operations for every role. | Every policy defaults and resolves correctly. | Policy test report. | |
V-05Blocking | Object coverage | Compare paths, sizes, hashes, metadata, and signed access. | Every required object is durable and correctly protected. | Storage manifest. | |
V-06Blocking | Triggers and side effects | Run success, retry, timeout, duplicate, and failure cases. | Idempotent approved outcomes. | Function log. | |
V-07Blocking | Query, realtime, and offline behavior | Run supported client versions through representative workloads. | Correct reads, writes, events, and recovery. | Client matrix. | |
V-08Blocking | Backup and rollback | Restore a destination backup and execute the rollback rehearsal. | Recovery objectives and integrity pass. | Recovery report. |
Remove the scaffolding safely.
Safe after: One complete operating cycle, at least seven stable days, and owner sign-off on every blocking check.
- Create final Firebase exports and archive verification evidence.
- Revoke temporary credentials, API keys, webhooks, and elevated roles.
- Remove obsolete embeds, forms, jobs, integrations, and DNS records.
- Keep the source intact through the approved retention window.
- Cancel paid plans only after billing, legal, and recovery review.
- Schedule the next Appwrite backup, access, and migration-playbook review.
When the plan met reality.
First-hand accounts are preferred. Vendor case studies are labeled, and every note below is an editorial paraphrase—follow the link for the full context.
Sudarshan Dhakal describes moving projects from Firebase to Appwrite in search of similar managed-backend ergonomics with more control and a self-hosting path. Authentication was the hardest part because password hashes could not be exported through the chosen route, leading to gradual migration for some projects and forced resets for others. Firestore collections mapped reasonably well to Appwrite collections, while storage moved through a custom download-and-upload script.
- Choose between gradual account migration and a forced password reset before cutover, then communicate that identity plan clearly.
- Build and test explicit transfer scripts for storage and data instead of assuming similar SDK concepts imply automatic compatibility.
- The application-code change felt approachable because the SDK models were similar, but user authentication still required a product-level transition.
- Moving to Appwrite also changed the operating model by creating a later option to shift from Appwrite Cloud to a self-hosted instance.
Verify against the primary material.
Platform behavior changes. Check these sources and the review dates above before executing a production migration.
- Firebase: official migration documentationAccessed 2026-07-19
- Appwrite: official migration documentationAccessed 2026-07-19