Sie möchten Heroku ablösen und Deployment sowie Betrieb kontrollierbar weiterführen? WZ-IT übernimmt die Heroku-Migration ab 1.990 Euro netto bis zur getesteten Zielumgebung und auf Wunsch den anschließenden Betrieb.
Eine Migration von Heroku zu Coolify oder Self-Hosting übersetzt ein eingespieltes PaaS-Modell in explizite Komponenten. Dynos, Procfile, Buildpacks, Config Vars, Add-ons, Pipelines und Heroku Postgres müssen im Ziel weiter funktionieren oder bewusst ersetzt werden.
Heroku hat am 6. Februar 2026 die Umstellung auf ein Sustaining-Engineering-Modell angekündigt: Der Schwerpunkt liegt auf Stabilität, Sicherheit, Zuverlässigkeit und Support, Enterprise-Verträge werden Neukunden nicht mehr angeboten. Für bestehende Kunden und für Kunden mit Kreditkartenabrechnung ändert sich laut Heroku nichts. Plattformänderungen erscheinen weiterhin, im Oktober 2026 etwa PostgreSQL 18 als Standard und der neue Tarif Heroku Postgres Advanced. Ein Heroku-Exit ist damit keine Notfallmaßnahme, sondern eine planbare Entscheidung über die langfristige Plattformstrategie.
Heroku-Anwendung und Pipeline inventarisieren
Erfasst werden insbesondere:
- Apps und Zuordnung zu Heroku Pipelines
- Staging-, Review- und Production-Umgebungen
- Dyno-Typen, Anzahl und Ressourcen
- Prozessgruppen aus dem Procfile
- Buildpacks, Runtime-Versionen und Systemabhängigkeiten
- Config Vars und Secret-Verwendung
- Add-ons und deren tatsächliche Funktion
- Heroku Postgres, Redis, Storage und externe Datenwege
- Scheduler, Release Phase und One-off Dynos
- Domains, TLS, E-Mail, Webhooks und OAuth-Callbacks
- Logs, Metriken und Alarmierung
Die Add-on-Liste allein reicht nicht. Für jeden Dienst muss bekannt sein, welche Daten er hält, wie die Anwendung ihn anspricht und welches Export- oder Ersatzverfahren verfügbar ist.
Dynos und Procfile im Ziel abbilden
| Heroku-Ebene | Mögliche Zielabbildung |
|---|---|
| web Dyno | Anwendung hinter Reverse Proxy und TLS |
| worker Dyno | separater Worker-Service ohne öffentlichen Endpoint |
| clock/Scheduler | geplanter Plattformjob oder System-Timer |
| release Phase | kontrollierter Migrations- oder Deployment-Schritt |
| one-off Dyno | administrativer Job oder temporärer Task |
| Config Vars | geschützte Variablen und Secrets je Umgebung |
| Pipeline | getrennte Staging- und Produktionsprojekte |
Ein Procfile beschreibt Startkommandos, aber nicht das vollständige Betriebsmodell. Health Checks, Ressourcen, Restart, Parallelität, Logging und Skalierung werden im Ziel zusätzlich festgelegt.
Buildpacks durch reproduzierbare Builds ersetzen
Buildpacks erkennen Sprache und Abhängigkeiten teilweise automatisch. Beim Exit wird der Build explizit und reproduzierbar gemacht. Je nach Anwendung entsteht ein Dockerfile oder eine nachvollziehbare Build-Konfiguration der Zielplattform.
Zu prüfen sind:
- Runtime- und Paketversionen
- Lockfiles und private Registries
- Betriebssystempakete und native Bibliotheken
- Build- und Release-Skripte
- statische Assets und Compile-Schritte
- Startkommando und erwartete Ports
- Verhalten bei mehreren Instanzen
Der Build wird zuerst unabhängig von Heroku erzeugt und in einer isolierten Zielumgebung gestartet.
Add-ons funktional ersetzen
Heroku Add-ons können Datenbanken, Cache, Queues, E-Mail, Monitoring, Logging, Search oder Object Storage bereitstellen. Ein Wechsel ersetzt nicht den Produktnamen, sondern die benötigte Funktion und den Datenweg.
Für jedes Add-on werden dokumentiert:
- Daten und Konfiguration
- Export- und Importweg
- Zielprodukt oder weiterhin externer Dienst
- neue Verbindungsdaten und Secret-Rotation
- Abnahme und Rückfall
- spätere Kündigung oder Aufbewahrung
Heroku Postgres migrieren
Heroku dokumentiert Export- und Importwege für Postgres. Für ein planbares Verfahren werden Datenbankversion, Größe, Extensions, Rollen, Verbindungen, Pooling, Schreiblast und zulässige Ausfallzeit aufgenommen.
Nach dem Restore werden nicht nur Tabellenzahlen geprüft. Sequenzen, Constraints, Funktionen, Trigger, Extensions, Zeitzonen und zentrale fachliche Abfragen gehören zur Abnahme. Die Anwendung wird zunächst unter Staging mit der neuen Datenbank getestet.
Staging, Review Apps und Git-Deployment
Git-basierte Deployments bleiben möglich. Heroku Pipelines und Review Apps werden jedoch nicht automatisch eins zu eins reproduziert. Die Zielstrecke kann feste Staging- und Produktionsumgebungen sowie optional kurzlebige Preview-Umgebungen umfassen.
Dabei werden Branches, Secrets, Datenzugriff, Domain, Freigabe, Health Check und Rollback getrennt festgelegt. Preview-Umgebungen dürfen nicht unbeabsichtigt produktive Daten verändern.
Cutover und anschließender Betrieb
Vor der Umschaltung werden Webprozesse, Worker, Scheduler, Daten, E-Mail, Webhooks, Neustart, Logs, Monitoring, Backup und Restore getestet. Der Cutover koordiniert laufende Jobs, Schreibgrenze, finalen Datenabgleich, Domainwechsel und Smoke Tests. Die Quelle bleibt bis zum Ende des vereinbarten Rückfallfensters verfügbar, sofern Datenmodell und Vertrag das zulassen.
Bei mehreren Anwendungen oder unbekannten Add-ons kann der PaaS Exit Review den sinnvolleren ersten Schritt bilden.
