A phased migration from Firebase

Who is this for?

Mobile application and backend teams.

Before you start

An owned staging environment, sample user journey and access model.

1. Map current dependencies

List Firestore collections, Security Rules, Auth providers, Functions triggers, Storage files and offline behavior. Match cost-producing workflows to invoices; do not assume every component must move.

2. Prepare SQL models and authorization

Represent document relationships with tables, keys and indexes. Keep original document IDs in migration mappings. Move Security Rules behavior into API authorization; merely hiding an endpoint is insufficient.

3. Migrate identity carefully

User IDs, social identity links and password verification formats must fit the new Auth design. Test session continuity; otherwise plan controlled sign-in or password reset. Never convert passwords to plaintext.

4. Pilot a small workflow

Move a public catalog read to a versioned REST endpoint, for example. Start with exported data in an isolated environment. Validate client errors, offline behavior, paging and update handling.

5. Test cutover and rollback

Define incremental changes after the full transfer. Compare record counts, important fields and permission results. If dual writes are used, address conflicts and failure risks; set rollback conditions ahead of time.

6. Keep the parts that work

FCM or Crashlytics can stay in a hybrid setup. Uygulama Cloud does not provide managed Firebase migration or a compatible SDK today. This is a planning guide; no production transfer is executed automatically.

7. Map documents into a target schema

Copying every collection into a JSON column may not solve query and ownership requirements. Inventory identifiers, subcollections and references. Define missing fields, timestamps, deletion and version behavior. Build a repeatable staging transform with identity mappings and uniqueness so a second run does not duplicate records.

8. Revalidate identity and rules

Map existing user identities to data references. Do not assume password or session formats transfer unchanged; verify supported migration paths and a possible sign-in transition. Translate Security Rules into target API or data policies, then test cross-user reads, writes and file access.

9. Define cutover and rollback

Choose a one-way move, a bounded write pause or controlled dual writes. Partial dual-write success needs recovery logic. Compare counts, sampled values, references and device behavior. Decide how post-cutover writes return to the old system before opening both paths.