Migrating from Heroku to StackBlaze

We talk to teams every week who are outgrowing Heroku pricing, need private networking between services, or want PITR on every database tier without an enterprise contract. Migration does not have to be a freeze-the-company weekend if you stage it correctly.

Concept mapping

Step 1: Export config and provision StackBlaze

Run heroku config -s -a your-app and save the output. Create a StackBlaze project, connect the same GitHub repo, and recreate variables in the dashboard, use Secret for anything sensitive. Do not commit production secrets to blueprint.yaml.

Step 2: Database migration

For Postgres, take a logical dump from Heroku and restore into StackBlaze Postgres. For large databases, use pg_dump with custom format and parallel restore to cut downtime.

#!/usr/bin/env bash
set -euo pipefail

HEROKU_URL="${HEROKU_DATABASE_URL:?}"
STACKBLAZE_URL="${DATABASE_URL:?}"

pg_dump "$HEROKU_URL" --format=custom --no-owner -f backup.dump
pg_restore --dbname="$STACKBLAZE_URL" --no-owner --jobs=4 backup.dump

echo "Restore complete, run verification queries before cutover"

Step 3: Staging parity and smoke tests

Deploy to a staging environment first. Hit health endpoints, run your integration test suite, and verify worker/cron jobs against staging data. StackBlaze PR previews help QA individual branches before merge.

Step 4: Cutover

1. Lower DNS TTL on your custom domain 24 hours ahead of time.
2. Deploy production on StackBlaze and confirm green health checks.
3. Point DNS to StackBlaze (or use a proxy in front during transition).
4. Monitor error rate and latency for one hour; keep Heroku app scaled to zero but available for rollback.
5. Deprovision Heroku add-ons after 48 hours of stable traffic.

What teams tell us surprised them

• Private .internal hostnames replace public DATABASE_URL calls between services, update connection code if you were routing through the internet.
• Build times are often faster because we cache npm/pip layers keyed on lockfiles.
• Invoice line items map per service, easier to see which microservice drives cost.

We offer migration office hours for teams moving more than five services. Book through support in the dashboard if you want a human to review your blueprint before cutover.