Heroku Migration for Elixir Apps
|> Outgrow Heroku without breaking the team that runs on it.
/ / Who this is for
- |> Teams paying $500+/month in Heroku dynos and add-ons
- |> Engineering leads whose app is hitting Heroku's connection or slug size limits
- |> Startups preparing a Series A infrastructure tidy-up
- |> Small teams who need the migration done right, without owning the whole project themselves
/ / What's included
- |>Current-state audit: dynos, add-ons, config vars, build pipeline, scheduled tasks
- |>Target platform selection and architecture design (AWS ECS, EC2, or self-hosted)
- |>Terraform config written and reviewed
- |>Zero-downtime cutover plan with rollback procedure
- |>Database migration and connection pool tuning
- |>Post-migration monitoring setup and handover documentation
/ / How we work
-
1
Discovery
We audit your Heroku setup, understand your traffic patterns, and agree a target architecture.
-
2
Build
We provision the new environment, wire up deployments, and run your app in parallel so there's no big-bang cutover.
-
3
Cutover & handover
We flip DNS, monitor for 48 hours, and hand over full documentation so your team owns what comes next.
/ / Common questions
- Do we need to rewrite any of our application code?
- Almost never. Heroku migrations are an infrastructure concern. Your Phoenix app, OTP releases, and Mix config stay the same. We change what surrounds the app, not the app itself.
- How long does a Heroku migration typically take?
- Most migrations complete in 8-10 weeks. Simple apps with one database can be done in under two weeks. Complexity is driven by the number of add-ons, background job queues, and whether you have strict downtime requirements.
- Can you migrate our Postgres database with no downtime?
- Yes. We use logical replication to keep the old and new databases in sync during the cutover window, so the switch takes seconds, not hours.
- Which platforms do you migrate to?
- We can migrate to almost any platform. For teams that need AWS for compliance or existing infrastructure reasons, we use ECS Fargate or EC2 depending on the workload.