Production Data Migration¶

This guide covers migrating live data from the original Firebase project (student-scheduler-v1) to the new production project (masterschedule-prod).

Do this before cutting over DNS

The new project's Firestore is empty. Until you complete this migration and update DNS, student-scheduler-v1 remains the live production database. There is no rush — both projects can coexist indefinitely.

What needs to migrate¶

Data	Location	Notes
School documents	`schools/{id}`	All school configs, metadata
Access records	`schools/{id}/access/{uid}`	User roles per school
Courses	`schools/{id}/courses/{id}`	All course records
Teachers	`schools/{id}/teachers/{id}`	All teacher records
Config	`schools/{id}/config/school`	School configuration
Audit logs	`schools/{id}/auditLog/{id}`	Optional — historical only
Superadmins	`superadmins/{uid}`	Platform admin grants
Auth users	Firebase Authentication	Separate step — see below

Prerequisites¶

You need the gcloud CLI and firebase CLI both installed and authenticated.

# Verify gcloud is installed
gcloud --version

# Authenticate
gcloud auth login
gcloud config set project masterschedule-prod

Step 1 — Export from student-scheduler-v1¶

In the Google Cloud Console, switch to the student-scheduler-v1 project.
Go to Firestore → Import/Export → Export.
Choose a GCS bucket in the same project (or create one: gs://student-scheduler-v1-export).
Leave collection group filters empty to export everything.
Click Export and wait for it to complete (typically a few minutes).

Or via CLI:

gcloud firestore export gs://student-scheduler-v1-export \
  --project=student-scheduler-v1

Step 2 — Copy the export to the new project's bucket¶

Create a GCS bucket in masterschedule-prod to receive the import:

gcloud storage buckets create gs://masterschedule-prod-import \
  --project=masterschedule-prod \
  --location=us-east1

Copy the export:

gcloud storage cp -r gs://student-scheduler-v1-export/* \
  gs://masterschedule-prod-import/

Step 3 — Import into masterschedule-prod¶

gcloud firestore import gs://masterschedule-prod-import/<EXPORT_FOLDER_NAME> \
  --project=masterschedule-prod

Replace <EXPORT_FOLDER_NAME> with the timestamped folder name created by the export (e.g., 2026-03-18T...).

Import overwrites

If masterschedule-prod already has any documents, the import will overwrite them. Run this on a fresh database for a clean migration.

Step 4 — Migrate Authentication users¶

Firestore data does not include Auth users — those must be migrated separately using the Firebase Admin SDK.

Install the Admin SDK tools:
```
npm install -g firebase-admin
```

Export users from student-scheduler-v1:

firebase auth:export users.json --project student-scheduler-v1

Import into masterschedule-prod:

firebase auth:import users.json --project masterschedule-prod \
  --hash-algo=SCRYPT \
  --hash-key=<key-from-old-project>

!!! warning "Hash key required" Google Sign-In users don't have password hashes, so the hash key is not strictly required for OAuth-only apps. You can omit --hash-algo and --hash-key if all your users sign in with Google.

Simplified version for Google-only auth:

firebase auth:import users.json --project masterschedule-prod

Step 5 — Verify the migration¶

Open the masterschedule-prod Firestore in the Firebase Console and confirm your school documents are present.
Open masterschedule-prod Authentication and confirm your users are listed.
Deploy to staging first and smoke-test with your account: ./deploy.sh --staging
When satisfied, deploy to production: ./deploy.sh --production

Step 6 — Update DNS (final cutover)¶

Once the new production deployment is live and verified:

In your DNS provider, point app.masterschedule.app → masterschedule-app.web.app
Point admin.masterschedule.app → masterschedule-admin.web.app
Point help.masterschedule.app → masterschedule-help.web.app
Point masterschedule.app → masterschedule-public.web.app

Firebase Hosting handles custom domains in Hosting → your site → Add custom domain.

After migration¶

Keep student-scheduler-v1 running in read-only mode for at least 30 days as a fallback.
After 30 days, disable new sign-ins in student-scheduler-v1 Authentication.
After 90 days, decommission the project entirely.