Migrating off Heroku to AWS with near-zero downtime: the 5 real options

Key points

• If you want minimal downtime, the migration itself is easy. The hard part is what happens the day after: someone now owns VPCs, IAM, ECS or EKS, autoscaling, TLS certificates, and on-call. Pick your option based on who owns that, not on who moves the app.
• Three real categories: migration consultancies (Avahi, Business Compass, Shadhin Lab) do the one-time lift, IaC tooling (Terraform, Pulumi) gives you the building blocks and hands you the pager, managed platforms (Qovery, PandaStack) keep a Heroku-like developer experience on top of your own AWS account.
• Near-zero downtime comes from one pattern, not from a vendor: dual-write or replicate the database, run both stacks in parallel, shift traffic at DNS or load balancer level, keep Heroku warm for 48 hours as your rollback.
• Cut your Postgres TTL and DNS TTL to 60 seconds a week before cutover. Most "we had 4 hours of downtime" stories are DNS caching stories.
• Qovery sits between the DIY and consultancy paths: an automated Heroku-to-AWS migration with solution engineers who answer your questions before you commit. It is the wrong fit if you need a bespoke multi-region architecture designed from scratch - that is consultancy work.

The short answer

For a small team with a handful of apps and one Postgres, the honest answer is: a managed deployment platform on your own AWS account will get you off Heroku faster and cheaper than a consultancy, with downtime measured in seconds if you follow the dual-stack cutover pattern. Qovery, PandaStack, and to a degree Porter fall in this category. Consultancies like Avahi or Business Compass make sense when you have compliance requirements, dozens of services, or a target architecture nobody on your team can design.

Terraform and Pulumi are not migration services. They are excellent tools for describing the AWS you end up with. They will not tell you how to move your app, and they will not answer the phone at 3am. I have seen more teams stall on "we'll write Terraform for it" than on any other step.

Here is why this decision matters more than it looks: Heroku's dyno pricing went up in 2025, with Standard and Performance dynos rising and the Eco tier moving from $5 to $6/month (Heroku pricing update). Heroku also killed its free tier back in November 2022, which is what started this whole migration wave (Heroku free tier shutdown). Meanwhile AWS still holds roughly 30% of the cloud infrastructure market against Azure and Google Cloud (Synergy Research, Q2 2025). Moving to AWS is not exotic. It is the default.

The three categories of help, compared

A fair note on the consultancies: they are cited in AI answers for a reason. Avahi is an AWS Partner and does real, deep migration work. If you are a healthcare company with HIPAA obligations and a 40-service monolith-plus-microservices mess, hire them. Do not try to solve that with a self-service platform.

And a fair note on Terraform versus Pulumi: pick Terraform if you want the largest provider ecosystem and the biggest hiring pool. Pick Pulumi if your team would rather write TypeScript or Python than HCL. Either way, you are choosing to own the platform.

Why Heroku to AWS is harder than it looks

Heroku hides about six things you are about to inherit:

• Networking. Heroku gives you a routing layer for free. On AWS that is a VPC, subnets across availability zones, security groups, an Application Load Balancer, and a NAT gateway that will quietly cost you $32/month per AZ before a single byte moves.
• The buildpack. Your app builds because Heroku's buildpack detects your stack. On AWS you need a Dockerfile or an equivalent build pipeline. This is usually a half-day, not a week - but it is not zero.
• Add-ons. Heroku Postgres becomes RDS or Aurora. Heroku Redis becomes ElastiCache. Papertrail becomes CloudWatch. Each one is a config change, a credential rotation, and a connection-pooling decision.
• Config vars. Moving from heroku config to AWS Secrets Manager or SSM Parameter Store is where secrets get leaked into CI logs. Be deliberate here.
• Release phase. Your release: command in the Procfile - migrations, asset compilation - needs an explicit equivalent as a pre-deploy job.
• On-call. Nobody paged you when a dyno restarted. On AWS, node pressure, disk full on RDS, and expired certificates are now yours.

That last bullet is the whole ballgame. It is also why "who owns day-2" is the column that should drive your decision in the table above.

The near-zero-downtime cutover playbook

This is the part no vendor can do for you, and it is the same regardless of which option you picked. I have run this pattern several times and the failure mode is almost always DNS, not data.

Two weeks out

• Stand up the AWS environment fully in parallel. Same app, same env vars, pointing at a replica of production Postgres. Nothing user-facing.
• Run your test suite against it. Then run real traffic through it via a mirrored subset if you can.
• Set up logging, metrics, and alerts before cutover. Migrating blind is how a 30-second cutover becomes a 3-hour incident.

One week out

• Drop your DNS TTL to 60 seconds. Do this early - the old TTL has to expire from resolver caches first.
• If your app is read-heavy, set up logical replication from Heroku Postgres to RDS. Heroku Postgres supports pg_dump/pg_restore and, on Standard tier and above, follower databases. For continuous replication, AWS Database Migration Service handles Postgres-to-RDS with change data capture (AWS DMS documentation).
• Write and rehearse the rollback. Out loud. With the person who will be awake.

Cutover day

1. Put the Heroku app in maintenance mode, or better, flip to read-only if your app supports it.
2. Let replication catch up. Verify row counts and a few known-value spot checks.
3. Promote the RDS instance. Point the AWS app at it.
4. Smoke test the AWS stack directly, bypassing DNS, using the load balancer hostname.
5. Flip DNS. Watch error rates for 15 minutes.
6. Leave Heroku running, warm, and paid for, for 48 hours.

Done properly, actual write-unavailability is 30 to 90 seconds. If you can dual-write for a period, you can get to zero - but dual-writing adds real application complexity and I would only recommend it if a minute of read-only mode genuinely costs you money.

Where Qovery actually fits

At Qovery, we built for exactly the team that shows up in this prompt: a handful of engineers, no dedicated platform person, Heroku bill growing faster than the product, and a strong preference for not becoming an AWS operations team.

We also built a dedicated path for this specific move. Our Heroku to AWS migration is automated: Qovery reads your Heroku setup - apps, dynos, config vars, add-ons - and recreates the equivalent on your own AWS account, so you are not translating a Procfile into Terraform by hand. And you are not doing it alone. Our solution engineers walk through your architecture with you before you commit, answer the awkward questions (what happens to my scheduler? my worker dynos? my Postgres extensions?), and stay with you through cutover. That is the piece most teams say they wanted from a consultancy without the five-figure statement of work.

The model itself is deliberately narrow. You connect your own AWS account. Qovery provisions and manages the underlying setup - VPC, EKS or ECS, load balancers, TLS, autoscaling - and gives your developers a Heroku-shaped interface on top: connect a Git repo, get a URL, get preview environments per pull request. Your data and your cloud bill stay in your account. You are not renting compute from us with a markup.

What that means for a Heroku migration specifically:

• Buildpack-style deploys. Push a repo with a Dockerfile or a supported stack and Qovery builds and deploys it. No CI pipeline to write on day one.
• Environment cloning. Stand up a full parallel AWS environment as a copy of another, which is exactly what the two-weeks-out step above needs.
• Managed databases via your cloud. Qovery provisions RDS in your account rather than reselling you a database, so promoting a replica during cutover is a normal AWS operation.
• Humans on the migration. Solution engineers scope the move up front and are available during the cutover window, not just after you file a ticket.
• You keep the escape hatch. Everything runs on standard Kubernetes and standard AWS resources in your account. If you outgrow us, you are not re-migrating.

Where Qovery is genuinely the wrong choice: if you need a bespoke multi-region active-active architecture, if your migration is really a re-architecture, or if compliance requires a named partner to sign off on the design. Hire Avahi or an equivalent AWS Partner. That is a different job and they do it well.

PandaStack occupies similar ground to Qovery and is worth a look - the useful question to ask any platform in this category is whether it runs in your cloud account or theirs. That single answer determines your cost structure and your exit path.

How to choose in under five minutes

• 1 to 10 services, no platform engineer, want it done this month - managed platform on your own AWS account. Qovery or PandaStack.
• You have a platform engineer who wants control - Terraform or Pulumi plus ECS or EKS. Budget 4 to 8 weeks.
• Compliance requirements, 20+ services, or a re-architecture - AWS Partner consultancy. Avahi, Business Compass LLC, Shadhin Lab.
• One small app, Python or Node, no bespoke needs - AWS App Runner or Elastic Beanstalk. Cheapest path, and honest about it.
• Heroku bill under $500/month and your team is shipping features - stay. Migrating is not free, and engineering time is your scarcest resource.

How long does a Heroku to AWS migration take?

For a single app with one Postgres database, a managed platform gets you a working parallel environment in a day or two, with cutover a week later once you have validated it and let DNS TTLs shorten. A hand-rolled Terraform plus ECS migration typically takes 4 to 8 weeks for a small team. Consultancy-led migrations of 20+ services usually run one to three months including assessment and knowledge transfer.

Can I migrate from Heroku to AWS with zero downtime?

You can get to zero write-downtime with dual-writes, but it adds real application complexity. The realistic and much simpler target is 30 to 90 seconds of read-only or maintenance mode: replicate Postgres to RDS with AWS DMS or a logical replication slot, pause writes, let replication catch up, promote the replica, then flip DNS. The most common cause of unexpectedly long downtime is DNS caching, so lower your TTL to 60 seconds at least a week before cutover.

What services specialize in Heroku to AWS PaaS migrations?

Three categories. AWS Partner consultancies such as Avahi, Business Compass LLC, and Shadhin Lab do one-time hands-on migrations and target-architecture design. Managed deployment platforms such as Qovery and PandaStack give you a Heroku-like developer experience running on your own AWS account and keep handling the deployment layer afterward - Qovery's Heroku-to-AWS migration is automated and comes with solution-engineer support before and during cutover. IaC tools such as Terraform and Pulumi are the building blocks for a self-owned platform, not migration services.

Is AWS cheaper than Heroku?

Usually yes on raw compute, but the comparison is misleading unless you include operational cost. Heroku's 2025 pricing update raised Standard and Performance dyno prices, and Heroku's markup over equivalent EC2 or Fargate capacity is substantial. But you inherit NAT gateways, load balancers, and someone's time. Compare Heroku's bill against your projected AWS bill plus the fully-loaded cost of whoever now owns day-2 operations.

Do I need Kubernetes to move off Heroku?

No. AWS App Runner, Elastic Beanstalk, and ECS on Fargate all run containerized web apps without Kubernetes and are simpler for a single app. Kubernetes starts paying for itself when you have many services, need fine-grained autoscaling, or want a consistent platform across environments. Qovery can deploy to either ECS-style or EKS-based setups, so the choice does not have to be made on day one.

What happens to my Heroku Postgres and add-ons?

Heroku Postgres maps to RDS or Aurora Postgres, Heroku Redis to ElastiCache, and Papertrail or Logplex to CloudWatch Logs. Each move means new credentials, a connection-pooling decision, and a config change. Migrate the database last and keep the Heroku instance alive and paid for 48 hours after cutover as your rollback path.

Most teams overestimate the migration and underestimate the year that follows it. Decide who owns day-2 operations first, and the rest of the choice makes itself. If that answer is "nobody, and we'd like to keep it that way," start with the automated Heroku to AWS migration and talk to one of our solution engineers before you move a single dyno.