Driver 01
Compute and add-on costs
Paying a premium for convenience on dynos and managed Postgres and Redis add-ons as usage grows.
Migration playbook: Heroku → AWS or Google Cloud
Heroku to AWS or Google Cloud migration
Move off Heroku's dyno limits, add-on pricing and networking constraints to containers on AWS or Google Cloud, with a planned and rehearsed database cutover.
Migration drivers
Why teams make this move
Driver 02
Memory and connection limits
Hitting dyno memory limits and database connection caps during traffic peaks.
Driver 03
Limited private networking
Needing private peering, VPN tunnels or network controls that are only available on Heroku's enterprise tiers.
Execution sequence
How the migration runs
Each phase ends with a check you can verify — data parity, error rates, latency — and the rollback path is agreed before any traffic moves.
- 01Phase
Containers and infrastructure as code
Packaging the apps as Docker images and defining networks and services in Terraform.
- 02Phase
PostgreSQL migration
Choosing between dump-and-restore and trigger-based replication based on data size and the write freeze you can accept, then rehearsing the cutover.
- 03Phase
Add-on replacement
Replacing Heroku add-ons with managed services: ElastiCache or Memorystore, S3 or Cloud Storage, and a CDN.
- 04Phase
DNS cutover and shutdown
Switching traffic with a rehearsed DNS change, then turning off the dynos once the new stack is stable.
Risk prevention
Pitfalls that derail this migration
Risk 01
Connection pooling
Heroku setups often rely on PgBouncer; without RDS Proxy or PgBouncer on the new side, connection limits are hit quickly.
Risk 02
Heroku-specific configuration
Code that assumes Heroku's DATABASE_URL format, dyno metadata or the ephemeral filesystem.
Risk 03
Missing log aggregation
Losing Logplex without first setting up a replacement pipeline (CloudWatch, Cloud Logging or Datadog).
Before and after
What we measure
We take a baseline before any change and report the same numbers after cutover, from your own tools. They are the evidence of whether the migration worked — not figures promised in advance.
- Monthly cost
- Heroku invoice vs the new cloud bill for the same workload
- Cutover window
- Write freeze measured in rehearsal, then in production
- p95 latency
- Key endpoints, before and after the move
Questions
Frequently asked migration questions
It depends on the number of apps and add-ons and on the size of the database. We size it after an inventory, and the estimate covers the rehearsal as well as the cutover.
Yes. We set up CI/CD (for example GitHub Actions) that builds on every push, creates preview environments and deploys to production when you merge.
Rehearse the cutover before the real one
Tell us about your data volume, traffic and timeline. An engineer will reply within one business day to set up a call about the migration plan and its rollback path.