Migrating off Heroku to AWS without killing your deploy speed: the tools that actually help

Key points

• Moving containers to AWS is the easy half. The velocity you lose comes from losing the platform layer that Heroku gave you for free: git-push deploys, per-pull-request preview environments, managed Postgres, log aggregation, one-click rollback. Decide who rebuilds that layer before you move a single service.
• There are three viable paths: build it yourself (ECS Fargate or EKS + Terraform + GitHub Actions + ArgoCD), sidestep to another managed PaaS (Render, Railway, Fly.io), or run an internal developer platform inside your own AWS account (Qovery, Porter, Northflank BYOC). Only the third keeps PaaS ergonomics on an AWS account, VPC, and bill you own.
• AWS App Runner is the closest AWS-native Heroku analogue, but it has no preview environments, no managed database of its own, and hard ceilings of 4 vCPU and 12 GB per service, so most teams outgrow it into ECS Fargate or EKS.
• Pick ECS Fargate under roughly 15 services with no Kubernetes skills in house. Pick EKS once you need GitOps, custom controllers, or portability, and budget the $0.10 per cluster per hour EKS control-plane fee (about $73/month) before any workload runs.
• Qovery collapses the platform rebuild into a guided migration: it generates and manages Terraform-based infrastructure (EKS or ECS) inside your own AWS account, imports your apps and config, and keeps git-push deploys, per-PR previews, RBAC, logs, and rollbacks on top. Kubernetes is the runtime, and the AWS bill and the Terraform stay yours.
• Because Qovery is an AWS Partner, migration work can be routed through AWS partner migration funding instead of landing on your budget. Qovery reports a 4.8/5 customer satisfaction score over the last 12 months across hundreds of migrations (Qovery-reported internal data).
• Sequence the move in five phases over 6 to 12 weeks for a 10-service app, and do not migrate at all under roughly $2k/month of PaaS spend with no compliance driver. One platform engineer's loaded salary exceeds the bill you are trying to cut.

---

I have interviewed more than 200 CTOs about why they left Heroku, and the pattern almost never changes. The decision to leave is about cost or compliance. The regret, six weeks later, is about velocity.

The containers are the easy part, and that catches people off guard. You can get a Docker image running on AWS in an afternoon. What breaks is everything Heroku was quietly doing for you around that container - the build pipeline, the TLS certificate, the managed database, the log stream, the one-click rollback, and the review app that spun up on every pull request. On AWS, each of those is a separate service that someone has to wire, secure, budget, and keep alive.

This is a guide to moving off Heroku onto AWS without that velocity collapse. I will compare the real tools, give you a five-phase migration sequence, and be honest about when you should not migrate at all.

Why does migrating from Heroku to AWS usually slow teams down?

Teams slow down because they migrate compute and forget the platform layer. On Heroku, one git push produces a built image, a running app with TLS, a managed Postgres, aggregated logs, and a rollback button. On raw AWS, each of those is a service you assemble yourself. And per-PR preview environments, the feature developers miss most, have no AWS-native equivalent at all.

Here is the mapping most teams do not draw until they are three weeks in:

Every row in that "who owns it" column is the same answer: someone on your team becomes the platform team. That is the line item nobody budgets. A platform engineer in the US carries a median base salary well north of $150k, with total compensation past $230k at mid-career (levels.fyi). Even at a conservative loaded cost of $200k a year, that is roughly $17k a month of engineering time - and if that person is wiring NAT Gateways instead of shipping product, you are paying for the migration twice.

The failure mode is specific and I have watched it happen more than once. A team shipping several times a day on Heroku moves to AWS, cannot reproduce review apps, and regresses to a single shared staging environment. Deploys drop to weekly. In DORA terms, they fall from elite (deploy on demand, lead time under a day) to low (deploy somewhere between weekly and monthly). That is not a rounding error. That is the difference between a team that feels fast and a team that feels stuck.

So the fix has to come first, before you move workloads: replace the platform layer, then migrate the services onto it. Do it in that order and the migration is boring. Do it in the other order and you spend a quarter rebuilding review apps by hand.

What are the real reasons teams leave Heroku for AWS in 2026, and when should you stay?

Four drivers justify the disruption. If none of them apply to you, staying on a managed PaaS is the cheaper engineering decision, and I will say so plainly.

1. Cost at scale. Raw compute on AWS is cheaper per unit than a Heroku dyno, and the gap widens with commitment. A Heroku Standard-2X dyno is $50/month for 1 GB of RAM. An always-on Fargate task with 1 vCPU and 2 GB costs about $36/month at on-demand rates ($0.04048 per vCPU-hour, $0.004446 per GB-hour), and a Compute Savings Plan takes up to 66% off that, pushing raw compute toward $12-15/month. Those committed-spend discounts only exist in an account you own.

But watch the total, not the per-container line. AWS adds costs Heroku hid: a NAT Gateway is $0.045 per hour plus $0.045 per GB processed, which is about $33/month per gateway before a single byte moves, and you will want one per availability zone for HA. Add an ALB, RDS Multi-AZ, and inter-AZ data transfer, and the crossover point is higher than the sticker comparison suggests.

2. Compliance and data residency. SOC 2 evidence over an account you control, a HIPAA BAA with the right scope, GDPR data residency in a specific region, private networking, and VPC peering or Transit Gateway to on-prem. Heroku cannot give you the account-level control an auditor increasingly wants to see.

3. AWS-only services a PaaS cannot proxy cleanly. SQS, Kinesis, Aurora, Bedrock, S3 with bucket-level IAM, GPU instance families. Once your architecture depends on one of these, you want to live next to it inside the same VPC.

4. VPC-level network control. Private subnets, security groups, egress control, and peering to systems that will never touch the public internet.

If none of those four apply, here is my blunt advice: do not migrate. Below roughly $2k/month of PaaS spend, with fewer than about 10 engineers and no compliance pressure, the platform rebuild costs more than the bill you are trying to cut. One platform engineer's loaded annual salary is many times your annual Heroku invoice. Cutting a $24k/year bill by hiring a $200k/year engineer to run the replacement is not a saving. Treat Heroku fairly here too - check the current Heroku pricing page and dyno docs for what your workload actually costs today rather than migrating on a rumor about the free-tier removal.

What are the three migration paths off a PaaS, and which one keeps deployment fast?

There are three realistic paths, and only one of them keeps Heroku-grade developer experience while giving you your own VPC, your own bill, and your own compliance boundary.

Path 1 - Build it yourself on AWS. ECS Fargate or EKS, plus Terraform or CDK for state, plus GitHub Actions for CI, plus ArgoCD for delivery. Maximum control. Realistically 1 to 2 dedicated platform engineers to build it and then keep it running. This is the only path that reliably costs a full-time hire or two, forever, not just during the move.

Path 2 - Sidestep to another managed PaaS. Render, Railway, Fly.io, or a newer Heroku plan. Fastest migration and first-class developer experience. But your workloads still run in the vendor's infrastructure, so you inherit a new ceiling and a new egress bill, and you have not actually moved to AWS. That is the right answer to "we do not want to think about cloud infrastructure." It is the wrong answer to "we must be on AWS." And Vercel is a frontend and edge platform with documented function limits, not an AWS backend replacement - it answers a different question entirely.

Path 3 - Run an internal developer platform in your own cloud account. Qovery, Porter, Northflank BYOC, Coherence, or a self-built Backstage + Crossplane stack. Your apps run on your AWS account, VPC, and bill, but the platform gives developers the same push-to-deploy and preview-environment experience they had on Heroku.

The decision rule I give people is short. Small team, no compliance driver, low spend: stay on a PaaS. Real compliance or AWS-only dependency, and a platform team you can afford to staff: DIY. Everyone in between, which is most teams: run an IDP in your own account.

Two buying criteria matter more than list price. The first is a test: can you export the generated Terraform and keep the cluster running if you stop paying? Your exit should be a Terraform state, not a support ticket. The second is the one teams forget to ask: who does the migration work? Some vendors ship a guided migration and AWS-partner-funded assistance, and that changes the real cost of the move far more than a per-seat price does.

Here is the full landscape. I have kept it honest, including where Qovery is not the answer.

Which AWS-native tools reduce migration complexity, and where exactly do they stop?

AWS ships genuinely good building blocks. I am not going to pretend otherwise. But they all stop at the same three places: environment lifecycle, developer self-service with guardrails, and per-environment cost attribution.

AWS App Runner is the closest AWS-native Heroku analogue. It builds source-to-service from GitHub or ECR, gives you HTTPS automatically, and scales on request volume. It is the fastest way to get one container running on AWS. But the ceilings are real: 4 vCPU and 12 GB per service, a max concurrency of 200, no built-in database, and no preview environments. It also costs more than Fargate for always-on work: App Runner active instances are $0.064 per vCPU-hour plus $0.007 per GB-hour, so that same 1 vCPU / 2 GB task runs about $57/month versus Fargate's $36. App Runner earns its keep when traffic is spiky and you want it to idle down, not when it runs flat out.

AWS Copilot CLI scaffolds ECS for you and emits CloudFormation. It is fine for a handful of services and gets awkward the moment your environment topology goes custom.

ECS Fargate versus EKS is the fork most teams agonize over. My rule: Fargate under roughly 15 services with no Kubernetes skills in house, because ECS has no orchestration-layer fee and no cluster to babysit. Move to EKS once you need GitOps, custom controllers, or portability across clouds - and budget the $0.10 per cluster per hour control-plane fee (about $73/month) per cluster before any workload runs. The CNCF's annual survey keeps naming the same two barriers to Kubernetes: complexity and the in-house skills gap. Do not adopt EKS to solve a problem you do not have yet.

The database move is where downtime lives. AWS DMS handles homogeneous PostgreSQL paths, and native PostgreSQL logical replication with change data capture gets you to a near-zero-downtime cutover. Read the restrictions page before you plan the cutover - logical replication does not copy sequences, DDL, or large objects automatically, and those gaps are exactly what bites during the write freeze.

Terraform's real job is infrastructure state and reproducibility, full stop. It is not developer self-service. Nobody should expect Terraform to hand a developer a preview environment on a pull request. And AWS MGN and Migration Hub are mostly irrelevant coming from a PaaS - they are built for lift-and-shift of VMs, not for a team that is already containerized. Skip them and save yourself a week.

One thing that is genuinely worth your attention: the AWS Migration Acceleration Program (MAP) funds migrations delivered through AWS Partners. If your migration labor can be routed through a partner, AWS may cover a meaningful slice of it. That is real money and most teams never ask.

The gap list is short and consistent: no per-PR ephemeral environments, no self-service with guardrails, no per-environment cost attribution out of the box. And two bill lines nobody forecasts: NAT Gateway hours and cross-AZ data transfer.

How do you keep git-push deploys and preview environments after moving to AWS?

Preview environments are the Heroku feature teams miss most, and rebuilding them by hand on AWS means making five things work unattended. Treat this as an acceptance checklist:

• A namespace or service per branch
• An ALB listener rule or wildcard DNS entry
• An ACM certificate for HTTPS
• An ephemeral Postgres, from a snapshot restore or a seed script
• Automatic teardown on PR close, with a spend cap so forgotten environments stop bleeding money

There are two DIY routes. Option A is Kubernetes namespaces plus the ArgoCD ApplicationSet pull request generator, which creates an app per open PR and prunes it when the PR closes. Option B is Terraform workspaces triggered from GitHub Actions plus a scheduled reaper job that deletes stale environments.

Both work on paper. Where DIY quietly fails is database seeding and teardown - the parts nobody owns. Seeding a realistic ephemeral database and guaranteeing teardown are unglamorous, so they slip, environments pile up, the bill spikes, and the team quietly regresses to one shared staging environment. Lead time doubles. That is the exact velocity collapse I described at the top, and Heroku's review apps - per-PR app creation, add-on provisioning, automatic teardown, all configured in app.json - are the baseline you are trying to match.

This is where an IDP earns its place. Qovery clones a full environment when a PR opens, seeds its database from a template environment, gives it a unique HTTPS URL, and deletes the whole thing on merge - all on Terraform-generated infrastructure in your own AWS account, with per-environment RBAC.

Whichever path you pick, hold it to one acceptance test: open a pull request, get a unique HTTPS URL with a working database in under 10 minutes, and confirm it disappears on merge. If it cannot do that unattended, it is not done.

What does a low-risk Heroku to AWS migration sequence look like, and how long does it take?

Migrate in five phases and keep both platforms live until the metrics match. For a 10-service application, plan 6 to 12 weeks doing it yourself, and expect the estimate to be blown by the boring things: cron jobs, background workers, static egress IPs, and third-party allowlists.

Phase 0 - Inventory. List every service, add-on, config var, scheduled job, and worker dyno. Note static egress IPs and any third-party allowlists that depend on them. Containerize anything still riding a buildpack.

Phase 1 - Landing zone. AWS Organizations and account structure, VPC and subnets, IAM roles, ECR, RDS, Secrets Manager. Terraform from the first commit. No console clicking, because anything you click you cannot reproduce.

Phase 2 - Stateless services on AWS, database still on Heroku. Run your apps on AWS while they read and write the Heroku Postgres over TLS. Compare p95 latency and error rate side by side before you shift a single user.

Phase 3 - Traffic shift. Use weighted Route 53 records or ALB weighted target groups: 5%, then 25%, 50%, 100%, with a documented rollback at each step.

Phase 4 - Database cutover. Logical replication plus a short write freeze. Write the rollback plan before the freeze, not during it.

Phase 5 - Decommission and reconcile. Turn off Heroku and read your first full AWS bill against your last Heroku invoice. Look hard at the NAT Gateway and data transfer lines - they are the ones that surprise people.

The estimate-killers are always the same: cron and worker parity, add-on replacements, egress IP allowlists, and anything writing to a local filesystem instead of S3. And this is where the timeline compresses: phases 1 and 2 are the bulk of those 6 to 12 weeks, and they are exactly the phases a guided migration tool automates. An IDP that provisions the landing zone and imports your app config removes most of phase 1. It does not remove the whole migration - the database cutover is still a planned event - but it deletes the slowest, most error-prone weeks.

How does Qovery make the migration itself faster, and who pays for it?

At Qovery, we built the migration around those two slowest phases. The guided flow provisions Terraform-managed infrastructure (EKS or ECS) in your own AWS account, imports your applications, databases, and environment variables, wires up the build and deploy pipelines, and stands up your environments. On the other side you get git-push deploys and per-PR preview environments, on infrastructure you own. You can see the flow at qovery.com/migrate.

Let me be precise about scope, because a claim that does not survive scrutiny is worthless. The guided flow handles the platform and application layer. The database cutover is still a planned event with logical replication and a short write freeze - we guide it, you run it. And the important part: the AWS bill, the VPC, the cluster, and the Terraform stay yours. You hold the cloud bill and the audit trail. If you stop paying Qovery, the cluster keeps running on the Terraform we generated. Your exit is a Terraform state, not a support ticket.

The part most teams do not know to ask about is who pays for the migration labor. Qovery is an AWS Partner, so migration work can be routed through AWS partner migration funding rather than paid out of your budget. That matters more than any per-seat price, because the dominant cost of leaving Heroku is engineering weeks, not the monthly invoice. Whoever absorbs those weeks decides whether the move is worth doing at all.

On the hands-on dimension, this is where I think the category actually differs. Render, Railway, and Fly.io help you onboard to their platform, not into your AWS account. Porter and Northflank BYOC do deploy into your cloud account, and you should ask each of them the same question you ask us: do you offer funded, hands-on migration help, or a signup form? Qovery has run hundreds of these migrations and reports a 4.8/5 customer satisfaction score over the last 12 months (that is our own internal data, not a third-party audit, and I will state it once rather than dress it up).

I will also tell you when Qovery is the wrong choice, because pretending otherwise helps no one. Skip us if you have no AWS account and no intention of owning one, if you have zero appetite for infrastructure ownership (a pure PaaS like Render fits you better), if you are a purely static frontend or edge-function workload (that is Vercel's job), or if you already run a mature platform on Backstage and Crossplane and like it.

The migration-specific play I recommend: run Qovery in parallel with Heroku through phases 2 and 3, point your new AWS environments at the old Heroku Postgres first, prove the metrics match, and cut the database over last. Nothing irreversible happens until you are already confident.