Hosting migration

Firebase Hosting → Cloudflare Pages

Move a Firebase-hosted site to Cloudflare Pages while translating build output, redirects, headers, rewrites, functions, authentication, data services, domains, previews, and rollback.

Typical timeline7–15 business days24–50 hours active work

Statusneeds review

Source testedFirebase Hosting configuration reviewed 2026-07-19

Destination testedCloudflare migration guide updated 2026-04-21

Last reviewed2026-07-19

Sources3

Before you migrate

Should you make this move?

Both platforms have a case. Compare what you gain with what you give up before scheduling the cutover.

Current platform

Firebase Hosting

Reasons to stay

Simple static hosting integrates cleanly with the wider Firebase platform
Managed deployments reduce infrastructure and release-management work

Reasons to leave

Edge controls and framework deployment options are narrower than specialist hosting platforms
Runtime assumptions, platform services, and pricing models shape the architecture

New platform

Cloudflare Pages

What gets better

Static sites deploy globally with simple previews and strong Cloudflare integration
Managed deployments reduce infrastructure and release-management work

What gets worse

Pages-specific workflows and Functions constraints can limit complex full-stack applications
Runtime assumptions, platform services, and pricing models shape the architecture

Best of the move

Cloudflare Pages: Static sites deploy globally with simple previews and strong Cloudflare integration. This removes a major source-side concern: Edge controls and framework deployment options are narrower than specialist hosting platforms.

Worst of the move

What you lose: Simple static hosting integrates cleanly with the wider Firebase platform. What you inherit: Pages-specific workflows and Functions constraints can limit complex full-stack applications.

01At a glance

Know the shape of the move.

Transfer outcome10 features audited

Clean1

Partial4

Manual5

Lost0

Mapping route8 of 8 fields have a destination path

SourceFirebase Hosting8 mapped fields

Automatic1

Transform3

Manual4

Unsupported0

DestinationCloudflare Pages8 supported paths

This timeline assumes

A static site or app with one Firebase Hosting target and a Git repository.
firebase.json identifies the public build directory.
Cloud Functions, Auth, Firestore, Storage, and other Firebase services are separate workstreams.
The same production commit is deployed to both platforms for comparison.
Firebase remains intact through verification.

02Loss matrix

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
Static files and assets	clean	critical	Pages can deploy the same build directory identified by Firebase Hosting.	Compare route and asset manifests.
Build command	manual	high	Firebase Hosting does not store a universal build command.	Document and pin the repository build.
Redirects and headers	partial	high	firebase.json rules require translation to Pages configuration.	Assert every status, location, and header.
Rewrites and SPA fallback	partial	critical	Rewrite precedence and function targets differ.	Build a route matrix including deep links and 404s.
Cloud Functions	manual	critical	Functions do not transfer with static output.	Rewrite as Pages Functions/Workers or keep an explicit external backend.
Firebase Auth	manual	critical	Hosted site migration does not migrate identity or sessions.	Test allowed origins, redirects, cookies, and every login flow.
Firestore, Realtime Database, and Storage	manual	critical	Backend data services remain on Firebase unless separately migrated.	Document retained services or run independent data migrations.
App Check, Analytics, Performance, and Remote Config	partial	high	SDKs may continue, but origins, policies, and observability change.	Test each integration and update allowed domains.
Preview channels	partial	medium	Pages previews use different URLs and CI triggers.	Rebuild branch policy and protection.
Custom domain and TLS	manual	critical	DNS must move from Firebase to Pages.	Pre-validate domain, certificate, and rollback record.

03Field and feature mapping

Where each thing goes.

Source	Destination	Method	Notes
firebase.json public	Pages build output directory	automatic	Verify actual build artifact.
Build script	Pages build command	manual	Pin runtime and package manager.
redirects	_redirects	transform	Test order and status.
headers	_headers	transform	Test static response headers.
rewrites/function target	Pages Function/Worker route	manual	Rewrite backend behavior.
Environment config	Pages variable/secret or Worker binding	manual	Rotate and scope.
Preview channel	Pages preview deployment	transform	Update CI URLs and access.
Custom domain	Pages custom domain	manual	Switch DNS after preview validation.

04Before you begin

Make the move recoverable.

Backup procedure

Create the source-of-truth backup

Preserve the known-good build, hosting rules, backend dependencies, domains, and recovery path.

Record the production commit, public directory, build command, redirects, headers, rewrites, domains, preview channels, functions, Auth, data, Storage, SDKs, and integrations.
Build and hash the production artifact.
Export or snapshot backend data according to each service.
Crawl routes and headers.
Record DNS and rollback values.

Proof to capture: A manifest covers every route rule, artifact, backend dependency, domain, and restore point.

Transformation · Pages _redirects, _headers, and Functions

Hosting rule translation

Preserve request behavior.

Map each Firebase rule.
Test precedence, SPA fallback, and 404s.
Reject loops and chains.

Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.

Transformation · Architecture and integration test matrix

Backend boundary map

Make retained Firebase dependencies explicit.

List each SDK and endpoint.
Update origins and keys.
Test auth, data, storage, and failure behavior.

Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.

05Handle with care

The things most likely to hurt.

These are operating limits. Treat every “Stop if” condition as a blocked migration, not a suggestion.

Preview

Static pages pass while backend rewrites fail

criticalpossible likelihood

Deep or API routes return fallback HTML.

Consequence: Application actions fail.
Mitigation: Test every route class directly.

Stop if: Any backend path returns the wrong handler.

Integration

Auth rejects the new domain

criticalpossible likelihood

OAuth redirects or authorized-domain checks fail.

Consequence: Users cannot sign in.
Mitigation: Add and test the Pages/custom domain before cutover.

Stop if: Any required login or recovery flow fails.

Cleanup

Firebase project is deleted too early

criticalpossible likelihood

Hosting and backend services share one project.

Consequence: Data, auth, functions, or storage are destroyed.
Mitigation: Remove hosting only through an approved dependency review.

Stop if: Any retained service still uses the project.

06Precise timeline

Do the work in this order.

Estimate forOne hosting target with up to 25 functions and retained Firebase backend services

Total elapsed7–15 business days

Active work24–50 hours

BufferAdd time for function rewrites, auth, large data, or multi-site hosting.

Days 1–2Inventory2 days

Days 3–4Static deployment2 days

Days 5–8Rules and backend4 days

Days 9–11Production rehearsal3 days

Days 12–15DNS and observation2–4 days

1
Days 1–2 · inventory
Inventory
6–10 hours active2 days elapsedOwner review waiting
- Inventory hosting and backend dependencies.
- Choose retained and migrated services.
Depends on: Firebase and Cloudflare admins
Stop / go checkpoint
Build?
Go when: Every route and backend is mapped.
Stop when: Critical dependency is unknown.
2
Days 3–4 · static
Static deployment
4–7 hours active2 days elapsedBuilds waiting
- Create Pages project.
- Deploy exact artifact.
- Compare static routes.
Depends on: Inventory
Stop / go checkpoint
Translate?
Go when: Static output matches.
Stop when: Build artifact differs.
3
Days 5–8 · runtime
Rules and backend
9–20 hours active4 days elapsedCode review waiting
- Translate rules and functions.
- Update Auth, SDK, data, storage, and observability settings.
Depends on: Static deploy
Stop / go checkpoint
Rehearse?
Go when: All dynamic scenarios pass.
Stop when: Auth, data, or routing fails.
4
Days 9–11 · rehearse
Production rehearsal
3–7 hours active3 days elapsedPreview validation waiting
- Crawl preview.
- Run login, data, storage, function, and rollback tests.
Depends on: Runtime
Stop / go checkpoint
Cut over?
Go when: Blocking matrix passes.
Stop when: Any critical scenario fails.
5
Days 12–15 · cutover
DNS and observation
2–6 hours active2–4 days elapsedDNS and production signals waiting
- Freeze deploys.
- Switch domain.
- Run production checks and observe.
Depends on: Rehearsal
Stop / go checkpoint
Close rollback?
Go when: All routes and retained services remain stable.
Stop when: Critical traffic or backend regresses.

07The point of change

Cut over with a way back.

Go live

Cutover

Route production hosting to Pages while retained Firebase services continue safely.

Recommended window: A low-traffic morning with hosting and backend owners available.

Freeze Firebase and repository deploys.
Deploy the approved artifact to Pages.
Verify rules, functions, Auth, data, storage, and TLS.
Switch DNS/CNAME.
Run production tests.
Keep Firebase Hosting and project intact.

Proof to capture: Pages serves the canonical domain and every retained backend scenario passes.

Return to safety

Rollback

Restore Firebase Hosting routing.

Deadline: Before removing Firebase Hosting, normally within seven days.

Stop Pages scheduled or write behavior.
Restore DNS to Firebase.
Restore hosting integrations and allowed origins.
Run route and backend tests.
Preserve Pages deployment.

Proof to capture: Firebase again serves the canonical domain with current backend behavior.

Rollback immediately when

Auth failure
Function/rewrite failure
Data or storage access failure
Domain/TLS failure
Critical route regression

08Verification report

Prove the migration worked.

Every blocking check must pass. Capture the evidence before cleanup begins.

ID	Check	Method	Expected result	Evidence
`V-01`Blocking	Build output	Compare route and asset manifests.	Approved parity.	Build report.
`V-02`Blocking	Redirects, headers, rewrites, 404	Run HTTP assertions.	Exact contract.	Route matrix.
`V-03`Blocking	Dynamic handlers	Test success, auth, validation, and failure.	Correct result.	Function log.
`V-04`Blocking	Identity flows	Test sign-in, redirect, recovery, and logout.	All required flows pass.	Auth matrix.
`V-05`Blocking	Database and storage	Run read/write/upload/download scenarios.	Correct authorized behavior.	Data log.
`V-06`Blocking	DNS and TLS	Resolve and inspect.	Pages target and valid TLS.	DNS/TLS output.
`V-07`Blocking	Analytics, App Check, Remote Config	Trigger each retained SDK.	Expected events and policy.	Integration report.
`V-08`Blocking	Hosting rollback	Rehearse DNS and origin restoration.	Meets recovery target.	Rollback log.

09Post-migration cleanup

Remove the scaffolding safely.

Safe after: Seven stable days and all retained Firebase services pass a full operating cycle.

Archive hosting config and evidence.
Revoke obsolete deploy tokens.
Remove old DNS records after rollback window.
Do not delete the Firebase project while any service remains.
Reduce hosting resources only after dependency review.
Schedule quarterly route, auth, data, and recovery checks.

Sources and maintenance

Built to be reviewed.

Tested 2026-07-19. Next scheduled review: 2026-10-19.

Cloudflare: migrate from FirebaseAccessed 2026-07-19
Firebase Hosting configurationAccessed 2026-07-19
Cloudflare Pages redirectsAccessed 2026-07-19

Know the shape of the move.

This timeline assumes

What survives the move.

Where each thing goes.

Make the move recoverable.

Create the source-of-truth backup

Hosting rule translation

Backend boundary map

The things most likely to hurt.

Static pages pass while backend rewrites fail

Auth rejects the new domain

Firebase project is deleted too early

Do the work in this order.

Inventory

Build?

Static deployment

Translate?

Rules and backend

Rehearse?

Production rehearsal

Cut over?

DNS and observation

Close rollback?

Cut over with a way back.

Cutover

Rollback

Prove the migration worked.

Remove the scaffolding safely.

Built to be reviewed.