Buildpacks und Build-Prozess
Heroku Buildpacks, `heroku.yml`, Container Registry, Runtime-Versionen und Build-Konfiguration reproduzierbar auf das Ziel übertragen.
Procfile und Dynos
Web-, Worker-, Clock- und Release-Prozesse als getrennte Anwendungen, Container oder Jobs mit passenden Startbefehlen abbilden.
Config Vars und Secrets
Konfiguration exportieren, Umgebungen trennen, sensible Werte rotieren und Verbindungen im Ziel neu setzen.
Heroku Postgres
Version, Extensions, Rollen, Größe und Last prüfen und Daten mit geeignetem Dump-, Replikations- oder Synchronisationsverfahren übertragen.
Add-ons und Datendienste
Redis, Logging, Monitoring, E-Mail, Search und weitere Add-ons ersetzen, selbst betreiben oder bewusst extern weiterverwenden.
Scheduler und Hintergrundarbeit
Geplante Jobs, Queues, Worker-Skalierung, Retry-Verhalten und Zeitzonen im Ziel explizit konfigurieren.
Pipelines, Staging und Domains
Git-Deployment, Review Apps, Staging, Produktion, TLS, DNS und Freigabeprozess passend zum Team neu aufbauen.
Monitoring und Betrieb
Logs, Metriken, Erreichbarkeit, Backups, Updates und Incident-Verantwortung vor dem produktiven Wechsel festlegen.
Heroku migrieren: Dynos, Postgres und Add-ons kontrolliert ablösen
WZ-IT überführt Heroku-Anwendungen auf Coolify, Docker, Kubernetes oder eine andere passende Zielplattform. Web- und Worker-Prozesse, Buildpacks, Config Vars, Datenbanken, Scheduler, Add-ons, Domains und Betriebsfunktionen werden gemeinsam geplant.
Ausgangslage
Wann eine Heroku-Migration sinnvoll ist
- Heroku-Kosten oder Add-on-Kosten sollen planbarer werden
- Anwendung und Daten sollen auf kontrollierbarer oder europäischer Infrastruktur laufen
- Buildpacks, Dynos und Add-ons sollen in portable Container und Dienste überführt werden
- Git-Deployment und getrennte Umgebungen sollen ohne eigenen Plattformbetrieb erhalten bleiben
- Heroku Postgres, Worker und Betrieb sollen in einer verantworteten Zielarchitektur zusammengeführt werden
Heroku kontrolliert ablösen
Den vertrauten Deployment-Prozess erhalten und die Plattformressourcen portabel neu aufbauen
Heroku abstrahiert Prozesse, Builds, Datenbanken und Add-ons. Der Exit ordnet jede dieser Funktionen einem nachvollziehbaren Ziel zu, bevor Dynos oder Daten abgeschaltet werden.
Heroku-Ressourcen inventarisieren
Apps, Pipelines, Dynos, Procfile, Buildpacks, Config Vars, Add-ons, Scheduler, Domains und Daten werden vollständig erfasst.Prozesse und Services neu abbilden
Web, Worker, Release Tasks, Postgres, Redis und externe Add-ons werden als Container, Dienste oder weiterhin externe Services geplant.Daten und Traffic kontrolliert wechseln
Testdeployment, Datenexport, Validierung, Wartungsfenster, DNS, Smoke Tests und Rückfallpunkt werden abgestimmt.
Technischer Leitfaden zu Procfile, Dynos, Add-ons, Postgres und Cutover beim Heroku Exit.
Heroku-Migrationsleitfaden öffnenHeroku-Migrationspfad
Vom Procfile bis Heroku Postgres alle Betriebsbausteine berücksichtigen
Eine einfache Web-Dyno-Anwendung lässt sich anders migrieren als eine Plattform aus mehreren Workern, Release Tasks, Datenbanken und spezialisierten Add-ons.
Aufwandsfaktoren
Heroku-Add-ons und Daten bestimmen häufig den tatsächlichen Aufwand
- Anzahl der Apps, Pipelines, Dyno-Typen und Umgebungen
- Buildpack- oder Runtime-Spezifika und notwendige Containerisierung
- Heroku Postgres Größe, Last, Extensions und zulässige Ausfallzeit
- Anzahl und Ersetzbarkeit angebundener Add-ons
- Review Apps, Autoscaling, private Netzwerke und Enterprise-Funktionen
- Notwendige Codeanpassungen sowie Ziel- und Betriebsanforderungen
Ablauf
Heroku-Anwendung und Daten parallel auf dem Ziel validieren
Heroku bleibt bis zur technischen Abnahme und geplanten Umschaltung als Rückfallmöglichkeit bestehen.
- 01
Heroku inventarisieren
Apps, Prozesse, Builds, Variablen, Add-ons, Daten, Domains und Pipelines erfassen.
- 02
Ziel bereitstellen
Container, Prozesse, Datenservices, Netzwerk, TLS, Backups und Monitoring aufbauen.
- 03
Testmigration durchführen
Code deployen, Daten testweise übertragen und Web-, Worker-, Job- und Integrationspfade validieren.
- 04
Daten und DNS umschalten
Schreibfenster koordinieren, finalen Datenstand übernehmen, Traffic wechseln und Rückfallpunkt halten.
Was wir für die Einordnung benötigen
- Heroku-Apps, Pipelines, Repositories und verwendete Buildpacks
- Procfile, Dyno-Typen, Skalierung, Scheduler und Release Tasks
- Liste der Add-ons und externen Integrationen
- Heroku Postgres, weitere Datenbanken und grobe Datenmengen
- Zielwunsch, Wartungsfenster und Betrieb nach dem Wechsel
Einstiegspreis
Heroku-Migration ab 1.990 € netto
1.990 € netto sind der Einstieg für eine klar abgrenzbare Heroku-Anwendung. Das verbindliche Angebot richtet sich nach Prozessen, Add-ons, Daten, Zielarchitektur und Cutover-Anforderungen.
Der Einstiegspreis ist kein pauschales Komplettpaket. Bei mehreren Apps, unbekannten Add-ons oder offenem Ziel kann zunächst der PaaS Exit Review ab 1.490 € netto sinnvoll sein.
Alle Preise verstehen sich netto zuzüglich gesetzlicher Umsatzsteuer. Die Angebote richten sich an Unternehmen.
Individuell eingeordnete Heroku-Migration
Für den kontrollierten Wechsel einer abgegrenzten Heroku-Anwendung auf eine vorbereitete Zielumgebung.
Preisbestimmende Faktoren
- Apps, Dyno-Typen, Pipelines und Umgebungen
- Buildpacks, Procfile und notwendige Containerisierung
- Heroku Postgres und weitere Datenprodukte
- Add-ons, Integrationen und externe Abhängigkeiten
- Zielplattform, Verfügbarkeit und Betriebsmodell
- Test-, Cutover- und Rückfallanforderungen
Passende Anschlüsse
Zielplattform, Daten und laufenden Betrieb gemeinsam planen
Je nach Plattformtiefe beginnt der Heroku Exit mit einem Review oder führt direkt zur Migration und einer betreuten Zielplattform.
PaaS Exit Review
Dynos, Add-ons, Daten, Zieloptionen und Cutover vor der Umsetzung dokumentiert bewerten.
Review ansehenCoolify Managed Hosting
Web-, Worker- und Datenbankdienste über Git auf betreuter Infrastruktur weiterführen.
Coolify ansehenSoftware-Wartung
Dependencies, CVEs, Fehler, Reviews und Releases der migrierten Anwendung laufend betreuen lassen.
Software-Betreuung ansehenHäufige Fragen zur Heroku-Migration
Dynos, Procfile, Buildpacks, Add-ons, Postgres und Zielbetrieb
- Eine Heroku-Migration beginnt bei 1.990 Euro netto. Der Einstiegspreis ist kein pauschaler Festumfang. Apps, Dyno-Typen, Buildpacks, Add-ons, Daten, Zielarchitektur und Cutover bestimmen das konkrete Angebot.
- Die im Procfile definierten Startbefehle sind eine wichtige Grundlage. Web-, Worker-, Clock- und Release-Prozesse werden im Ziel jedoch bewusst als getrennte Anwendungen, Services oder Jobs konfiguriert. Bei mehreren Prozessen ist deshalb keine ungeprüfte Eins-zu-eins-Übernahme sinnvoll.
- Für geeignete Datenbanken können Heroku PGBackups beziehungsweise PostgreSQL Dump und Restore verwendet werden. Bei größeren oder schreibintensiven Datenbanken prüfen wir alternative Synchronisations- und Cutover-Verfahren sowie Versionen, Rollen und Extensions.
- Jedes Add-on wird nach Funktion und Datenhaltung eingeordnet. Manche Dienste können als eigener Open-Source-Service betrieben werden, andere bleiben sinnvollerweise extern oder werden durch einen alternativen Managed Service ersetzt. Zugangsdaten und Endpunkte werden beim Wechsel neu gesetzt.
- Ja. Sie werden im Ziel als eigene Prozesse oder geplante Jobs eingerichtet. Startbefehle, Parallelität, Zeitzone, Retry-Verhalten, Secrets, Logging und Überwachung müssen dabei explizit übernommen oder neu festgelegt werden.
- Ja. Mit Coolify oder einer passenden CI/CD-Strecke kann ein Git-Push weiterhin automatisierte Builds und Deployments auslösen. Staging, Produktion, Freigaben, Health Checks und Rollback werden passend zum Teamprozess eingerichtet.
- Ja. WZ-IT kann Infrastruktur, Deployment-Plattform, Datenservices, Monitoring, Backups, Updates und Incident-Reaktion betreiben. Software-Wartung und Weiterentwicklung bleiben ein separat vereinbarter Anwendungsumfang.
Bewertungen & Projekte
Migrationen mit messbarem Ergebnis
Cloud-Exit, Proxmox und souveräner Betrieb mit konkreten Ergebnissen statt nur Architekturfolien.
WZ-IT hat unsere Studio-Infrastruktur von dezentralen Einzelgeräten auf eine zentrale Plattform gehoben: Jeder Standort ist per VPN sicher angebunden, neue Geräte werden automatisiert onboardet und ein kompletter Standort wird per Vorlage provisioniert - ohne manuelle Schritte vor Ort. Was mich am meisten beeindruckt hat, ist die Breite und Tiefe des Wissens: Timo und Robin sind kein normaler IT-Dienstleister, der einen Server aufsetzt und wieder geht. Die beiden denken sich in hochkomplexe Infrastruktur- und Softwarethemen rein, arbeiten sich in jede Anforderung ein, die wir ihnen hinlegen, und bauen Vernetzung, Provisioning und Betrieb so auf, dass am Ende alles zusammenpasst. WZ-IT ist ein hervorragender Partner, wenn es um komplexe Software-, Netzwerk- und Architekturprojekte geht.
Steve KirchnerGeschäftsführer, nextGYM GmbH
International
Gebaut im Ruhrgebiet. Produktiv weltweit.
WZ-IT plant, entwickelt und betreibt Infrastruktur und Software für Kunden in Deutschland und international. Projekte setzen wir remote um und begleiten sie auch nach dem Go-live im laufenden Betrieb.
Ausgewählte Projekte
- LiveRemote-Access-Plattform für verteilte WasseraufbereitungsanlagenABCO Water Systems · Australien · Secure Access & OT
- 81%AWS-Migration mit deutlich geringeren laufenden KostenEVA Real Estate · VAE · Cloud-Exit & Infrastruktur
- 98%Neue Standorte in Minuten statt Stunden bereitstellennextGYM GmbH · Deutschland · Automatisierung & IoT
Kundenstimmen ansehen
- Cloud-Kosten senken - bis −81 %
- HA-Proxmox-Cluster aufbauen
- Mit Managed Proxmox virtualisieren
- Proxmox & Backup absichern lassen
- Souveräne Infrastruktur modernisieren
- Souveränen Open-Source-Stack planen
- Lokale KI-Lösung integrieren
- Legacy-Software modernisieren
- Open-Source-KI-Architektur entwerfen
- Kollaboration managen lassen
- Vom Prototyp in den Betrieb
- Standorte und Cluster sicher verbinden
Heroku-Migration anfragen
Welche Heroku-Anwendung soll migriert werden?
Nennen Sie Apps, Prozesse, Add-ons, Daten und Zielwunsch. Wir prüfen, ob eine direkte Migration oder zunächst ein Exit Review sinnvoll ist.
