Die meisten Migrationen scheitern nicht an der Migration selbst. Sie scheitern in der Nacht, in der etwas Unerwartetes passiert und niemand weiß, wie man zurück auf das alte System kommt. Ein System, das seit Jahren im Produktivbetrieb läuft, ist kein Müll, den man endlich loswird. Es ist der lebende Beweis, dass die Fachlogik funktioniert. Genau deshalb verdient es einen sauberen Rückweg, falls der neue Stand Probleme macht.
Ein durchdachtes PHP Migration Rollback ist keine Kapitulation. Es ist die Voraussetzung dafür, dass Sie eine Migration überhaupt guten Gewissens starten können. Wer keinen Plan B hat, migriert unter Druck, trifft nachts schlechte Entscheidungen und behält am Ende ein halb migriertes System, das niemand mehr versteht.
Warum jede PHP-Migration einen Rollback-Plan braucht
Der Denkfehler ist fast immer derselbe: Man plant die Migration bis zum Go-Live und behandelt alles danach als Detail. Dabei entscheidet sich der Erfolg genau in den ersten Stunden nach der Umstellung. Ein Cronjob, der auf der alten PHP-Version lief und jetzt eine Deprecation als Fatal Error wirft. Ein Zahlungsanbieter, dessen SDK die neue Symfony-Version nicht mag. Eine Session-Serialisierung, die sich zwischen PHP 7.4 und 8.3 verändert hat und plötzlich alle Nutzer ausloggt.
Das Problem ist dabei selten die Fachlogik. Die Berechnung Ihrer Rabatte oder die Regeln Ihrer Rechnungsstellung funktionieren seit Jahren. Was bricht, ist der Code drumherum: das Framework, die Bibliotheken, die Infrastruktur. Ein Rollback gibt Ihnen die Ruhe, diese Randprobleme in Ruhe zu lösen, statt sie um drei Uhr morgens zu improvisieren.
Was ein PHP Migration Rollback konkret abdecken muss
Ein Rollback ist nicht nur "die alte Version wieder deployen". Ein vollständiger Plan denkt in drei Schichten, die alle gleichzeitig zurückgerollt werden müssen, damit das System konsistent bleibt.
- Anwendungscode: Der alte Stand muss jederzeit wieder deploybar sein. Bei einem Blue-Green-Deployment oder mit getaggten Releases ist das eine Sache von Minuten.
- Datenbankschema: Die schwierigste Schicht. Jede Migration, die Spalten löscht oder umbenennt, macht einen einfachen Code-Rollback unmöglich, weil der alte Code die geänderte Struktur nicht mehr versteht.
- Abhängigkeiten und Konfiguration: PHP-Version, Extensions, Umgebungsvariablen, Cache-Struktur. Ein Rollback des Codes nützt nichts, wenn der Server noch auf der neuen PHP-Version läuft und die alten Dependencies nicht mehr installiert sind.
Wie halten Sie die Datenbank rollback-fähig?
Machen Sie Datenbankänderungen abwärtskompatibel, statt destruktiv. Das ist der wichtigste einzelne Hebel für ein funktionierendes Rollback, weil Daten sich nicht so einfach zurückspielen lassen wie Code.
Der Schlüssel ist das Expand-and-Contract-Muster (auch Parallel-Change genannt). Sie trennen eine riskante Schemaänderung in mehrere, jeweils harmlose Schritte:
- Expand: Sie fügen die neue Spalte additiv hinzu, ohne die alte zu entfernen. Das alte System läuft unverändert weiter.
- Migrate: Der neue Code schreibt in beide Spalten oder liest aus der neuen. Beide Stände sind gleichzeitig lauffähig.
- Contract: Erst wenn die neue Version über Tage stabil läuft, entfernen Sie die alte Spalte in einer separaten, späteren Migration.
In der kritischen Phase direkt nach dem Go-Live gibt es also keine destruktive Änderung. Ein Rollback auf den alten Code funktioniert, weil die alte Spalte noch existiert. Ob Sie Doctrine Migrations unter Symfony oder die Laravel-Migrations nutzen, spielt keine Rolle: Das Prinzip ist framework-unabhängig. Wichtig ist nur, dass eine einzelne Migration niemals gleichzeitig ein Feld hinzufügt und ein anderes löscht.
Faustregel: Solange der alte Code auf dem neuen Schema laufen könnte, ist Ihr Rollback sicher. Sobald das nicht mehr gilt, haben Sie einen Point of no Return überschritten, und den sollten Sie bewusst und dokumentiert setzen, nicht versehentlich.
Wie sieht ein realistischer Rollback-Ablauf aus?
Ein Rollback muss geübt sein, nicht nur dokumentiert. Ein Runbook, das noch nie durchgespielt wurde, ist im Ernstfall wertlos. Ein praktikabler Ablauf besteht aus vier Punkten:
- Definierte Abbruchkriterien: Legen Sie vorher fest, was ein Rollback auslöst. Zum Beispiel: Fehlerrate über einem Schwellwert, kritischer Geschäftsprozess wie Checkout nicht funktionsfähig, oder Antwortzeiten dauerhaft zu hoch. So diskutiert niemand im Krisenmoment, ob es "noch geht".
- Ein Kommando, kein Bastelwerk: Der Rückweg sollte ein bekannter, getesteter Schritt sein: das vorherige Release-Tag deployen, den Loadbalancer zurückschwenken, den Feature-Flag deaktivieren.
- Feature-Flags statt harter Umschaltung: Wenn Sie neue Codepfade hinter einem Flag ausrollen, ist der Rollback ein Config-Wert, kein Deployment. Das ist der schnellste denkbare Rückweg.
- Daten seit dem Go-Live: Klären Sie vorab, was mit Bestellungen oder Datensätzen passiert, die zwischen Go-Live und Rollback entstanden sind. Das Expand-and-Contract-Muster hilft, weil diese Daten im gemeinsamen Schema erhalten bleiben.
Warum ein guter Rollback-Plan die Neuentwicklung überflüssig macht
Viele Teams greifen zur kompletten Neuentwicklung, weil sie sich eine schrittweise Migration nicht zutrauen. Der eigentliche Grund ist oft fehlendes Vertrauen in den Rückweg: Man traut sich nicht, das laufende System anzufassen, also baut man daneben ein neues. Das ist in der Regel die teuerste und riskanteste Option, weil Sie dabei Jahre erprobter Fachlogik neu erfinden und dabei zwangsläufig Fehler wieder einführen, die längst gelöst waren.
Ein belastbares Rollback dreht diese Logik um. Wenn Sie jederzeit sicher zurückkönnen, können Sie das bestehende System in kleinen, umkehrbaren Schritten modernisieren. Sie migrieren die PHP-Version, dann das Framework, dann einzelne Module. Jeder Schritt ist für sich getestet und für sich rücksetzbar. Das Risiko verteilt sich auf viele kleine Etappen statt auf einen einzigen großen Sprung ins Ungewisse.
Der ehrliche Praxis-Tipp
Bauen Sie das Rollback zuerst, bevor Sie die erste Zeile migrieren. Deployen Sie den unveränderten alten Stand einmal über Ihren neuen Prozess, rollen Sie ihn testweise zurück und stoppen Sie die Zeit. Erst wenn dieser Rückweg nachweislich funktioniert, hat Ihre Migration ein Sicherheitsnetz. Alles andere ist ein Sprung ohne Seil.
Genau bei solchen Übergängen, wo ein bewährtes System sauber und ohne Blindflug modernisiert werden soll, unterstützt LegacyWerk mit Erfahrung aus vielen geretteten PHP-Anwendungen.
