Modernisieren bei laufendem Betrieb – ohne Ausfall

Ein produktives System offline nehmen, um es zu modernisieren? Fast nie nötig. So gelingt die Modernisierung ohne Ausfall – in kleinen, sicheren Schritten statt im großen Big-Bang.

Die häufigste Frage, die mir Geschäftsführer und IT-Leiter stellen, lautet sinngemäß: "Wenn wir das jetzt anfassen, steht dann alles still?" Dahinter steckt eine berechtigte Angst. Das System, um das es geht, verarbeitet Bestellungen, Rechnungen oder Patientendaten – und es läuft. Seit Jahren. Genau das ist der entscheidende Punkt: Ein System, das seit Jahren zuverlässig läuft, ist kein Müll. Es ist der lebende Beweis, dass die Fachlogik funktioniert. Das Problem ist fast nie diese Logik, sondern der Code drumherum – veraltete Frameworks, fehlende Tests, unklare Abhängigkeiten.

Die gute Nachricht: Modernisieren bei laufendem Betrieb ist nicht nur möglich, es ist in den meisten Fällen der günstigere und sicherere Weg als eine Neuentwicklung. Man muss es nur richtig aufziehen.

Warum Modernisierung ohne Ausfall der Normalfall sein sollte

Der Big-Bang-Ansatz – altes System aus, neues System an – klingt sauber, ist aber die riskanteste Variante überhaupt. Er verlangt, dass Sie jahrelang gewachsene Fachlogik vollständig verstehen und fehlerfrei neu bauen, bevor der erste Nutzer den Unterschied merkt. Jede undokumentierte Sonderregel, jeder Workaround, der irgendwann einen realen Geschäftsfall gerettet hat, muss dabei mitwandern. Übersehen Sie einen davon, fällt es erst im Live-Betrieb auf.

Modernisierung ohne Ausfall dreht die Logik um: Sie verändern das laufende System in kleinen, jederzeit rückrollbaren Schritten. Nach jedem Schritt ist das System weiterhin produktiv. Es gibt keinen Stichtag, an dem alles gut gehen muss – es gibt nur viele kleine Schritte, von denen jeder einzelne sicher ist.

Erste Voraussetzung: ein Sicherheitsnetz, bevor Sie etwas ändern

Bevor Sie eine einzige Zeile am produktiven Code anfassen, brauchen Sie eine Möglichkeit, Fehler zu bemerken, bevor Ihre Kunden es tun. In der Praxis heißt das drei Dinge:

  • Charakterisierungstests: Tests, die nicht prüfen, was der Code tun sollte, sondern was er aktuell tut. Sie zementieren das heutige Verhalten – inklusive Eigenheiten – als Referenz, gegen die Sie jede Änderung absichern.
  • Ein realitätsnahes Staging: eine Umgebung mit anonymisierten, aber echten Datenmengen. Legacy-Bugs zeigen sich oft erst bei realistischen Daten, nicht bei drei sauberen Testdatensätzen.
  • Deployments, die Sie in Minuten zurückrollen können: Wenn ein Rollback eine halbe Stunde und Nervenkitzel kostet, trauen Sie sich keine kleinen Schritte mehr. Genau die brauchen Sie aber.

Dieses Netz ist kein optionaler Luxus. Es ist die Bedingung dafür, dass "ohne Ausfall" mehr als ein Versprechen ist.

Die Strangler-Fig-Strategie: das System Stück für Stück umbauen

Das bewährtste Muster für Modernisierung ohne Ausfall ist die sogenannte Strangler-Fig-Strategie, benannt nach der Würgefeige, die einen Baum langsam umwächst, bis sie ihn ersetzt. Übertragen auf Software heißt das: Sie legen neuen, sauberen Code um das alte System herum und leiten nach und nach einzelne Funktionen dorthin um.

Wie sieht das konkret in einer PHP-Anwendung aus? Sie setzen einen Einstiegspunkt vor die Anwendung, der Requests entweder ans alte oder ans neue System routet. Eine typische Reihenfolge:

  1. Sie wählen eine klar abgegrenzte Funktion mit wenig Verflechtung – etwa den Rechnungs-Export oder die Registrierung.
  2. Sie bauen diese Funktion sauber neu, oft in einem modernen Framework wie Symfony oder Laravel, hinter demselben Endpunkt.
  3. Sie leiten erst intern, dann für einen Teil der Nutzer, dann für alle auf die neue Implementierung um.
  4. Erst wenn die neue Version stabil läuft, entfernen Sie den alten Code.

Der entscheidende Vorteil: Zu jedem Zeitpunkt ist genau ein Teil in Bewegung. Geht etwas schief, betrifft es eine Funktion, nicht das ganze System – und Sie routen einfach zurück auf den alten Pfad.

Was Sie zuerst modernisieren – und was Sie in Ruhe lassen

Nicht alles muss angefasst werden, nur weil es alt ist. Alter Code, der stabil läuft und selten geändert wird, ist selten das dringendste Problem. Priorisieren Sie stattdessen dort, wo Alter echten Schmerz verursacht:

  • Sicherheit zuerst: Eine PHP-Version ohne Sicherheitsupdates oder ein Framework am End-of-Life ist ein akutes Risiko, kein Schönheitsfehler. Das gehört nach vorne.
  • Stellen, die häufig geändert werden: Wo Ihr Team ständig arbeitet und sich ständig blockiert, zahlt sich sauberer Code sofort aus.
  • Datenbank-Zugriffe und Abhängigkeiten: Direkte, ungesicherte SQL-Abfragen oder uralte Bibliotheken sind oft die Wurzel von Sicherheits- und Stabilitätsproblemen.

Ein pragmatischer Zwischenschritt ist die reine Runtime-Modernisierung: die Anwendung auf eine aktuelle, unterstützte PHP-Version heben, ohne die Architektur anzufassen. Das schließt die dringendsten Sicherheitslücken oft in Wochen statt Monaten – und verschafft Ihnen Luft für den strukturellen Umbau.

Datenbank-Änderungen ohne Ausfall: das unterschätzte Risiko

Beim Code denken die meisten an Ausfallrisiken. Bei der Datenbank nicht – und dort lauern die härtesten Fallen. Eine Änderung am Schema kann eine große Tabelle sperren und die Anwendung für Minuten lahmlegen.

Der sichere Weg sind abwärtskompatible Migrationen in mehreren Schritten. Eine Spalte umbenennen heißt dann nicht "umbenennen", sondern: neue Spalte anlegen, in beide schreiben, Daten migrieren, Lesen umstellen, alte Spalte erst viel später entfernen. Jeder einzelne Schritt ist für sich harmlos und lässt sich zurückrollen. Für das Sperrproblem gibt es bei MySQL und PostgreSQL Online-Schema-Change-Werkzeuge, die Änderungen ohne Vollsperre durchführen.

Faustregel: Der neue Code muss mit dem alten Schema laufen können, und das alte Schema muss mit dem neuen Code laufen können. Diese Überlappung ist das, was Rollbacks überhaupt erlaubt.

Ehrlicher Praxis-Tipp zum Schluss

Der größte Fehler ist nicht der falsche technische Ansatz. Es ist, den Umbau als einmaliges Projekt mit Enddatum zu behandeln. Modernisierung ohne Ausfall funktioniert, wenn sie zur Gewohnheit wird: bei jeder ohnehin anstehenden Änderung ein Stück mehr aufräumen, statt einmal im Jahr ein großes, riskantes Refactoring anzusetzen. Fangen Sie klein an, mit einer unkritischen Funktion, und lernen Sie an ihr, wie Ihr System auf Veränderung reagiert. Und wenn Sie unsicher sind, wo Sie den ersten Schnitt ansetzen sollen, ohne etwas kaputtzumachen – genau bei dieser Analyse und dem sicheren Umbau unterstützt LegacyWerk.

Strangler-Fig: Umbau bei laufendem Betrieb Requests Router Altes System (Legacy) Neuer, sauberer Code Schrittweise mehr Funktionen umleiten Start: fast alles alt System bleibt live Ziel: alles neu kein Big-Bang

Ist Ihre PHP-Anwendung noch zu retten?

Im kostenlosen Kurz-Check schaue ich mit Ihnen auf Ihr System und sage Ihnen ehrlich, was möglich ist – unverbindlich und ohne Verkaufsdruck.

Kurz-Check vereinbaren