Introduction

You don’t migrate off Heroku for fun — you do it when the bill, a compliance requirement, or a missing capability forces the conversation. Here’s the path we recommend, designed so you can stop at any step.

Phase one: stand up the target

Connect your AWS account and let Squark provision the cluster, VPC, and DNS zone. Deploy your app from the same GitHub repo Heroku builds from — most Procfile-style apps need only a Dockerfile, and Squark can detect the build context.

Run both environments in parallel. Point a staging domain at the Squark deployment and soak it against real traffic patterns.

Phase two: data and cutover

Provision Postgres from the Marketplace and replicate from your Heroku database. Move env vars into Squark’s secret management. When staging is boring, cut DNS over with a low TTL — and keep Heroku warm for a week as your rollback plan.

Workers and cron jobs move last: they’re stateless, and running them twice is usually worse than running them late.

The takeaway

Migrations fail when they’re leaps. This one is a ramp: every phase is independently reversible, and the old platform stays your safety net until the new one has earned trust.