← All playbooks
Hosting migration

Vercel → Netlify

Move a Vercel project into Netlify while translating build settings, environments, domains, redirects, headers, functions, edge code, image handling, cron, storage, analytics, previews, and deployment operations.

Typical timeline7–16 business days32–62 hours active work
Statusneeds review
Source testedVercel documentation reviewed 2026-07-19
Destination testedNetlify documentation reviewed 2026-07-19
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

Netlify

What gets better
  • Excellent frontend deployment ergonomics combine previews, forms, functions, and add-ons
  • Managed deployments reduce infrastructure and release-management work
What gets worse
  • Platform-specific services and bandwidth or build costs can become limiting
  • Runtime assumptions, platform services, and pricing models shape the architecture
Best of the move

Netlify: Excellent frontend deployment ergonomics combine previews, forms, functions, and add-ons. 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: Platform-specific services and bandwidth or build costs can become limiting.

01At a glance

Know the shape of the move.

Transfer outcome12 features audited
Transfer outcome distributionClean transfer: 1, Partial transfer: 6, Manual rebuild: 4, Not transferred: 1.
Clean1
Partial6
Manual4
Lost1
Mapping route9 of 9 fields have a destination path

This timeline assumes

  • Up to 20 projects, 100 functions, and 500 routes
  • The application source code and infrastructure dependencies are available for review.
  • A production-shaped destination preview runs before traffic changes.
  • The source stays intact and billable through the rollback window.
  • The migration team records evidence for every blocking verification check.
02Loss matrix

What survives the move.

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

ItemOutcomeImpactWhat happensMitigation
Build and framework behaviorpartialcriticalThe same repository can deploy, but adapters, build commands, output, caching, ISR, and framework defaults differ.Pin versions and compare production and preview builds route by route.
Functions, Edge Functions, Middleware, and cronmanualcriticalRuntime APIs, regions, limits, schedules, and request semantics are platform-specific.Port and integration-test every endpoint, background action, and schedule.
Vercel storage, environment variables, and secretsmanualcriticalManaged stores and scoped environment values do not transfer with source code.Migrate data separately and recreate least-privilege environment configuration.
Deployment history, analytics, previews, domains, and controlslosthighHistorical deployments and reports remain in Vercel while destination access and domain settings start fresh.Export evidence and rehearse domain cutover, preview access, and rollback.
Source code and static assetscleancriticalRepository-owned application code can redeploy when the destination supports the framework and runtime.Pin versions and compare reproducible build output.
Build configuration and dependency cachepartialcriticalBuild images, commands, paths, caching, and framework detection differ.Run clean production and preview builds with no source cache.
Environment variables and secretsmanualcriticalSecret values and environment scoping do not transfer with code.Recreate least-privilege values and rotate them after cutover.
Functions, workers, and background jobspartialcriticalRuntime APIs, regions, limits, concurrency, retries, and scheduling differ.Port and integration-test every endpoint and job.
Databases and durable statepartialcriticalState requires a separate dump, restore, replication, or dual-write plan.Rehearse consistency, downtime, restore time, checksums, and backups.
Object, key-value, and persistent storagepartialcriticalManaged stores and attached disks do not move with the application deployment.Copy and verify every object, key, volume, and access policy.
Domains, DNS, and TLSmanualcriticalCustom domains and certificate ownership require destination validation and DNS changes.Lower TTL, prevalidate domains, and retain exact rollback records.
Redirects, rewrites, headers, and routingpartialcriticalRule syntax, ordering, matching, and proxy behavior differ.Create a routing registry and test every rule and status code.
03Field and feature mapping

Where each thing goes.

SourceDestinationMethodNotes
Vercel project, app, or serviceNetlify project or servicemanualMap topology, runtime, region, and ownership.
Build command and outputDestination build configurationtransformPin runtime and dependency versions.
Environment variable or secretDestination environment variable or secretmanualRecreate by environment and rotate.
Function, worker, or jobDestination compute unittransformPort APIs, limits, retries, and schedules.
Database or durable storeDestination data servicetransformMigrate and verify separately from code.
Domain and certificateDestination domain and certificatemanualPrevalidate before DNS changes.
Redirect, rewrite, or headerDestination routing ruletransformTest precedence, conditions, and status.
Preview or staging environmentDestination preview or staging environmentmanualRebuild branch and access behavior.
Log, metric, alert, or analytics streamDestination observabilitymanualReset history after exporting baselines.
04Before you begin

Make the move recoverable.

Backup procedure

Create the source-of-truth backup

Preserve Vercel data, configuration, and operating evidence before any destination write.

  1. Export Vercel build settings, environments, domains, routes, functions, stateful services, access, integrations, and recent releases.
  2. Create application, data, storage, DNS, certificate, and observability inventories.
  3. Record traffic, error, latency, build, job, and capacity baselines.
  4. Preserve the last known-good release and hash all exports.

Proof to capture: A signed manifest reconciles every scoped record class, runtime dependency, export file, count, and hash.

Transformation · Infrastructure manifest and route tester

Runtime and routing manifest

Translate application topology, builds, compute, domains, and rules.

  1. Inventory source values and exceptions.
  2. Define explicit destination mappings.
  3. Reject unmapped critical records.

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

Transformation · Provider tools, checksums, and restore scripts

State and configuration migration

Move data, objects, secrets, and observability deterministically.

  1. Normalize encoding, dates, identifiers, and blanks.
  2. Run a representative pilot.
  3. Reconcile accepted, rejected, and transformed rows.

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

The app builds but runtime behavior differs

criticalpossible likelihood

Routes render while functions, jobs, state, caching, or retries behave differently.

Consequence
Users lose data or critical actions.
Mitigation
Test complete business paths under production-shaped load.

Stop if: Any critical path lacks durable evidence.

Cutover

Both platforms write durable state

criticalpossible likelihood

Source and destination workers, schedules, or web traffic modify the same data.

Consequence
State diverges or actions duplicate.
Mitigation
Freeze source writers and transfer one owner at a time.

Stop if: An unapproved source writer remains active.

Domain

DNS rollback is unavailable

criticalpossible likelihood

Certificates, proxy settings, or DNS records cannot return traffic quickly.

Consequence
An outage outlives the application fix.
Mitigation
Prevalidate both directions and preserve exact prior records.

Stop if: Rollback cannot be completed within the approved objective.

06Precise timeline

Do the work in this order.

Estimate forUp to 20 projects, 100 functions, and 500 routes
Total elapsed7–16 business days
Active work32–62 hours
BufferAdd time for Next.js edge behavior, ISR, Vercel storage, AI SDK workloads, complex routing, or many domains.
01
Days 1–3Inventory and decisions2–3 days
02
Days 3–5Backup and reconcile1–3 days
03
Days 5–12Map and pilot3–8 days
04
Days 10–20Final delta and switch1–5 days
05
Days 12–40Observe and close3–10 days
  1. Days 1–3 · inventory

    Inventory and decisions

    6–12 hours active2–3 days elapsedOwner review waiting
    • Inventory Vercel data, features, users, domains, and integrations.
    • Approve scope, owners, mappings, and exclusions.

    Depends on: Vercel and Netlify administrator access

    Stop / go checkpoint

    Export?

    Go when: Every critical item has an owner and disposition.

    Stop when: Consent, billing, access, or system ownership is unclear.

  2. 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 checkpoint

    Transform?

    Go when: Source totals and export manifests agree.

    Stop when: Any critical dataset or configuration is absent.

  3. Days 5–12 · pilot

    Map and pilot

    10–35 hours active3–8 days elapsedDestination processing and review waiting
    • Configure Netlify and transform representative data.
    • Run a pilot containing normal records and every critical edge case.

    Depends on: Verified backup

    Stop / go checkpoint

    Scale?

    Go when: Pilot mappings, behavior, access, and evidence pass.

    Stop when: Any critical check fails or produces unexplained variance.

  4. Days 10–20 · cutover

    Final delta and switch

    5–25 hours active1–5 days elapsedDNS, import, or sync propagation waiting
    • Freeze production writes in Vercel.
    • Apply the final delta, switch ownership, and run blocking checks.

    Depends on: Passed pilot and approved rollback

    Stop / go checkpoint

    Open production?

    Go when: Counts reconcile and one destination system owns production.

    Stop when: A source writer remains active or a blocking check fails.

  5. 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 checkpoint

    Close rollback?

    Go when: No trigger occurs during the agreed observation period.

    Stop when: Data, access, delivery, routing, or business results regress.

07The point of change

Cut over with a way back.

Go live

Cutover

Make Netlify the only production system without losing the final Vercel delta.

Recommended window: A low-volume weekday morning with platform, data, DNS, and business owners available.

  1. Freeze production writes and scheduled actions in Vercel.
  2. Export, transform, and reconcile the final delta.
  3. Apply the approved delta to Netlify.
  4. Switch domains, forms, integrations, sending, or sync ownership as applicable.
  5. Run every blocking verification check and keep the source intact.

Proof to capture: Netlify owns production, totals reconcile, and every blocking check has durable evidence.

Return to safety

Rollback

Return production ownership to Vercel without losing destination-era changes.

Deadline: Within seven days and before source data, plans, credentials, domains, or billing are changed.

  1. Stop new writes and scheduled actions in Netlify.
  2. Restore the prior Vercel routing, forms, integrations, sending, or sync ownership.
  3. Export the Netlify post-cutover delta.
  4. Review and apply safe destination-era changes to Vercel.
  5. Run the same blocking checks against the restored source.

Proof to capture: Vercel again owns production with current data and no duplicate destination action.

Rollback immediately when
  • 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
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-01BlockingReproducible releaseBuild a pinned source revision from a clean environment.Output and dependency versions match acceptance.Build log and artifact hash.
V-02BlockingHTTP behaviorCrawl routes, redirects, rewrites, headers, errors, and assets.Approved status, body, and header parity.Route diff.
V-03BlockingFunctions and jobsRun every endpoint, queue path, schedule, retry, and timeout.One correct durable result per test.Runtime log.
V-04BlockingData and storage reconciliationCompare counts, checksums, invariants, and backup restore.Every scoped item is accounted for and recoverable.State report.
V-05BlockingSecrets and accessTest representative users, services, previews, and production actions.Least privilege with no secret exposure.Access evidence.
V-06BlockingDNS, TLS, and rollbackResolve from multiple networks and exercise rollback records.Valid TLS and routing within approved objectives.DNS and certificate report.
V-07BlockingLogs, metrics, traces, and alertsGenerate known failures and load.Signals arrive with correct context and thresholds.Observability evidence.
V-08BlockingSingle production platformInspect traffic, writers, jobs, webhooks, and deployment triggers.Netlify alone owns production.Ownership checklist.
09Post-migration cleanup

Remove the scaffolding safely.

Safe after: One complete operating cycle, at least seven stable days, and owner sign-off on every blocking check.

  1. Create final Vercel exports and archive verification evidence.
  2. Revoke temporary credentials, API keys, webhooks, and elevated roles.
  3. Remove obsolete embeds, forms, jobs, integrations, and DNS records.
  4. Keep the source intact through the approved retention window.
  5. Cancel paid plans only after billing, legal, and recovery review.
  6. Schedule the next Netlify backup, access, and migration-playbook review.
Sources and maintenance

Built to be reviewed.

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

  1. Netlify: deploy from a repositoryAccessed 2026-07-19
  2. Netlify: framework integrationsAccessed 2026-07-19
  3. Vercel: project configurationAccessed 2026-07-19