So migrierst du 2026 von Heroku zu einer Multicloud-PaaS

Am 6. Februar 2026 gab Salesforce bekannt, dass Heroku in den „Sustaining Engineering“-Modus wechselt. Es gibt keine neuen Features und keine neuen Enterprise-Verträge für Neukunden mehr. Bestehende Kunden sind vorerst nicht betroffen: Preise, Abrechnung und der tägliche Service laufen wie bisher weiter. Für Teams, die noch darauf arbeiten, stellt sich nun eine praktische Frage: Was bedeutet ein Wechsel weg von Heroku? Dieser Beitrag geht konkret darauf ein.

Was „Sustaining Engineering“ bedeutet

Folgendes hat sich geändert:

• Es werden künftig keine neuen Features mehr entwickelt. Die Roadmap ist defensiv ausgerichtet: ausschließlich Sicherheitspatches, Stabilitätskorrekturen und Infrastrukturwartung.
• Keine neuen Enterprise-Verträge für Neukunden. Bestehende Enterprise-Kunden können ihre Verträge weiterhin verlängern.
• Für bestehende Kunden mit Kreditkartenabrechnung ändert sich nichts an Preisen, Abrechnung oder Service.
• Heroku hat kein Datum für die Einstellung des Dienstes bekannt gegeben, und nichts in den Berichten über die Ankündigung deutet darauf hin, dass dies unmittelbar bevorsteht.

In der Praxis bedeutet das, dass eine Plattform in diesem Modus künftig nicht mehr in neue Compliance-Zertifizierungen, die Unterstützung neuer Programmiersprachen oder neue Infrastrukturfunktionen investieren wird. Für ein Team, das mehr als ein oder zwei Jahre im Voraus plant, lohnt es sich, dies bei einer Infrastrukturentscheidung zu berücksichtigen – auch wenn keine unmittelbare Dringlichkeit für eine Migration besteht.

Warum auf eine Multicloud-PaaS migrieren?

Die meisten Heroku-Migrationsanleitungen verweisen auf Railway, Render oder Fly.io. Alle drei sind gute Plattformen, und alle drei haben eines mit Heroku gemeinsam: Jede läuft auf ihrer eigenen, eigenständigen Infrastruktur. Der Wechsel von Heroku zu einer dieser Plattformen beseitigt zwar das Heroku-spezifische Risiko (eine Plattform, die nicht mehr weiterentwickelt wird), aber nicht das zugrunde liegende Risiko, nämlich die Abhängigkeit von einem einzigen Anbieter, der darüber entscheidet, wo deine Anwendung überhaupt laufen kann.

Ein Multicloud-PaaS ändert diese Gleichung. Upsun Cloud beispielsweise stellt dieselbe Anwendungskonfiguration auf AWS, Azure, Google Cloud, IBM Cloud oder OVHcloud bereit. Heroku hingegen lief schon immer ausschließlich auf einer begrenzten Anzahl von AWS-Regionen, was an sich schon eine der Einschränkungen ist, von denen Teams wegziehen. Der Wechsel zu einer Plattform, die auf mehr als einem Anbieter laufen kann, bedeutet, dass die nächste Migration – falls sie jemals nötig sein sollte – lediglich darin besteht, dieselbe Konfiguration bei einem anderen Anbieter neu bereitzustellen, und nicht in einer weiteren kompletten Neuprogrammierung.

Die Migrationszuordnung zu Upsun Cloud

Die gute Nachricht: Die Kernkonzepte von Heroku lassen sich ziemlich direkt auf Upsun Cloud übertragen. Insbesondere das Procfile-Muster lässt sich nahtlos umsetzen. Das sollte klar gesagt werden, da „Migration“ oft als Synonym für „Neuprogrammierung“ behandelt wird: Die Definition deiner Anwendung in die deklarative Konfigurationsdatei von Upsun Cloud zu übertragen, ist nicht dasselbe wie die Neuprogrammierung ihrer Logik. Der Anwendungscode selbst ändert sich in der Regel nicht; was sich ändert, ist die Art und Weise, wie die Laufzeitumgebung, die Dienste und die Verbindungen beschrieben werden.

• Die Procfile-Prozesstypen (web, worker, release) entsprechen den Anwendungs- und Dienstdefinitionen in der Datei .upsun/config.yaml von Upsun Cloud. Ein Web-Prozesstyp wird zum Webdienst der Anwendung; ein Worker wird zu einem Hintergrund-Worker-Dienst, der auf dieselbe Weise definiert ist.
• Dynos entsprechen Containern, die Upsun Cloud entsprechend deiner Konfiguration bereitstellt. Während Heroku-Dynos nach festen Stufen (Eco, Basic, Standard, performance) abgerechnet werden, kannst du bei der bereitstellungsbasierten Preisgestaltung von Upsun Cloud genau die CPU und den Arbeitsspeicher angeben, die ein Dienst benötigt, anstatt schon bei einer einzigen Ressourcenerhöhung in die nächste Stufe zu springen.
• Add-ons werden größtenteils zu integrierten Plattformfunktionen und sind nicht mehr nur ein Marktplatz für separate Dienste. Persistenter Speicher, Cron-Jobs, DDoS-Schutz und backups sind in der Regel direkt in die Plattform integriert und erfordern kein separates Add-on mit eigener Kostenposition. Add-ons von Drittanbietern, die sich über einen API-Schlüssel verbinden (Überwachungstools, E-Mail-Dienste), funktionieren nach der Migration in der Regel weiter, da die entsprechenden Umgebungsvariablen übernommen werden – das sollte jedoch für jedes Add-on einzeln überprüft werden und nicht pauschal angenommen werden.
• Konfigurationsvariablen werden in Upsun Cloud direkt als Umgebungsvariablen übernommen.
• Heroku Postgres wird über den Standardprozess pg_dump/pg_restore auf den verwalteten PostgreSQL-Dienst von Upsun Cloud migriert. Dies ist in der Regel der risikoreichste Schritt der gesamten Migration und erfordert mehr Sorgfalt und Testzeit als die Konfigurationsumsetzung.
• Review Apps werden den Preview-Umgebungen zugeordnet, wobei sich die Vorgehensweise jedoch erheblich unterscheidet: Bei den Review Apps von Heroku müssen die Daten manuell in jede einzelne geladen werden, während Upsun Cloud die Datenbank, Dateien und Dienste automatisch pro Branch Byte für Byte klont.
• Die DNS-Umstellung ist der letzte Schritt, sobald die Upsun-Cloud-Umgebung anhand der Muster des Produktionstraffics validiert wurde.

Was sich bei Upsun Cloud ändert

Ein paar Dinge, die als echte Verhaltensänderungen hervorzuheben sind:

• Persistenter Speicher. Die Dynos von Heroku verfügen über keinen eigenen persistenten Speicher; alles, was einen Neustart überstehen muss, muss in einem externen Dienst wie S3 gespeichert werden. Upsun Cloud bietet nativ persistenten Speicher und macht so die Einrichtung und Wartung dieser zusätzlichen Infrastruktur überflüssig.
• Dyno-Zyklus. Heroku startet Dynos mindestens alle 24 Stunden neu, wodurch der Speicherzustand verloren geht und lang andauernde Verbindungen unterbrochen werden können. Upsun Cloud startet Container nur bei der Bereitstellung neu, nicht nach einem festen Zeitplan, wodurch eine Reihe von sporadischen Problemen beseitigt wird, für die Teams heute noch Workarounds entwickeln müssen.
• Zeitüberschreitungen bei Anfragen. Heroku erzwingt eine nicht konfigurierbare Antwortzeit von 30 Sekunden. Upsun Cloud legt diese Grenze nicht fest, was für alle Vorgänge wichtig ist, die große Datei-Uploads oder lang andauernde Anfragen beinhalten – es lohnt sich, das tatsächliche Verhalten deiner Anwendung vor der Migration zu überprüfen.

Häufige Migrationsrisiken

• Die Datenmigration ist der risikoreichste Schritt, nicht die Konfigurationsumsetzung. Teste den Postgres-Dump-/Restore-Prozess anhand einer Kopie der Produktionsdaten rechtzeitig vor der eigentlichen Umstellung, nicht währenddessen.
• Überprüfe alles auf einem Klon, bevor du die Produktivumgebung berührst. Anstatt eine Migration in einer Staging-Umgebung zu testen, die die Produktivumgebung nur annähernd nachbildet, deckt das Testen der migrierten Konfiguration anhand eines vollständigen Klons der Produktionsdaten und -dienste auf einem Upsun-Cloud-Zweig Probleme auf, die bei der reinen Konfigurationsumsetzung allein nicht zutage treten würden.
• Add-ons von Drittanbietern müssen einzeln überprüft werden. Add-ons, die über API-Schlüssel und Umgebungsvariablen verbunden sind, funktionieren in der Regel weiter, sobald diese Variablen übernommen wurden – aber „in der Regel“ heißt nicht „immer“, und jedes einzelne sollte explizit überprüft werden.
• Migre nicht alles auf einmal. Wenn du zuerst eine einzelne, nicht kritische Anwendung umstellst, dich mit dem Bereitstellungs-Workflow von Upsun Cloud vertraut machst und erst dann die Produktionssysteme migrierst, verringert das das Ausmaß möglicher Überraschungen.

Häufig gestellte Fragen (FAQs)

Bedeutet die Migration weg von Heroku, dass ich meine Anwendung neu schreiben muss? Normalerweise
nicht. Die Logik der Anwendung bleibt in der Regel gleich; was sich ändert, ist die Art und Weise, wie ihre Laufzeitumgebung, Dienste und Verbindungen beschrieben werden – der Übergang vom Heroku-Modell zur deklarativen Konfigurationsdatei von Upsun Cloud. Insbesondere die Zuordnung von Procfile zu Diensten lässt sich direkt übersetzen, ohne dass eine Neuprogrammierung erforderlich ist.

Lässt sich mein Heroku-Procfile direkt auf die Konfiguration von Upsun abbilden?
Das Konzept schon. Prozesstypen (web, worker, release) werden in Dienstdefinitionen in der Datei .upsun/config.yaml von Upsun Cloud übersetzt, wobei sich die genaue Syntax unterscheidet und eine Neufassung erforderlich ist – ein einfaches Kopieren reicht nicht aus.

Was passiert mit meinen Heroku-Postgres-Daten?
Sie werden über einen Standard-Datenbank-Dump und eine Wiederherstellung in den verwalteten PostgreSQL-Dienst von Upsun Cloud migriert. Dies ist der Schritt, der am ehesten zusätzliche Testzeit erfordert, da dabei tatsächliche Produktionsdaten und nicht nur Konfigurationen verschoben werden.

Muss ich alles auf einmal migrieren?
Nein, und das ist im Allgemeinen auch nicht ratsam. Die Migration einer kleineren, nicht kritischen Anwendung zu Beginn ermöglicht es einem Team, den Bereitstellungs-Workflow von Upsun Cloud zu validieren, bevor der Produktionsverkehr umgestellt wird.

Warum auf eine Multicloud-PaaS migrieren statt auf eine andere Single-Cloud-Alternative wie Railway oder Render? Die
Migration auf eine andere Single-Cloud-Plattform löst zwar das spezifische Problem, dass Heroku nicht mehr weiterentwickelt wird, beseitigt aber nicht das zugrunde liegende Risiko, bei der Ausführung einer Anwendung von einem einzigen Anbieter abhängig zu sein. Upsun Cloud, das dieselbe Konfiguration auf AWS, Azure, Google Cloud, IBM Cloud oder OVHcloud bereitstellt, bedeutet, dass ein zukünftiger Anbieterwechsel keine weitere vollständige Migration erfordert.

Werden meine Add-ons von Drittanbietern nach der Migration weiterhin funktionieren? Die
meisten Add-ons, die über einen API-Schlüssel und Umgebungsvariablen verbunden sind, funktionieren auf Upsun Cloud weiter, sobald diese Variablen übernommen wurden. Das solltest du jedoch Add-on für Add-on überprüfen, anstatt es pauschal für den gesamten Stack anzunehmen.