Leaving Heroku: a migration checklist for a small team

Heroku is moving to a "sustaining engineering model" and will not ship new features. If you are the CTO of a small startup running on it, you do not have to leave this month. But if you do leave, the hard part is not the code. It is everything Heroku did for you that you never had to think about.

This post is the checklist for that move: what Heroku does today, where each piece goes on a server you own, and the steps to switch with one short maintenance window.

Disclosure: we build DollarDeploy, a control plane that deploys and operates apps on servers you own. The checklist works with any setup. Where DollarDeploy covers a step, we say so, and where it does not, we say that too.

What changed at Heroku

The news: on February 6, 2026, Heroku announced that it is "transitioning to a sustaining engineering model focused on stability, security, reliability, and support", with the emphasis on maintaining quality "rather than introducing new features".

What did not change: Heroku says there is "no change for customers using Heroku today": same pricing, billing and service. Enterprise Account contracts are no longer offered to new customers.

Why it matters: nothing breaks tomorrow. But a platform without a roadmap is a platform you will leave at some point, and it is easier to plan the move now than during a deadline.

The catch nobody mentions

On Heroku, git push gives you a build, a running process, HTTPS, config vars, logs, a database and a scheduler. Move to a plain server and each of those becomes your job:

• Builds and deploys: someone has to turn a commit into a running process, and keep the previous one to go back to.
• The server itself: security updates, a firewall, a disk that does not fill up.
• HTTPS: certificates that renew on their own.
• Data: a database, and backups you have actually restored.
• Visibility: logs you can search next week, and someone told when a deploy or a job fails.

That list is why "just rent a server" is a trap for a team without a DevOps hire. The fix is to move the platform, not only the app.

Heroku piece by piece

Use this as the map. Left: what you use on Heroku. Right: where it goes on your own server, and what DollarDeploy does for it.

• git push heroku main: deploys from your GitHub repo on every push to a branch you pick. In DollarDeploy you connect the repo once and every push builds and deploys.
• Procfile web: line: the app's start command. DollarDeploy detects common stacks (Node.js, Next.js, Python, Go and more) and fills in the build and start commands; you can override them.
• Procfile release: phase (migrations before the new version starts): the Custom pre start shell command in the app settings. It runs before the app starts, so database migrations go there.
• Worker dynos: a second app from the same repo with its own start command, on the same server.
• Config vars: app env vars. They are stored encrypted, and hidden from teammates without write access to that app.
• Heroku Postgres and Heroku Redis: PostgreSQL and Redis installed on your server with one click, on localhost, next to the app.
• Heroku Scheduler: the app's Cron tab. Each run is a task with logs, retries and a notification when a job starts failing (paid plans).
• Automatic certificates: HTTPS from Let's Encrypt for every app domain, renewed for you.
• Logs: 30 days of app logs and monitoring on every plan.
• Rollback: the Builds table, where Deploy on any earlier build ships it again without rebuilding.
• Team access: roles per team, project, app or server (View, Deploy, Write, Maintain, Admin), so a contractor can deploy one app without touching the server.

The server work Heroku hid from you is covered too: DollarDeploy prepares the server with a firewall and automatic security updates, and Inspect checks 13 areas of it (disk, memory, services, certificates, SSH logins and more) without changing anything.

The migration, step by step

Plan for one maintenance window of 15-60 minutes, depending on the size of your database. Everything before it can happen during the week.

1. Lower your DNS TTL to 5 minutes, two days ahead. The final switch then takes minutes instead of hours.
2. Rent a server close to your users. One server with 2 GB of memory usually runs a small app, its worker and its database. DollarDeploy can create it for you with Hetzner, DigitalOcean, Vultr or AWS (selected regions), or connect any server you already have over SSH.
3. Export your config vars. heroku config -s -a <app> prints them in KEY=value form. Keep the file out of git.
4. Create the app from your GitHub repo and paste the env vars. Then point DATABASE_URL at the new database: DollarDeploy exposes the local PostgreSQL as POSTGRES_URL, and Redis as REDIS_URL.
5. Deploy it on a temporary domain and run through your app with a copy of the data. Fix build differences now, not during the window.
6. Add the cron jobs that Heroku Scheduler ran, and send deploy, cron and backup notifications to the channel your team reads (Slack, Telegram, Discord, email or a webhook).
7. Start the window: heroku maintenance:on, then take a final backup with heroku pg:backups:capture and download it with heroku pg:backups:url.
8. Restore it on the new server with pg_restore. This is the one step that needs SSH, once.
9. Switch DNS to the new server, check the app from outside your network, and keep Heroku running read-only for a few days in case you need to go back.
10. Take a backup and restore it once on the new server. A backup you have not restored is a guess.

Yes, but

You now own a server. DollarDeploy keeps it updated and checked, but capacity is your call: there is no autoscaling across machines. For a small always-on app this rarely matters. For spiky traffic, size the server for the peak, or keep that part where it is.

Some Heroku features have no one-to-one match. Review apps and pipelines do not map directly. The common replacement is a second app that deploys your staging branch.

Cron runs are capped at 60 seconds. Long jobs that ran as one-off dynos should run in your worker instead, with the cron only starting them.

Our honest limit: DollarDeploy does not page anyone when your app is down, so add an external uptime monitor. We are also a small team without a public SLA or status page yet. If you need contractual uptime guarantees, factor that in.

By the numbers

Cost is not the reason to move, but you should know it. A small always-on app with its database on one server in the US or London: $15/mo all-in, DollarDeploy Hobby $5 plus a Vultr 1 vCPU / 2 GB server at $10.

The bottom line

Leaving Heroku is safe when the things Heroku did quietly (deploys, rollback, HTTPS, logs, backups, server updates) move with you. Map them first, rehearse on a temporary domain, and the switch itself is one short window.

Go deeper: Running production without a DevOps hire: a checklist for the first-time CTO and Your first production incident: a runbook for a small team.

Leave Heroku without inheriting its ops. DollarDeploy deploys your apps from GitHub to servers you own and runs the day-to-day work Heroku did for you: builds and one-click rollback, HTTPS, 30 days of logs, PostgreSQL and Redis, cron jobs, backups and server updates. Nothing for you to maintain. Start free on DollarDeploy, no card needed.