Migrate from Heroku without trading cost for risk

A Heroku migration is more than moving a web process

Heroku bundles the runtime, routing, TLS, logs, add-ons, and release management. Moving the web process to a cheaper virtual machine does not replace all of that.

We first list the process types, buildpacks, add-ons, data stores, traffic, release commands, and support needs. That list shows whether the app belongs on a small container host, another managed platform, or a conventional paid cloud setup.

• Web and worker process types
• Release commands and build-time dependencies
• Add-ons, log drains, metrics, and alerting
• Current spend by app, database, and environment

Databases, backups, and rollback come first

A database move needs an explicit consistency plan. Small PostgreSQL databases may tolerate an export and restore during a maintenance window; larger or busier databases may need replication, validation, and a staged cutover.

Before DNS changes, the target database should be restored, application migrations tested, backups verified, and a rollback decision point documented. A migration is not complete until a restore has been tested and the old environment is retained long enough to support rollback.

• Database engine and extension compatibility
• Backup, restore, and retention checks
• Cutover write freeze or replication plan
• Rollback criteria and old-environment retention

Workers, cron jobs, files, and environment variables

Background workers need their own restart policy, health checks, resource limits, and logging. Heroku Scheduler jobs must become system timers, container jobs, or a managed scheduler. Configuration variables should be transferred through a secret store, never pasted into a public intake form.

An ephemeral Heroku filesystem is often safe to replace because persistent files already live in object storage. If the application writes durable files locally, those files need private object storage or a deliberately managed volume before migration.

• Worker concurrency and queue dependencies
• Scheduled jobs and time zones
• Secret and environment-variable inventory
• Persistent uploads and object-storage permissions

DNS, TLS, downtime, and the actual cutover

DNS TTLs can be lowered before the migration, but DNS is only one part of the cutover. The target must have valid TLS, correct host handling, health checks, monitoring, and a tested application build before traffic moves.

For a small application, a short written maintenance window can be safer and less expensive than engineering a zero-downtime migration. Business-critical systems with no acceptable interruption require a different scope and often paid redundant infrastructure.

• Pre-cutover smoke tests
• DNS TTL and certificate readiness
• Customer-visible maintenance communication
• Post-cutover logs, metrics, and rollback watch

When leaving Heroku will not save enough

Heroku may remain good value when the team depends heavily on its workflow, has little operational capacity, or needs managed services that would be costly to reproduce safely. A migration should be declined when expected savings do not justify the engineering and operational risk.

Voog considers more than one destination. Oracle Cloud Infrastructure can fit some steady Linux workloads, but its free tier can change and it is not right for every application.