Heroku → Render
Move Heroku apps, dynos, config vars, Postgres, key-value stores, workers, schedulers, domains, add-ons, release commands, logs, and traffic into Render with a rehearsed data 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
Render
- Straightforward web services, workers, databases, and static sites cover common architectures
- Managed deployments reduce infrastructure and release-management work
- Regional options, platform depth, and scaling controls are less extensive than larger clouds
- Runtime assumptions, platform services, and pricing models shape the architecture
Render: Straightforward web services, workers, databases, and static sites cover common architectures. 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: Regional options, platform depth, and scaling controls are less extensive than larger clouds.
Know the shape of the move.
This timeline assumes
- Up to 10 apps, 10 process types, and 100 GB of Postgres data
- 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.
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 |
|---|---|---|---|---|
| Apps, dynos, workers, and release processes | partial | critical | Render maps Heroku apps to services, dynos to instances, workers to background workers, and release commands to pre-deploy commands. | Create one Render service per process and test release ordering and concurrency. |
| Config vars and secrets | manual | critical | Environment values must be recreated and services do not share them by default. | Use environment groups where appropriate and rotate secrets after verification. |
| Heroku Postgres and key-value data | partial | critical | Data moves through explicit backup, restore, or replication rather than with the app deploy. | Rehearse restore time, final write freeze, counts, extensions, and connection switching. |
| Add-ons, pipelines, logs, and operational history | manual | high | Third-party add-ons may remain external, while platform pipelines and history do not transfer. | Choose replacements and rebuild alerts, log streams, staging, and promotion behavior. |
| Source code and static assets | clean | critical | Repository-owned application code can redeploy when the destination supports the framework and runtime. | Pin versions and compare reproducible build output. |
| Build configuration and dependency cache | partial | critical | Build images, commands, paths, caching, and framework detection differ. | Run clean production and preview builds with no source cache. |
| Environment variables and secrets | manual | critical | Secret values and environment scoping do not transfer with code. | Recreate least-privilege values and rotate them after cutover. |
| Functions, workers, and background jobs | partial | critical | Runtime APIs, regions, limits, concurrency, retries, and scheduling differ. | Port and integration-test every endpoint and job. |
| Databases and durable state | partial | critical | State requires a separate dump, restore, replication, or dual-write plan. | Rehearse consistency, downtime, restore time, checksums, and backups. |
| Object, key-value, and persistent storage | partial | critical | Managed stores and attached disks do not move with the application deployment. | Copy and verify every object, key, volume, and access policy. |
| 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, ordering, matching, and proxy behavior differ. | Create a routing registry and test every rule and status code. |
Where each thing goes.
| Source | Destination | Method | Notes |
|---|---|---|---|
| Heroku project, app, or service | Render project or service | manual | Map topology, runtime, region, and ownership. |
| Build command and output | Destination build configuration | transform | Pin runtime and dependency versions. |
| Environment variable or secret | Destination environment variable or secret | manual | Recreate by environment and rotate. |
| Function, worker, or job | Destination compute unit | transform | Port APIs, limits, retries, and schedules. |
| Database or durable store | Destination data service | transform | Migrate and verify separately from code. |
| Domain and certificate | Destination domain and certificate | manual | Prevalidate before DNS changes. |
| Redirect, rewrite, or header | Destination routing rule | transform | Test precedence, conditions, and status. |
| Preview or staging environment | Destination preview or staging environment | manual | Rebuild branch and access behavior. |
| Log, metric, alert, or analytics stream | Destination observability | 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, environments, domains, routes, functions, stateful services, access, integrations, and recent releases.
- Create application, data, storage, DNS, certificate, and observability inventories.
- Record traffic, error, latency, build, job, and capacity baselines.
- 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.
Runtime and routing manifest
Translate application topology, builds, compute, domains, and rules.
- Inventory source values and exceptions.
- Define explicit destination mappings.
- Reject unmapped critical records.
Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.
State and configuration migration
Move data, objects, secrets, and observability deterministically.
- Normalize encoding, dates, identifiers, and blanks.
- Run a representative pilot.
- Reconcile accepted, rejected, and transformed rows.
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 runtime behavior differs
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.
Both platforms write durable state
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.
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 data, features, users, domains, and integrations.
- Approve scope, owners, mappings, and exclusions.
Depends on: Heroku and Render 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 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 Render and transform representative data.
- Run a pilot containing normal records 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 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 Render the only production system without losing the final Heroku delta.
- Freeze production writes and scheduled actions in Heroku.
- Export, transform, and reconcile the final delta.
- Apply the approved delta to Render.
- Switch domains, forms, integrations, sending, or sync ownership as applicable.
- Run every blocking verification check and keep the source intact.
Proof to capture: Render 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 Render.
- Restore the prior Heroku routing, forms, integrations, sending, or sync ownership.
- Export the Render 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 and jobs | Run every endpoint, queue path, schedule, retry, and timeout. | One correct durable result per test. | 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. | Render 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 Render 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.
Render’s interview with ReadMe infrastructure engineer Ryan Park covers an eight-year Heroku estate moved with about 90 seconds of downtime. The team began with a full service inventory, chose Render-native replacements selectively, left one PostgreSQL-backed service behind for later replacement, and load-tested a proof of concept before the final cutover. The managed-service similarity kept the learning curve low for a small infrastructure team.
- Inventory every service and dependency first, then decide which components should migrate, remain external, or be retired.
- Load-test a production-shaped proof of concept and rehearse the cutover before moving the primary application.
- ReadMe did not force every Heroku component into Render; selective replacement reduced unnecessary migration work.
- A familiar managed-service model helped product engineers remain self-sufficient after the platform change.
Built to be reviewed.
Tested 2026-07-19. Next scheduled review: 2026-10-19.
- Render: migrate from HerokuAccessed 2026-07-19
- Heroku: create a Postgres backupAccessed 2026-07-19
- Render: infrastructure as codeAccessed 2026-07-19