Heroku → Vercel
Move Heroku web dynos, config vars, Postgres, workers, schedulers, release commands, add-ons, domains, and traffic into Vercel Functions without treating a git deploy as a complete cutover.
Should you make this move?
Both platforms have a case. Compare what you gain with what you give up before scheduling the cutover.
Heroku
- Git-based deploys, buildpacks, and add-ons offer an exceptionally approachable platform
- Managed deployments reduce infrastructure and release-management work
- Pricing and infrastructure control become limiting as applications grow
- Runtime assumptions, platform services, and pricing models shape the architecture
Vercel
- Exceptional frontend previews and framework integration make releases fast and polished
- Managed deployments reduce infrastructure and release-management work
- Costs and proprietary platform features can grow rapidly with traffic and complexity
- Runtime assumptions, platform services, and pricing models shape the architecture
Vercel: Exceptional frontend previews and framework integration make releases fast and polished. This removes a major source-side concern: Pricing and infrastructure control become limiting as applications grow.
What you lose: Git-based deploys, buildpacks, and add-ons offer an exceptionally approachable platform. What you inherit: Costs and proprietary platform features can grow rapidly with traffic and complexity.
Jump to a section
Know the shape of the move.
This timeline assumes
- Up to 10 apps, 10 process types, and 100 GB of Postgres data
- Web traffic can run on Vercel Functions, while long-running workers and persistent connections have an approved replacement.
- A production-shaped Vercel Preview runs before traffic changes.
- The Heroku app stays intact and billable through the rollback window.
- The migration team records evidence for every blocking verification check.
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 |
|---|---|---|---|---|
| Procfile web process and dynos | partial | critical | Vercel does not read a Procfile. The web process becomes Functions, and Vercel documents duration and 4.5 MB body limits that Heroku dynos do not share. | Map every route to a function, pin the runtime, and test timeouts, streaming, and payload size against the documented limits. |
| Worker dynos and long-running processes | manual | critical | Vercel’s Heroku guide maps Celery-style workers to Queues. A process that must stay running does not transfer with the web deploy. | Inventory every worker and choose a queue, cron route, or separate host before cutover. |
| Release commands and Heroku Scheduler | manual | critical | Heroku runs release commands before a release goes live and can block a bad deploy. Vercel does not read those Procfile entries. Scheduler jobs become Cron Jobs. | Move migrations into CI before promotion and recreate every schedule as a cron route with a freeze plan. |
| Config vars and secrets | manual | critical | Environment values must be recreated per Vercel environment. Preview and production do not share them automatically. | Recreate least-privilege values, scope them by environment, and rotate secrets after verification. |
| Heroku Postgres and key-value data | partial | critical | Data moves through an explicit backup, restore, or replication. Serverless functions also handle connections differently than persistent dynos. | Restore into a destination database, rehearse connection pooling, and verify counts before switching writers. |
| Buildpacks, Aptfile packages, and local disk | partial | high | Extra buildpacks and system packages need a matching Vercel runtime or a container image. Ephemeral function filesystems do not replace attached disks. | List every system dependency and move uploads or caches to an external store. |
| Add-ons, pipelines, logs, and operational history | manual | high | Third-party add-ons may remain external. Heroku pipelines and log history do not become Vercel observability. | Choose replacements and rebuild alerts, log drains, Preview promotion, and baselines. |
| Source code and static assets | clean | critical | Repository-owned application code can redeploy when the destination runtime supports the framework. | Pin versions and compare reproducible build output. |
| Sessions, uploads, and in-process state | lost | critical | Vercel’s guide asks whether sessions and uploads can live outside the application process. In-memory dyno state does not survive a function invocation. | Move session and upload state to an external store and test login, payment, and file paths. |
| WebSockets and persistent connections | partial | high | Vercel documents Python WebSocket support as beta and subject to function duration limits, so clients need reconnection. | Prove reconnection and idle behavior, or keep the socket path on a host that supports long connections. |
| Domains, DNS, and TLS | manual | critical | Custom domains and certificate ownership require destination validation and DNS changes. | Lower TTL, prevalidate domains, and retain exact rollback records. |
| Redirects, rewrites, headers, and routing | partial | critical | Rule syntax, Preview routing, and incremental rewrites to the legacy host differ from Heroku routers. | Create a routing registry and test every rule, status code, and fallback to Heroku. |
Where each thing goes.
| Source | Destination | Method | Notes |
|---|---|---|---|
| Heroku app or Procfile web process | Vercel project or Function | transform | Drop the Procfile web entry and pin the runtime. |
| Worker dyno or Celery process | Vercel Queue, cron route, or separate host | manual | Do not leave a source worker writing after web cutover. |
| Release command | CI release pipeline | manual | Fail the promotion if migrations fail. |
| Heroku Scheduler job | Vercel Cron Job | transform | Test cadence and disable the source schedule first. |
| Config var or secret | Vercel environment variable | manual | Recreate by Preview and Production, then rotate. |
| Heroku Postgres or key-value store | Destination data service | transform | Migrate and verify separately from the app deploy. |
| Domain and certificate | Vercel domain and certificate | manual | Prevalidate before DNS changes. |
| Redirect, rewrite, or header | Vercel routing rule | transform | Test precedence, Preview behavior, and status. |
| Log, metric, or add-on stream | Vercel observability or replacement service | manual | Reset history after exporting baselines. |
Make the move recoverable.
Create the source-of-truth backup
Preserve Heroku data, configuration, and operating evidence before any destination write.
- Export Heroku build settings, Procfile processes, config vars, domains, add-ons, release commands, schedulers, and recent releases.
- Create application, Postgres, key-value, DNS, certificate, and observability inventories.
- Record traffic, error, latency, build, job, and capacity baselines.
- Take a native Heroku Postgres backup and hash all exports.
Proof to capture: A signed manifest reconciles every scoped record class, runtime dependency, export file, count, and hash.
Runtime and process map
Translate web processes, workers, schedules, and release gates onto Functions and CI.
- List every Procfile entry, scheduler, and add-on.
- Assign a Function, Queue, cron, CI job, or exclusion.
- Reject any critical process without a destination owner.
Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.
State and configuration migration
Move Postgres, objects, secrets, and observability without relying on the app deploy.
- Restore a rehearsal database and compare counts.
- Recreate environment values by Preview and Production.
- Reconcile accepted, rejected, and transformed records.
Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.
The things most likely to hurt.
These are operating limits. Treat every “Stop if” condition as a blocked migration, not a suggestion.
The app builds but function limits change behavior
Routes render while timeouts, body size, connection pooling, or retries differ from dynos.
- Consequence
- Users lose data or critical actions fail after a few seconds.
- Mitigation
- Test complete business paths against documented duration and payload limits.
Stop if: Any critical path lacks durable evidence under production-shaped load.
A Heroku worker keeps writing after web traffic moves
Scheduler jobs or worker dynos still mutate the shared database.
- 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.
DNS rollback is unavailable
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.
Do the work in this order.
- Days 1–3 · inventory
Inventory and decisions
6–12 hours active2–3 days elapsedOwner review waiting- Inventory Heroku processes, add-ons, data, users, domains, and integrations.
- Approve which work stays on Vercel and which needs another host.
Depends on: Heroku and Vercel administrator access
Stop / go checkpointExport?
Go when: Every critical item has an owner and disposition.
Stop when: Consent, billing, access, or system ownership is unclear.
- Days 3–5 · backup
Backup and reconcile
5–10 hours active1–3 days elapsedExport processing waiting- Create immutable exports, Postgres backups, and configuration evidence.
- Reconcile counts, totals, and hashes.
Depends on: Approved inventory
Stop / go checkpointTransform?
Go when: Source totals and export manifests agree.
Stop when: Any critical dataset or configuration is absent.
- Days 5–12 · pilot
Map and pilot
10–35 hours active3–8 days elapsedDestination processing and review waiting- Configure the Vercel project and restore representative data.
- Run a Preview containing normal traffic and every critical edge case.
Depends on: Verified backup
Stop / go checkpointScale?
Go when: Pilot mappings, behavior, access, and evidence pass.
Stop when: Any critical check fails or produces unexplained variance.
- Days 10–20 · cutover
Final delta and switch
5–25 hours active1–5 days elapsedDNS, import, or sync propagation waiting- Freeze production writes and schedulers in Heroku.
- Apply the final delta, switch ownership, and run blocking checks.
Depends on: Passed pilot and approved rollback
Stop / go checkpointOpen production?
Go when: Counts reconcile and one destination system owns production.
Stop when: A source writer remains active or a blocking check fails.
- 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 checkpointClose rollback?
Go when: No trigger occurs during the agreed observation period.
Stop when: Data, access, delivery, routing, or business results regress.
Cut over with a way back.
Cutover
Make Vercel the only production system without losing the final Heroku delta.
- Freeze production writes, workers, and scheduled actions in Heroku.
- Export, restore, and reconcile the final data delta.
- Promote the approved Vercel Production deployment.
- Switch domains, callbacks, integrations, or incremental rewrites as applicable.
- Run every blocking verification check and keep Heroku intact.
Proof to capture: Vercel owns production, totals reconcile, and every blocking check has durable evidence.
Rollback
Return production ownership to Heroku without losing destination-era changes.
- Stop new writes and scheduled actions in Vercel.
- Restore the prior Heroku routing, workers, integrations, and DNS records.
- Export the Vercel post-cutover delta.
- Review and apply safe destination-era changes to Heroku.
- Run the same blocking checks against the restored source.
Proof to capture: Heroku again owns production with current data and no duplicate destination action.
- 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
Prove the migration worked.
Every blocking check must pass. Capture the evidence before cleanup begins.
| Pass | ID | Check | Method | Expected result | Evidence |
|---|---|---|---|---|---|
V-01Blocking | Reproducible release | Build a pinned source revision from a clean environment. | Output and dependency versions match acceptance. | Build log and artifact hash. | |
V-02Blocking | HTTP behavior | Crawl routes, redirects, rewrites, headers, errors, and assets. | Approved status, body, and header parity. | Route diff. | |
V-03Blocking | Functions, jobs, and limits | Run every endpoint, queue path, schedule, retry, timeout, and oversized payload. | One correct durable result within documented limits. | Runtime log. | |
V-04Blocking | Data and storage reconciliation | Compare counts, checksums, invariants, and backup restore. | Every scoped item is accounted for and recoverable. | State report. | |
V-05Blocking | Secrets and access | Test representative users, services, Previews, and production actions. | Least privilege with no secret exposure. | Access evidence. | |
V-06Blocking | DNS, TLS, and rollback | Resolve from multiple networks and exercise rollback records. | Valid TLS and routing within approved objectives. | DNS and certificate report. | |
V-07Blocking | Logs, metrics, traces, and alerts | Generate known failures and load. | Signals arrive with correct context and thresholds. | Observability evidence. | |
V-08Blocking | Single production platform | Inspect traffic, writers, jobs, webhooks, and deployment triggers. | Vercel alone owns production. | Ownership checklist. |
Remove the scaffolding safely.
Safe after: One complete operating cycle, at least seven stable days, and owner sign-off on every blocking check.
- Create final Heroku exports and archive verification evidence.
- Revoke temporary credentials, API keys, webhooks, and elevated roles.
- Remove obsolete embeds, forms, jobs, integrations, and DNS records.
- Keep the source intact through the approved retention window.
- Cancel paid plans only after billing, legal, and recovery review.
- Schedule the next Vercel backup, access, and migration-playbook review.
When the plan met reality.
First-hand accounts are preferred. Vendor case studies are labeled, and every note below is an editorial paraphrase—follow the link for the full context.
After Heroku announced the end of its free plan in August 2022, morishin rewrote a five-year-old Rails and Heroku Postgres app as Next.js on Vercel with Prisma, tRPC, and PlanetScale. Cross-region SQL made TTFB slow until both app and database sat in Tokyo, and full SSR stayed expensive, so the main pages moved to on-demand ISR. The rewrite gained typed APIs and hybrid rendering, and lost Rails-style background jobs such as perform_later.
- Treat a Heroku-to-Vercel move as a process and data-store redesign, not only a git remote change, especially when the app uses Postgres, Redis, or async jobs.
- Measure TTFB with the database in the same region, and decide which routes need SSR before you cut public traffic.
- Keeping Rails on a free-tier host was the first search, and the Vercel path only appeared after that option closed.
- Vercel image optimization hit the free quota quickly, so image handling needed a separate plan from the app deploy.
Andrew VanDyke moved a set of portfolio demos off Heroku after the free tier ended. Hosting fell from more than eighty dollars a month to about fifteen. A written inventory of URLs, repos, secrets, databases, and the first visitor action showed that some apps belonged on Vercel and others needed a long-running or scheduled host. Build success was not enough. Clicking each live demo caught missing settings and stale OAuth callback URLs.
- List every app’s URL, secrets, datastore, and first visitor action before you move code, then decide which work does not belong on Functions.
- After deploy, click the public path a stranger would use, including login and payment return URLs, instead of trusting a green build.
- Scheduled collectors and long-running work stayed off Vercel, while the public pages moved.
- The cost drop mattered, but broken demo links would have hurt the portfolio more than the Heroku bill.
Verify against the primary material.
Platform behavior changes. Check these sources and the review dates above before executing a production migration.
- Vercel: migrate a Python API from HerokuAccessed 2026-10-23
- Heroku: create a Postgres backupAccessed 2026-10-23
- Vercel: incremental migrationAccessed 2026-10-23