Moving Off Heroku: What the Migration Really Costs, How Long It Takes, and How to Cut Over With Under Five Minutes of Downtime

A Heroku migration for one production app with a database, background workers and a handful of add-ons costs $4,000 to $18,000 in engineering time and takes three to eight weeks of calendar time. The cutover itself — the part everyone is actually nervous about — is two to five minutes of frozen writes if you move Postgres with logical replication, and anywhere from thirty minutes to several hours if you move it with pg_dump. Everything else in this post is detail on those two numbers: where the money goes, where the weeks go, and which decisions change them.

This is a vendor-neutral runbook. We do this work under cloud infrastructure, so we have an obvious interest, and we will tell you plainly in the last section when the right answer is to stay on Heroku and spend the money on product instead.

The short answer: $4,000-$18,000, three to eight weeks, two to five minutes down

A single production app — web processes, one or two background workers, Postgres, Redis, a few add-ons — is a $4,000-$9,000 project at the small end and $12,000-$18,000 when there are six or more processes, queues that cannot lose messages, or a compliance requirement attached. Calendar time is three to eight weeks, of which roughly one week is inventory, two to four weeks is building and running the new stack in parallel, one evening is the cutover, and 72 hours is the watch window nobody budgets for and everybody needs.

What moves you inside that range is not the language or the framework. It is four things: how many processes run outside the main web app, whether anyone can still explain the config vars, whether the database has pinned extensions or a non-default collation, and whether you need a compliance story at the end. A Rails app with three processes and a clean Procfile is the cheap end. A Django monolith with eleven config vars nobody recognizes, a cron job that emails finance, and a PDF library that needs system packages is the expensive end.

Heroku's 2026 price list, line by line

Heroku's published 2026 dyno prices are $5/month for Eco, $7 for Basic, $25 for Standard-1X, $50 for Standard-2X, $250 for Performance-M and $500 for Performance-L, each per dyno per month. Postgres starts at $5/month for Essential-0 and jumps to $50/month for Standard-0, the first plan Heroku describes as production-grade. These are list prices as of September 2026 and Heroku prorates most of them to the second, so treat them as monthly ceilings rather than guaranteed charges.

The real trigger is rarely the dynos — it is Postgres and the add-on stack

Most teams who call us about leaving Heroku are not annoyed about dyno prices. They are stuck on a database ladder. Postgres Essential-2 is $20/month and the next rung, Standard-0, is $50/month — and crossing it is not a slider, it is a plan change with a maintenance window. Above that the ladder keeps climbing in steps that do not map to how much database you actually need, and Essential plans have no in-place upgrade path at all.

The second trigger is the add-on bill. Nobody decides to spend $180/month on Heroku; they add a logging add-on, a Redis instance, a scheduler, an error tracker and a metrics dashboard over three years and then read the invoice. The classic moment of clarity is discovering that the add-ons cost more than the dynos.

• Database ceilings. You need a bigger instance, more connections, a read replica, or a Postgres extension Heroku does not ship.
• Add-on sprawl. Four to eight add-ons whose combined cost exceeds the compute bill.
• Compliance. A customer asks for a VPC diagram, data residency, audit logs, or a signed BAA and the platform answer is a support ticket.
• Network isolation. You need private networking to a service that is not on Heroku, and Private Spaces pricing is a large step up.
• Consolidation. Half your stack is already on AWS and you are paying two vendors to run one product.
• The bus factor. The person who set up Heroku has left and nobody can safely change anything.

The same app priced both ways

A three-process app with Postgres and Redis costs roughly $130-$160/month on Heroku and roughly $75-$160/month on AWS depending on how lean you build it — which means at this size migrating purely to save money is not worth it. The table below prices the same workload three ways at September 2026 US East list prices. AWS Fargate is billed around $0.04048 per vCPU-hour and $0.004445 per GB-hour; we have rounded the monthly figures.

Where the gap actually opens: Performance tier

The savings case becomes real above Standard dynos, where Heroku's per-dyno price stops tracking the underlying compute. A Performance-M dyno at $250/month buys 2.5 GB of RAM; comparable Fargate capacity at 2 vCPU and 4 GB is roughly $72/month on demand and around $50 with a one-year Compute Savings Plan. That is where the commonly quoted 50-80% reductions come from — not from the small app.

Read that table as a decision rule, not a promise. At Basic and Standard-1X, AWS is a rounding error cheaper and considerably more work. At Performance-M and above, you are paying Heroku a two-to-five-times premium for operational convenience, and at that point the convenience has to be worth roughly $180-$380 per process per month to justify staying.

Where to land: AWS vs Render vs Fly.io vs Railway vs DigitalOcean

AWS is not automatically the destination. For a team of one to five engineers with no platform specialist, Render and Fly.io are the closest like-for-like replacements for Heroku — git-push deploys, managed Postgres, background workers and cron, without a VPC to design. The cost advantage of AWS only outweighs its operational cost once you have real scale or a compliance requirement.

One honest note on lock-in: moving Heroku to Render or Fly.io is largely a Dockerfile and a database move, and you can do it again later for a fraction of the cost. Moving Heroku to a full AWS build with Terraform, IAM roles and CI pipelines is a bigger investment that is much harder to unwind. If you are not sure you will still want this architecture in three years, take the cheaper, more reversible step first.

The honest rule: under $300/month go managed, over $1,000/month go AWS

Use your current monthly Heroku invoice as the deciding number. Under about $300/month, a migration cannot pay for itself in infrastructure savings within a reasonable horizon, so only move if you have a non-cost reason. Between $300 and $1,000/month, move to Render or Fly.io — you capture most of the saving for a fraction of the effort. Above roughly $1,000/month, or under any real compliance requirement, AWS starts to earn its complexity.

1. 1Under $300/month, no compliance pressure: stay, or move to Render if you are hitting a specific Heroku ceiling. The engineering time is worth more spent on the product.
2. 2$300-$1,000/month: move to a managed PaaS. Expect a 30-50% bill reduction and a one-to-three-week project instead of a six-week one.
3. 3Over $1,000/month: AWS or GCP. The compute savings alone justify the build, and reserved capacity or Savings Plans widen the gap by a further 25-40%.
4. 4Any hard compliance requirement — VPC isolation, data residency, audit trails, a signed agreement your platform will not sign: go to a cloud you control, at any spend level. This is a security decision, not a cost one, and it usually pairs with a security review.

The nine-step runbook we use

Every migration we run follows the same nine steps in the same order, because the order is what keeps the downtime short. Inventory before infrastructure, parallel-run before cutover, and the database moves by replication rather than by dump. Steps one through three usually take a week, four through six take one to three weeks, and seven through nine happen in a single evening plus the following 72 hours.

Steps 1-3: why the inventory is the deliverable

The inventory phase is the one clients most want to skip and the one that most reliably saves money. Half the migrations we see quoted badly are quoted badly because nobody counted the scheduled jobs. If the original developer is gone, run the inventory as a standalone paid piece of work and stop there if the numbers do not justify continuing — you still own a document that tells you exactly what your product depends on, which is worth having whether or not you migrate.

Steps 4-6: logical replication, not pg_dump

Logical replication is the single decision that separates a five-minute cutover from a five-hour one. With pg_dump and pg_restore, the database is frozen for as long as the dump, the transfer and the restore take — roughly thirty minutes for a few gigabytes and several hours once you are into the tens of gigabytes, plus index rebuild time. With logical replication, the copy happens while the old database is still serving traffic, and the cutover is only the time it takes for the last transactions to drain.

Steps 7-9: the cutover evening

The cutover runs in a fixed order and takes under five minutes when the preparation is done. Enable maintenance mode on Heroku so writes stop. Watch replication lag until it reaches zero. Advance every sequence on the target past its current maximum. Run a short read-only smoke test against the new stack. Repoint DNS. Disable maintenance mode. Then leave the old stack running, untouched and paid for, until the watch window closes — deleting Heroku early to save $150 is how a recoverable incident becomes an unrecoverable one.

Replacing Heroku's invisible work

The hidden cost of leaving Heroku is not compute, it is the dozen small things the platform did that nobody wrote down: review apps, log drains, the scheduler, automated backups, certificate renewal, one-off shells and one-command rollback. Budget three to six engineering days to rebuild them, and expect $10-$80/month of tooling to come back on the bill.

That last row is the honest one. Heroku's price includes an operations team you never meet. When you leave, that responsibility becomes yours or your agency's, and it does not show up in any cost comparison table — including ours.

CI/CD for a one-to-five person team

Replacing git push heroku main takes about a day and one GitHub Actions workflow: build the image, push it to ECR, force a new ECS deployment, and wait for the service to stabilize. Use OIDC to assume an AWS role rather than storing long-lived access keys as repository secrets — leaked CI credentials are one of the most common ways small teams get compromised after a migration.

name: deploy
on:
  push:
    branches: [main]

jobs:
  ship:
    runs-on: ubuntu-latest
    permissions:
      id-token: write   # OIDC into AWS — no long-lived keys in secrets
      contents: read
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::${{ secrets.AWS_ACCOUNT_ID }}:role/gha-deploy
          aws-region: us-east-1
      - run: |
          docker build -t $ECR_URI:$GITHUB_SHA .
          docker push $ECR_URI:$GITHUB_SHA
      - run: aws ecs update-service --cluster prod --service web --force-new-deployment
      - run: aws ecs wait services-stable --cluster prod --services web

Four rules make this pipeline safe for a small team. Tag images with the commit SHA and never with latest, so a rollback is a known-good tag rather than a rebuild. Run database migrations as a separate ECS task before the deployment, not in the container entrypoint. Use ECS rolling deployments with a health check so a broken image never fully replaces a working one. And make aws ecs wait services-stable the last step, so a red build means a failed deploy instead of a silent one.

Uptime after the move: what each nine actually costs

99.9% uptime means 43 minutes and 12 seconds of allowed downtime per month, and for a normal web app it costs roughly $40-$120/month more than a single-task setup — two tasks across two availability zones, health checks, automated backups and alerting that reaches a human. Every additional nine after that costs multiples more, and the fourth nine is a staffing decision rather than an infrastructure one.

Two things worth saying out loud. First, a cloud provider's own SLA credit does not make your customers whole — it refunds a fraction of your bill, so buy availability because you need it, not because a document promises it. Second, most teams that say they need four nines actually need three nines plus a status page and an incident process, which costs an order of magnitude less.

The six things that break every time

Across migrations, the same six failures recur, and none of them appear during the cutover itself — they surface in the following 72 hours. Check each one explicitly during the parallel-run week.

1. 1Background workers process nothing. The queue driver, the Redis URL format or the TLS setting differs, and the worker connects to the wrong place or silently idles. Verify by draining a real queue in staging, not by checking that the process is running.
2. 2File uploads vanish. Code writing to local disk worked on Heroku for the life of one dyno and now fails differently. Everything user-uploaded has to be on S3 before cutover, and old files have to be copied and re-pointed.
3. 3A Postgres extension or collation is missing. pgcrypto, postgis, pg_trgm, or a citext column behaving differently because the target has a different collation. Compare extension lists and the ordering of a text index before you subscribe.
4. 4Timezones move. Heroku dynos run UTC. If a scheduled job or a report assumed that and the new container inherits a different TZ, month-end numbers change quietly. Pin TZ=UTC explicitly in the task definition.
5. 5Hardcoded Heroku environment variables. DYNO, HEROKU_APP_NAME, HEROKU_SLUG_COMMIT and PORT assumptions are scattered through most mature Heroku codebases. Grep for HEROKU_ before you build the image.
6. 6Certificates do not renew. Heroku renewed them for you. If the ALB certificate is not in ACM with DNS validation on a zone you control, you will find out 90 days later, at the worst possible hour.

Total cost of ownership and the break-even month

Total cost is the agency or engineering fee plus internal hours plus two to four weeks of running both stacks, and it only pays back through monthly savings if your Heroku bill is large enough. For a small app saving $40-$90/month against a $4,000-$9,000 project, the break-even is past three years — which is to say there is no cost case, only a capability case. For a team spending over $500/month, six to fourteen months is realistic.

When you should not leave Heroku

Stay on Heroku if your bill is under about $300/month, you have no compliance requirement, and nobody on your team wants to own infrastructure. At that size the migration costs more than several years of savings, and the engineering weeks are worth far more spent on the product. We turn this project down more often than we take it.

• You are pre-product-market-fit. Six weeks of platform work while you are still changing the product weekly is the wrong trade at any bill size.
• Nobody will own the pager. If there is no plan for who gets woken at 3am, Heroku's operations team is a bargain and you should keep buying it.
• Your bill is under $300/month and stable. The arithmetic does not work. Revisit when you cross Standard-2X or add a second database.
• You are mid-fundraise or mid-launch. Cutovers need a quiet fortnight either side. Do it after, not during.
• The real problem is the application, not the platform. If the app is slow because of N+1 queries and missing indexes, moving it to AWS makes it a slow app on AWS. Fix that first — often as a web development engagement — and the infrastructure question may disappear.

If none of those apply, the decision is straightforward: price your current stack honestly, pick the destination by the $300 and $1,000 thresholds, and run the nine steps in order. The work is well understood and the downtime number is a choice, not a risk you have to accept. You can see the kind of production platforms we run in our portfolio, including builds like ExpertAIQ.

Prefer to ask a question first? Get in touch — a five-minute answer about whether your bill justifies a move is free, and we would rather give it than quote a project you do not need.