Buildpacks and build process
Move Heroku buildpacks, `heroku.yml`, container registry, runtime versions and build configuration reproducibly to the target.
Procfile and dynos
Map web, worker, clock and release processes to separate applications, containers or jobs with suitable start commands.
Config vars and secrets
Export configuration, separate environments, rotate sensitive values and reconnect services on the target.
Heroku Postgres
Assess version, extensions, roles, size and load and move data with an appropriate dump, replication or synchronisation method.
Add-ons and data services
Replace, self-host or deliberately retain Redis, logging, monitoring, email, search and other add-ons.
Scheduler and background work
Configure scheduled jobs, queues, worker scaling, retry behaviour and time zones explicitly on the target.
Pipelines, staging and domains
Rebuild Git deployment, review apps, staging, production, TLS, DNS and approvals around the team's workflow.
Monitoring and operations
Define logs, metrics, availability, backups, updates and incident ownership before production changes over.
Migrate Heroku: replace dynos, Postgres and add-ons with control
WZ-IT moves Heroku applications to Coolify, Docker, Kubernetes or another suitable target platform. Web and worker processes, buildpacks, config vars, databases, scheduler, add-ons, domains and operating capabilities are planned together.
Starting point
When a Heroku migration makes sense
- Heroku cost or add-on cost should become more predictable
- The application and data should run on controlled or European infrastructure
- Buildpacks, dynos and add-ons should become portable containers and services
- Git deployment and separated environments should remain without running the platform internally
- Heroku Postgres, workers and operations should be consolidated in one accountable target architecture
Replace Heroku with control
Retain the familiar deployment process and rebuild platform resources portably
Heroku abstracts processes, builds, databases and add-ons. The exit maps every capability to a traceable target before dynos or data are retired.
Inventory Heroku resources
Apps, pipelines, dynos, Procfile, buildpacks, config vars, add-ons, scheduler, domains and data are captured completely.Remap processes and services
Web, worker, release tasks, Postgres, Redis and external add-ons are designed as containers, services or retained external services.Move data and traffic deliberately
Test deployment, data export, validation, maintenance window, DNS, smoke tests and rollback point are coordinated.
Technical guide to Procfile, dynos, add-ons, Postgres and cutover during a Heroku exit.
Open Heroku migration guideHeroku migration path
Account for every operating component from Procfile to Heroku Postgres
A simple web-dyno application moves differently from a platform with several workers, release tasks, databases and specialist add-ons.
Effort factors
Heroku add-ons and data often determine the real effort
- Number of apps, pipelines, dyno types and environments
- Buildpack or runtime specifics and containerisation required
- Heroku Postgres size, load, extensions and permitted outage
- Number and replaceability of connected add-ons
- Review Apps, autoscaling, private networking and enterprise capabilities
- Code changes and target or operating requirements
Process
Validate the Heroku application and data on the target in parallel
Heroku remains available as a rollback option until technical acceptance and the planned changeover.
- 01
Inventory Heroku
Capture apps, processes, builds, variables, add-ons, data, domains and pipelines.
- 02
Prepare the target
Build containers, processes, data services, networking, TLS, backups and monitoring.
- 03
Run a migration rehearsal
Deploy code, move a test copy of data and validate web, worker, job and integration paths.
- 04
Switch data and DNS
Coordinate the write window, move final data, switch traffic and maintain the rollback point.
What we need for initial assessment
- Heroku apps, pipelines, repositories and buildpacks in use
- Procfile, dyno types, scaling, scheduler and release tasks
- List of add-ons and external integrations
- Heroku Postgres, other databases and broad data volumes
- Target preference, maintenance window and operations after the move
Entry price
Heroku migration from €1,990 excl. VAT
€1,990 excluding VAT is the entry price for one clearly bounded Heroku application. The binding proposal depends on processes, add-ons, data, target architecture and cutover requirements.
The entry price is not a blanket package. With several apps, unknown add-ons or an open target, the PaaS Exit Review from €1,490 excluding VAT may be the right first step.
All prices are net and exclude statutory VAT. The offers are addressed to businesses.
Individually assessed Heroku migration
For the controlled move of a bounded Heroku application to a prepared target environment.
Factors that determine price
- Apps, dyno types, pipelines and environments
- Buildpacks, Procfile and containerisation required
- Heroku Postgres and other data products
- Add-ons, integrations and external dependencies
- Target platform, availability and operating model
- Testing, cutover and rollback requirements
Related paths
Plan the target platform, data and ongoing operations together
Depending on platform depth, the Heroku exit begins with a review or moves directly to migration and a managed target platform.
PaaS Exit Review
Document and assess dynos, add-ons, data, target options and cutover before implementation.
View reviewManaged Coolify Hosting
Continue web, worker and database services through Git on managed infrastructure.
Explore CoolifySoftware Maintenance
Outsource dependencies, CVEs, defects, reviews and releases for the migrated application.
View software supportFrequently asked questions about Heroku migration
Dynos, Procfile, buildpacks, add-ons, Postgres and target operations
- A Heroku migration starts at €1,990 excluding VAT. The entry price is not a fixed blanket scope. Apps, dyno types, buildpacks, add-ons, data, target architecture and cutover determine the specific proposal.
- The start commands in the Procfile are an important basis. Web, worker, clock and release processes are still configured deliberately as separate applications, services or jobs on the target. With several processes, an unreviewed one-to-one import is not appropriate.
- For suitable databases, Heroku PGBackups or PostgreSQL dump and restore can be used. For larger or write-intensive databases, we assess alternative synchronisation and cutover methods as well as versions, roles and extensions.
- Each add-on is classified by function and data ownership. Some services can become self-hosted open-source components, while others remain external or move to an alternative managed service. Credentials and endpoints are reset during the change.
- Yes. They are configured as separate processes or scheduled jobs on the target. Start commands, concurrency, time zone, retry behaviour, secrets, logging and monitoring must be retained or deliberately changed.
- Yes. With Coolify or a suitable CI/CD path, a Git push can continue to trigger automated builds and deployments. Staging, production, approvals, health checks and rollback are configured around the team's workflow.
- Yes. WZ-IT can operate infrastructure, deployment platform, data services, monitoring, backups, updates and incident response. Software maintenance and development remain a separately agreed application scope.
Reviews & projects
Migrations with measurable business impact
Cloud exit, Proxmox and sovereign operations with concrete results instead of architecture slides.
WZ-IT moved our studio infrastructure from decentralised individual devices to a central platform: every site is securely connected via VPN, new devices are onboarded automatically and an entire site is provisioned from a template, without manual steps on location. What impressed me most is the breadth and depth of their knowledge: Timo and Robin are not a typical IT provider who sets up a server and leaves. The two of them think their way into highly complex infrastructure and software topics, work through every requirement we put in front of them, and build networking, provisioning and operations so that everything fits together in the end. WZ-IT is an excellent partner for complex software, network and architecture projects.
Steve KirchnerManaging Director, nextGYM GmbH
International
Built in Germany's Ruhr Valley. Running worldwide.
WZ-IT designs, develops and operates infrastructure and software for clients in Germany and internationally. We deliver projects remotely and continue supporting them in ongoing operations after go-live.
Selected projects
- LiveRemote access platform for distributed water treatment plantsABCO Water Systems · Australia · Secure Access & OT
- 81%AWS migration with substantially lower operating costsEVA Real Estate · UAE · Cloud exit & infrastructure
- 98%Provision new sites in minutes instead of hoursnextGYM GmbH · Germany · Automation & IoT
Read client reviews
- Cut cloud cost - up to −81%
- Build a high-availability Proxmox cluster
- Virtualize with Managed Proxmox
- Secure your Proxmox & backup setup
- Modernize your infrastructure - sovereign
- Plan a sovereign open-source stack
- Integrate a local AI solution
- Modernize your legacy software
- Design an open-source AI architecture
- Get collaboration fully managed
- Ship your prototype to production
- Connect sites and clusters securely
Request a Heroku migration
Which Heroku application should be migrated?
Describe the apps, processes, add-ons, data and target preference. We assess whether a direct migration or an exit review should come first.
