Do you want to replace Heroku while retaining controlled deployment and operations? WZ-IT provides Heroku migration from EUR 1,990 excluding VAT through target acceptance and can take over ongoing operations.
A migration from Heroku to Coolify or self-hosting translates a mature PaaS model into explicit components. Dynos, Procfile, buildpacks, config vars, add-ons, pipelines and Heroku Postgres need to keep working on the target or be replaced deliberately.
On 6 February 2026 Heroku announced its move to a sustaining engineering model: the focus is on stability, security, reliability and support, and Enterprise Account contracts are no longer offered to new customers. According to Heroku, nothing changes for existing customers or for customers paying by credit card. Platform changes still ship; the October 2026 update, for example, made PostgreSQL 18 the default and introduced the Heroku Postgres Advanced tier. A Heroku exit is therefore not an emergency measure but a plannable decision about long-term platform strategy.
Inventory the Heroku application and pipeline
Capture in particular:
- apps and their Heroku Pipeline assignment
- staging, review and production environments
- dyno types, counts and resources
- process groups in the Procfile
- buildpacks, runtime versions and system dependencies
- config vars and secret use
- add-ons and their actual function
- Heroku Postgres, Redis, storage and external data paths
- scheduler, release phase and one-off dynos
- domains, TLS, email, webhooks and OAuth callbacks
- logs, metrics and alerting
The add-on list alone is insufficient. For every service, determine which data it holds, how the application connects and which export or replacement path is available.
Map dynos and the Procfile
| Heroku layer | Possible target mapping |
|---|---|
| web dyno | application behind reverse proxy and TLS |
| worker dyno | separate worker service without public endpoint |
| clock/scheduler | scheduled platform job or system timer |
| release phase | controlled migration or deployment step |
| one-off dyno | administrative job or temporary task |
| config vars | protected variables and secrets per environment |
| pipeline | separate staging and production projects |
A Procfile describes start commands, but not the complete operating model. Add health checks, resources, restart, concurrency, logging and scaling on the target.
Replace buildpacks with reproducible builds
Buildpacks detect language and dependencies partly automatically. During exit, make the build explicit and reproducible. Depending on the application, this becomes a Dockerfile or a transparent target-platform build configuration.
Validate:
- runtime and package versions
- lockfiles and private registries
- operating-system packages and native libraries
- build and release scripts
- static assets and compilation steps
- start command and expected ports
- behaviour across multiple instances
Produce the build independently of Heroku and start it in an isolated target environment first.
Replace add-ons by function
Heroku add-ons may provide databases, cache, queues, email, monitoring, logging, search or object storage. Replace the required function and data path, not merely the product name.
For each add-on document:
- data and configuration
- export and import path
- target product or retained external service
- new connection details and secret rotation
- acceptance and rollback
- later cancellation or retention
Migrate Heroku Postgres
Heroku documents export and import paths for Postgres. Capture database version, size, extensions, roles, connections, pooling, write activity and permitted outage before selecting the method.
After restore, validate more than table counts. Include sequences, constraints, functions, triggers, extensions, time zones and critical business queries. Test the application against the new database in staging first.
Staging, review apps and Git deployment
Git-based deployment remains possible. Heroku Pipelines and Review Apps do not automatically translate one to one. The target can provide fixed staging and production environments and optional short-lived previews.
Define branches, secrets, data access, domain, approval, health check and rollback separately. Preview environments must not alter production data unintentionally.
Cutover and ongoing operations
Before switching, validate web processes, workers, scheduler, data, email, webhooks, restart, logs, monitoring, backup and restore. Cutover coordinates in-flight jobs, write boundaries, final data sync, domain change and smoke tests. Keep the source available through the agreed rollback window where the data model and contract permit it.
For several applications or unknown add-ons, the PaaS Exit Review can be the more appropriate first step.
