Migrating from Heroku to AWS: A 2026 Playbook

We wrote about migrating Firstech from Heroku to AWS in 2024. Since then we’ve done several similar migrations, and the playbook has matured. The mechanics have stabilized. The tradeoff space has shifted slightly.

This post is an updated end-to-end playbook for teams considering the move.

Why teams are still doing this in 2026

Heroku is a great platform for the workloads it fits. But the workloads stop fitting at some point, usually when:

• Hosting costs cross a threshold where managed simplicity stops paying for itself (typically the $2K to $5K/month range)
• The team needs AWS services (specific databases, ML infrastructure, advanced networking) that Heroku integrations don’t expose well
• Compliance or data residency requirements push toward direct AWS usage
• The team has grown enough to absorb AWS operational complexity

If none of these apply, staying on Heroku is the right choice. We tell teams this regularly.

The three target architectures

For teams that have decided to move, three target shapes cover the overwhelming majority of cases:

ECS on Fargate

The most common target. The shape maps cleanly to Heroku’s mental model: each Heroku dyno type becomes an ECS service; each Heroku Postgres becomes Aurora; Redis becomes ElastiCache.

We used ECS for Firstech (originally scaffolded with AWS Copilot, which AWS has since announced will reach end-of-support in mid-2026). For new migrations today, we recommend CDK L3 constructs or hand-authored CloudFormation rather than Copilot.

Where it fits. Most production workloads. Multi-service applications. Anything beyond a single web process and a database.

Migration time. Typically 4 to 8 weeks for a multi-service application.

App Runner

A managed service that abstracts container deployment further. Closer to the Heroku experience than ECS: you push code or a container, it runs.

Where it fits. Smaller applications, especially single-service web apps. Teams that want to land on AWS but minimize operational complexity.

Migration time. 1 to 3 weeks for a small application.

Caveat. App Runner has matured significantly but still has gaps in customization compared to ECS. Confirm features before committing.

Elastic Beanstalk

The third option, and the one we recommend least often. Beanstalk’s mental model is older and the operational shape is awkward compared to current alternatives.

Where it fits. Almost never anymore. Occasionally for teams with very specific Beanstalk experience already on staff.

The phased migration approach

Whether you’re moving to ECS or App Runner, the phased approach is the same:

Phase 1: Database first

Migrate Heroku Postgres to AWS RDS or Aurora before touching the application. This is the highest-risk step. Get it done first, validate it, and you’ve removed the biggest unknown.

The mechanics: enable Heroku’s pg:upgrade features, set up logical replication to RDS, cut over with brief downtime. Specifics depend on Heroku Postgres tier and your acceptable downtime window.

Phase 2: Containerize

Build Docker images for each Heroku process type. This usually requires:

• Translating Procfile commands to container CMDs
• Externalizing config from Heroku environment variables to AWS Parameter Store or Secrets Manager
• Updating any code paths that depend on Heroku-specific environment variables (DATABASE_URL, PORT, etc.)

Run the containers locally against the new RDS database (now in production from Phase 1) to validate.

Phase 3: Stand up AWS infrastructure

For ECS, we now favor either CDK L3 constructs (aws-ecs-patterns) or a small CloudFormation template that follows the same shape: application load balancer, ECS service, target group, autoscaling, log group. The CDK option is fastest for greenfield work; the CloudFormation option is easier to maintain long-term if your team’s IaC standard is CloudFormation.

This is also where networking, domain configuration, and TLS get sorted. Don’t skip the staging environment. Set up production and staging in parallel from the start.

Phase 4: Cutover

Test the full application stack on AWS against the production database (which has been there since Phase 1). Switch DNS. Monitor closely for 24 to 48 hours.

Phase 5: Decommission

Remove Heroku resources. Cancel subscriptions. Update documentation.

What’s changed since 2024

A few things have shifted:

App Runner is more viable. It was rough around the edges in 2024. It’s now a credible target for smaller workloads.

Bedrock and AWS AI services are real differentiators. Teams moving for the AI tooling are now a meaningful share of our migrations, not just a hypothetical.

Heroku itself has improved. Salesforce has invested in the platform recently. The case for migrating away is no longer as clear-cut as it was in 2022. Run the numbers honestly.

AI-assisted migration is starting to help. Q Developer and similar tools meaningfully accelerate the containerization and IaC scaffolding work. Not magic, but real time savings on the boring parts.

Common pitfalls

Issues we’ve seen multiple times:

• Underestimating background job complexity. Heroku worker dynos are simple. AWS equivalents (ECS scheduled tasks, SQS-driven workers) are more powerful but require more design. Plan for it.
• Add-on parity. Heroku add-ons (logging, monitoring, error tracking) need AWS equivalents. Don’t leave this for the end.
• Networking surprises. Heroku networking is invisible. AWS networking is not. Budget time for VPC, subnet, security group, and load balancer configuration.
• Cost surprises in the wrong direction. Some workloads cost more on AWS at small scale because of the base service costs. Run a thorough cost projection before committing.

A simple rule

For teams trying to decide: if your Heroku bill is under $1K/month and you’re happy with the platform, stay. If your bill is over $5K/month or you need AWS services that Heroku doesn’t expose, the migration usually pays back inside a year.

The middle ground requires real analysis. We’ve helped several clients work through that decision, sometimes ending in “don’t migrate.”

Closing

Heroku to AWS isn’t an exotic project anymore. The patterns are well-established, the tooling is mature, and the right target architecture is usually clear after a brief assessment.

If you’re considering the move, we’d be glad to help you decide whether it makes sense and execute it well.