Heroku Postgres migrieren, ohne Maintenance-Window

Jeder andere Teil einer Heroku-Migration ist mechanisch: Config Vars kopieren und einfügen, das Procfile liest sich gleich, Buildpacks bauen die App unverändert. Die Datenbank ist das eine Stück, über das sich Leute tatsächlich Sorgen machen, weil es das eine Stück ist, bei dem „es hat nicht funktioniert” verlorene Daten bedeutet, nicht nur ein erneutes Deploy.

Es ist langweiliger, als es klingt. Hier ist genau, was passiert.

Was der Importer tatsächlich macht

Applications → Import liest einen Heroku-Account über einen API-Token aus und zeigt einen Plan pro App, bevor irgendetwas läuft — was rüberkommt, was du selbst noch hinzufügen musst. Speziell für Heroku: Config Vars, die volle Formation (Prozesstypen und ihre Anzahl), und Postgres-, Redis-, MySQL- und Memcached-Add-ons kommen alle rüber, zusammen mit eigenen Domains.

Das Einzige, was Herokus API wirklich nicht rausgeben kann, ist die Git-URL selbst — Heroku zeigt dein Repository nicht an, also ist das das eine Feld, das du beim Import selbst angibst.

Wie die Daten tatsächlich umziehen

Die Datenbank wird kopiert, indem ein Dump direkt von Herokus DATABASE_URL in die neue managed Postgres-Datenbank auf Railyard gestreamt wird — kein manuelles pg_dump auf einen Laptop und zurück, sondern ein direkter Stream zwischen den beiden. Das zählt, weil es bedeutet, dass während der Migration keine mehrstündige Datei auf irgendjemandes Festplatte als die eine Kopie der Produktionsdaten herumliegt.

Die Sequenz, die tatsächlich Downtime vermeidet:

1. Den Import ausführen. Die neue App existiert, konfiguriert, mit ihrer eigenen frischen Datenbank, die schon von der alten streamt.
2. Die Heroku-App die ganze Zeit weiterlaufen lassen. Nichts am Import stoppt sie.
3. Sobald die neue DATABASE_URL korrekt antwortet und du sie gegen die alte verifiziert hast, DNS umziehen.
4. Erst dann die Heroku-Dynos suspendieren — nach dem Cutover, nicht davor.

Es gibt kein Maintenance-Window zu planen, weil es keinen Moment gibt, in dem keine der beiden Datenbanken den Traffic bedient. Die alte antwortet weiter, bis die neue bewiesen ist, und der Wechsel selbst ist eine DNS-Änderung, kein Downtime-Ereignis.

Was immer noch einen Menschen braucht

Secrets, die als Heroku-Config-Vars gespeichert sind, kommen mit allem anderen rüber — aber wenn deine App Credentials von irgendwo holt, das Herokus API nicht offenlegt (ein von einem Buildpack injizierter Wert, etwas komplett außerhalb der Config Vars gesetzt), musst du das selbst nochmal prüfen. Und wenn die Datenbank Extensions über Standard-Postgres hinaus hat — pgvector, PostGIS — bestätige, dass das Ziel sie unterstützt, bevor du umschaltest, nicht danach.

Für den schnellsten Weg lässt sich die Ausgabe von heroku config -s direkt in Variables → Bulk import einfügen, falls du irgendeinen Teil davon von Hand statt über den Importer machst.

Vollständiges Mapping für jede Quellplattform: Import von Heroku, Render, Fly oder Railway und die komplette Anleitung unter Migration von Heroku.