Moving From Heroku to AWS ECS: A Checklist by Stage

Heroku bundles many things into one bill. List each and its AWS counterpart:

• Web and worker dynos: become ECS services, with the Procfile process types turning into separate task definitions.
• Release phase: becomes a migration step in your pipeline or a one-off ECS task that runs before the new version takes traffic.
• Scheduler: becomes scheduled tasks, for example EventBridge rules that start ECS tasks.
• Config vars: become environment variables and secrets injected at task start, ideally from a secrets manager.
• Add-ons: Postgres, Redis, email, logging and monitoring each need an AWS or third-party replacement.
• Domains, TLS and review apps: become a load balancer, certificates and whatever preview environment process you build.

Missing items are the main source of surprises, so read your Heroku dashboard and Procfile line by line, and ask whoever set it up what else is hidden there.

Work through these in order and test after each:

1. Write a Dockerfile that reproduces what the buildpack did, and confirm the image runs locally with production-like variables.
2. Create a container registry repository and push the image from CI.
3. Build the network: a VPC with private subnets for tasks and data, public subnets for the load balancer.
4. Define the ECS cluster, task definitions and services, with health checks and resource sizes based on your dyno metrics.
5. Set up a load balancer, certificate and a temporary hostname, and test the app end to end there.
6. Send logs to a central place and add basic alarms before you move traffic.

Choosing between launch types affects cost and operations; see ECS Fargate vs EC2 cost. If you're weighing ECS against Kubernetes first, read AWS ECS vs Kubernetes for tech startups.

The database is the riskiest step, so rehearse it. For small databases, a dump and restore during a short maintenance window is the simplest, with the application in read-only or offline mode while you copy. For larger ones, look for a replication-based approach that keeps the AWS copy in sync until cutover; what's possible depends on your Heroku plan and options, so check current documentation.

Rehearse at least once with a copy. Time it, verify row counts and run the app's tests against the restored database. Plan the cutover: stop writes, take the final copy, switch connection strings, verify, then reopen. Keep the old database untouched and read-only for a while as your fallback. For the target database options, see how a Postgres move is structured in the Supabase to RDS migration guide, which applies to any managed Postgres target.

Lower your DNS record's time-to-live a day or two before, so a change or rollback propagates quickly. On the day:

• Freeze deploys on Heroku.
• Complete the database move if it hasn't happened.
• Point DNS to the AWS load balancer, and watch error rates, latency and queue depth.
• Confirm scheduled jobs and workers run on AWS only, so tasks don't run twice or not at all.
• Check outbound integrations that whitelist your IP addresses, since AWS addresses differ from Heroku's.
• Keep the Heroku app scaled down but intact for your rollback window.

Have a named person own rollback, with the trigger conditions written down: for instance, error rate above a threshold for ten minutes.

Migrations often quietly change delivery speed. DORA's 2024 report describes lead time for changes from under a day to one to six months across performance clusters¹, so measure yours before and after. If deploys got slower, fix the pipeline before declaring victory.

Then tidy up: remove unused add-ons, cancel the Heroku plan only after your rollback window closes, document the new runbook, and set cost alerts. Note what Heroku gave you for free, such as router logs and automatic restarts, and confirm you've replaced each.