← All playbooks
Hosting migration

Vercel → Cloudflare Pages

Move a Vercel project to Cloudflare Pages while translating build settings, functions, edge behavior, environment values, domains, redirects, analytics, previews, and a measured rollback.

Typical timeline7–15 business days25–55 hours active work
Statusneeds review
Source testedVercel project settings 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

Vercel

Reasons to stay
  • Exceptional frontend previews and framework integration make releases fast and polished
  • Managed deployments reduce infrastructure and release-management work
Reasons to leave
  • Costs and proprietary platform features can grow rapidly with traffic and complexity
  • 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: Costs and proprietary platform features can grow rapidly with traffic and complexity.

Worst of the move

What you lose: Exceptional frontend previews and framework integration make releases fast and polished. 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
Transfer outcome distributionClean transfer: 1, Partial transfer: 2, Manual rebuild: 5, Not transferred: 2.
Clean1
Partial2
Manual5
Lost2
Mapping route7 of 8 fields have a destination path

This timeline assumes

  • A static or Pages-compatible project with one production domain.
  • Vercel serverless functions are treated as a separate rewrite because Cloudflare's guide says they are not supported directly in Pages.
  • The Git repository remains canonical.
  • Secrets are re-entered and rotated.
  • Vercel stays intact through verification.
02Loss matrix

What survives the move.

“Partial” and “manual” are not footnotes. They are work that must be scheduled and verified.

ItemOutcomeImpactWhat happensMitigation
Static build outputcleancriticalPages can run the build command and publish the output directory.Pin runtime and compare artifacts.
Vercel serverless functionslostcriticalCloudflare's migration guide says these are not directly supported in Pages.Rewrite as Pages Functions, Workers, or an external service.
Edge middleware and edge functionsmanualcriticalRuntime APIs and routing differ.Translate and test every request path.
Environment variables and secretsmanualcriticalValues and environment scope do not transfer.Inventory, rotate, and configure production/preview separately.
Redirects, rewrites, and headerspartialhighvercel.json semantics differ from Pages files and Functions.Translate and test every rule with status and header assertions.
Preview deploymentspartialmediumBoth platforms support previews but URLs, protection, aliases, and hooks differ.Rebuild branch and access policy.
Domains and TLSmanualcriticalDomain association and DNS require cutover.Pre-validate hostname and certificate.
Vercel Analytics, Speed Insights, and logslosthighHistory and product integrations remain at Vercel.Export baselines and choose Cloudflare or external observability.
Image optimizationmanualhighFramework and platform image behavior can differ.Choose a Cloudflare-compatible image path and verify formats/cache.
Cron, storage, queues, and integrationsmanualcriticalPlatform resources require explicit replacements.Map each binding and test its failure path.
03Field and feature mapping

Where each thing goes.

SourceDestinationMethodNotes
Build CommandPages build commandautomaticPin runtime and package manager.
Output DirectoryPages output directoryautomaticVerify artifact root.
Environment variablePages variable/secretmanualSeparate preview and production.
Vercel FunctionPages Function/WorkermanualRewrite runtime APIs.
Redirect/rewrite/header_redirects, _headers, or FunctiontransformTest precedence.
CronWorker cron triggermanualPreserve timezone and idempotency.
Custom domainPages custom domainmanualSwitch DNS after preview passes.
Vercel integrationNo destinationunsupportedInstall Cloudflare-native replacement.
04Before you begin

Make the move recoverable.

Backup procedure

Create the source-of-truth backup

Preserve source, deployment configuration, variables, domains, functions, rules, and operating evidence.

  1. Record build/runtime settings, framework, domains, aliases, variables, functions, middleware, rules, cron, storage, analytics, logs, and integrations.
  2. Export variables names and owners without exposing values.
  3. Download or record the known-good deploy and commit.
  4. Crawl production routes and headers.
  5. Record DNS and rollback values.

Proof to capture: A manifest covers every build setting, route rule, runtime feature, binding, domain, and integration.

Transformation · Pages Functions and Workers

Runtime translation

Replace Vercel-only execution paths.

  1. Inventory functions and middleware.
  2. Map APIs and bindings.
  3. Run unit, integration, and failure tests.

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

Transformation · Crawler and HTTP assertions

Routing contract

Preserve public request behavior.

  1. Translate rules.
  2. Test status, location, headers, and body.
  3. Check precedence and loops.

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 preview hides missing functions

criticalpossible likelihood

Pages load but API paths fail.

Consequence
Production runtime breaks.
Mitigation
Inventory and exercise every dynamic route.

Stop if: Any production function lacks a tested replacement.

Config

Secret scope changes

criticalpossible likelihood

Preview builds can read production secrets.

Consequence
Credential exposure.
Mitigation
Separate environments and rotate values.

Stop if: Any preview can access production-only data.

Routing

Redirect precedence changes

highpossible likelihood

Rules loop, chain, or return wrong content.

Consequence
SEO and application failure.
Mitigation
Test the full route matrix.

Stop if: Any critical route changes status or destination.

06Precise timeline

Do the work in this order.

Estimate forOne project with up to 50 functions and one domain
Total elapsed7–15 business days
Active work25–55 hours
BufferAdd time for Next.js-specific runtime work, databases, or complex middleware.
01
Days 1–2Inventory2 days
02
Days 3–4Static build2 days
03
Days 5–8Runtime and routing4 days
04
Days 9–11Production rehearsal3 days
05
Days 12–15Domain switch2–4 days
  1. Days 1–2 · inventory

    Inventory

    6–10 hours active2 days elapsedOwner review waiting
    • Inventory build, runtime, routing, data, and integrations.
    • Choose replacements.

    Depends on: Vercel and Cloudflare access

    Stop / go checkpoint

    Build?

    Go when: Every runtime feature is mapped.

    Stop when: Critical Vercel-only behavior is unknown.

  2. Days 3–4 · static

    Static build

    4–7 hours active2 days elapsedBuilds waiting
    • Create Pages project.
    • Match build and artifact settings.
    • Compare static output.

    Depends on: Inventory

    Stop / go checkpoint

    Translate?

    Go when: Static routes and assets pass.

    Stop when: Build is nondeterministic.

  3. Days 5–8 · runtime

    Runtime and routing

    10–22 hours active4 days elapsedCode review waiting
    • Rewrite functions and middleware.
    • Configure variables, rules, bindings, and observability.

    Depends on: Static build

    Stop / go checkpoint

    Rehearse?

    Go when: Every dynamic and failure path passes.

    Stop when: Critical behavior differs.

  4. Days 9–11 · rehearse

    Production rehearsal

    3–8 hours active3 days elapsedPreview and DNS waiting
    • Crawl preview.
    • Test performance, security, cron, integrations, and rollback.

    Depends on: Runtime

    Stop / go checkpoint

    Cut over?

    Go when: Route and operational checks pass.

    Stop when: Any blocking check fails.

  5. Days 12–15 · cutover

    Domain switch

    2–8 hours active2–4 days elapsedDNS and observation waiting
    • Freeze deploys.
    • Attach domain and switch DNS.
    • Monitor and verify.

    Depends on: Rehearsal

    Stop / go checkpoint

    Close rollback?

    Go when: Seven days or agreed window is stable.

    Stop when: Critical route, function, or metric regresses.

07The point of change

Cut over with a way back.

Go live

Cutover

Route production to Cloudflare Pages while Vercel remains recoverable.

Recommended window: A low-traffic morning with DNS and runtime owners available.

  1. Freeze Vercel and repository deploys.
  2. Deploy the approved commit to Pages.
  3. Verify variables, functions, rules, bindings, and TLS.
  4. Switch the custom domain.
  5. Run production route and integration tests.
  6. Keep Vercel intact.

Proof to capture: Cloudflare serves the canonical domain and every blocking route/runtime check passes.

Return to safety

Rollback

Restore Vercel routing without losing configuration changes.

Deadline: Before removing the Vercel project, normally within seven days.

  1. Stop Pages-related scheduled writes.
  2. Restore DNS/domain association to Vercel.
  3. Restore integrations and webhooks.
  4. Run the route and runtime suite.
  5. Preserve Cloudflare deployment for analysis.

Proof to capture: Vercel again serves the approved release and all critical routes.

Rollback immediately when
  • Critical function failure
  • Route or header regression
  • Secret exposure
  • Domain/TLS failure
  • Data-binding failure
08Verification report

Prove the migration worked.

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

0%
Interactive report preview0 / 8 checks passed
PassIDCheckMethodExpected resultEvidence
V-01BlockingArtifact parityCompare routes and key asset hashes.Approved output.Build report.
V-02BlockingFunctionsExercise success and failure paths.Correct status, body, and side effect.API log.
V-03BlockingRulesAssert redirects, rewrites, headers, and 404s.Exact contract.Route matrix.
V-04BlockingVariablesAudit environment and scope.Correct least-privilege values.Config audit.
V-05BlockingDNS and TLSResolve and inspect.Cloudflare target and valid cert.DNS/TLS output.
V-06BlockingCron and integrationsTrigger each.One correct execution.Job log.
V-07BlockingLogs and alertsGenerate known events.Signals arrive and alerts fire.Alert evidence.
V-08Critical pagesCompare synthetic results.Within approved thresholds.Performance report.
09Post-migration cleanup

Remove the scaffolding safely.

Safe after: Seven stable days and all scheduled/runtime paths pass.

  1. Archive Vercel settings and evidence.
  2. Revoke obsolete tokens and integrations.
  3. Remove old DNS records.
  4. Keep Vercel project through retention.
  5. Cancel paid resources only after billing review.
  6. Schedule quarterly route and recovery checks.
Sources and maintenance

Built to be reviewed.

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

  1. Cloudflare: migrate from VercelAccessed 2026-07-19
  2. Cloudflare Pages framework guidesAccessed 2026-07-19
  3. Vercel project configurationAccessed 2026-07-19