Legacy-PHP modernisieren ohne Big-Bang

Fast jedes gewachsene Unternehmen hat sie: eine Software, die seit Jahren läuft, geschäftskritisch ist — und die niemand mehr gern anfasst. Die Versuchung ist groß, sie komplett neu zu bauen. In den meisten Fällen ist das die teuerste und riskanteste Option. Dieser Beitrag zeigt, wie man Legacy-PHP stattdessen Schritt für Schritt modernisiert, ohne den Betrieb zu gefährden.

Warum der Komplett-Neubau so oft scheitert

Der „Big-Bang” — alte Software stilllegen, neue Software live schalten — klingt verlockend sauber. In der Realität bringt er drei Probleme mit:

Sie bauen Jahre an Geschäftslogik nach, die niemand vollständig dokumentiert hat. In der alten Anwendung stecken unzählige Sonderfälle, die im Tagesgeschäft entstanden sind. Genau diese Fälle vergisst ein Neubau zuverlässig — und sie fallen erst im Produktivbetrieb auf.
Während des Neubaus steht die Weiterentwicklung still. Das Geschäft wartet aber nicht. Monatelang nur „nachbauen, was schon da ist”, ist schwer durchzuhalten.
Der Umschalttag ist ein Alles-oder-nichts-Risiko. Geht etwas schief, steht ein geschäftskritisches System.

Die gute Nachricht: Es gibt einen Weg, der das Risiko klein hält.

Schritt 1: Stabilisieren, bevor man verändert

Bevor irgendetwas modernisiert wird, schaffen wir eine sichere Ausgangslage. Das heißt konkret:

Versionskontrolle und reproduzierbare Umgebung. Erstaunlich oft liegt Legacy-Code noch ohne saubere Git-Historie oder ohne lauffähige lokale Umgebung vor. Das ist der erste Hebel.
Ein Sicherheitsnetz aus Tests — nicht für jede Zeile, aber für die kritischen Pfade. Schon eine Handvoll automatisierter Tests rund um die wichtigsten Abläufe verwandelt „Angst vor jeder Änderung” in „wir merken sofort, wenn etwas bricht”.
Monitoring und Logging, damit Fehler im Betrieb sichtbar werden, statt unbemerkt zu bleiben.

Erst wenn dieses Netz steht, beginnt die eigentliche Modernisierung.

Schritt 2: Die Codebasis beherrschbar machen

Veraltete PHP-Versionen sind nicht nur ein Sicherheitsrisiko, sie blockieren auch moderne Werkzeuge. Der Sprung von PHP 5.x oder 7.x auf PHP 8 ist daher oft der erste große Schritt — und dank Tools planbar:

# Statische Analyse deckt Inkompatibilitäten auf, bevor sie im Betrieb auffallen
vendor/bin/phpstan analyse src --level=5

# Automatisierte Migrationen heben großen Teil des Codes auf PHP 8
vendor/bin/rector process src --dry-run

Statische Analyse (z. B. PHPStan) und automatisierte Refactorings (z. B. Rector) nehmen einen Großteil der stumpfen Arbeit ab. Sie zeigen vorab, wo es klemmt, statt dass man es im Produktivbetrieb herausfindet.

Schritt 3: Den Strangler-Fig-Ansatz nutzen

Das wichtigste Muster für risikoarme Modernisierung heißt Strangler Fig: Statt alles auf einmal zu ersetzen, wird die alte Anwendung nach und nach „umwachsen”. Neue oder überarbeitete Funktionen entstehen als saubere Module — etwa hinter einer modernen API — und übernehmen Stück für Stück die Aufgaben des Altsystems. Die alte und die neue Welt laufen parallel, bis das Alte schließlich vollständig abgelöst ist.

Der Vorteil: Jeder Schritt ist klein, einzeln testbar und produktiv nutzbar. Es gibt keinen einzelnen riskanten Umschalttag — und sollte ein Schritt Probleme machen, ist nur ein Modul betroffen, nicht das ganze System.

Schritt 4: Wert vor Eleganz

Ein häufiger Fehler bei Modernisierungen ist der Drang, „alles richtig” zu machen — und sich in Refactorings zu verlieren, die niemand sieht. Modernisierung sollte sich an Geschäftswert orientieren, nicht an technischer Schönheit:

Zuerst die Stellen, die am meisten wehtun (häufige Fehler, Sicherheitslücken, Engpässe).
Dann die Stellen, die Weiterentwicklung blockieren.
Eleganz dort, wo sie sich auszahlt — nicht als Selbstzweck.

So bleibt die Modernisierung jederzeit begründbar und finanzierbar.

Eine ehrliche Bestandsaufnahme am Anfang

Jede gute Modernisierung beginnt mit einer nüchternen Analyse: Wo liegen die Risiken? Was lässt sich retten, was muss ersetzt werden? Welche Teile sind geschäftskritisch, welche kaum noch in Benutzung? Diese Bestandsaufnahme verhindert, dass Aufwand in Code fließt, der ohnehin bald verschwindet.

Genau so gehen wir bei der Legacy-Modernisierung vor: erst stabilisieren und verstehen, dann in sicheren Schritten erneuern — immer im laufenden Betrieb.

Fazit

Legacy-Software ist kein Grund zur Panik und selten ein Fall für den Abriss. Wer zuerst ein Sicherheitsnetz aus Tests und Monitoring spannt, die Codebasis mit modernen Werkzeugen beherrschbar macht und dann nach dem Strangler-Fig-Prinzip Stück für Stück erneuert, modernisiert ohne den gefürchteten Big-Bang — und ohne das Geschäft zu gefährden.

Sie haben ein System, das niemand mehr anfassen mag? Sprechen Sie uns an — wir schauen mit Ihnen auf den Bestand und skizzieren einen Weg, der den Betrieb nie aufs Spiel setzt.