Legacy PHP modernisieren

Legacy PHP modernisieren: Wann sich ein Refactoring lohnt

Ihr System läuft. Seit Jahren. Es verarbeitet Bestellungen, steuert interne Prozesse oder treibt eine Webanwendung an, die täglich genutzt wird. Auf dem Papier funktioniert alles. Aber in der Praxis dauern kleine Änderungen immer länger. Neue Entwickler brauchen Wochen, um sich einzuarbeiten. Sicherheitsupdates bleiben liegen, weil niemand weiß, was dabei kaputtgehen könnte. Und die PHP-Version, auf der das Ganze läuft, bekommt seit Monaten keine Patches mehr.

Wenn Ihnen dieses Szenario bekannt vorkommt, stehen Sie vor einer Entscheidung: Weitermachen wie bisher und das wachsende Risiko tragen? Oder investieren und das System modernisieren?

Dieser Leitfaden hilft Ihnen, diese Entscheidung fundiert zu treffen. Ohne Panikmache, aber mit einer ehrlichen Einschätzung der Kosten, Risiken und Optionen.

Warnsignale: Wann ein PHP-System modernisiert werden muss

Nicht jedes ältere System braucht sofort ein Refactoring. Manche Legacy-Anwendungen laufen stabil und erfüllen ihren Zweck. Aber es gibt klare Warnsignale, bei denen Sie handeln sollten.

1. End-of-Life PHP-Version

Das deutlichste Signal: Ihre Anwendung läuft auf einer PHP-Version, die keine Sicherheitsupdates mehr erhält. Stand April 2026 sind PHP 8.1 und alle älteren Versionen am End-of-Life angelangt. PHP 8.2 erhält nur noch Security-Patches bis Ende 2026 (Quelle: php.net/supported-versions). Alles darunter ist ein offenes Sicherheitsrisiko. Die kritische Schwachstelle CVE-2024-4577 (CVSS 9.8) hat gezeigt, wie real dieses Risiko ist: PHP 7.x und 8.0 blieben ungepatcht, weil sie bereits End-of-Life waren.

2. Steigende Entwicklungszeiten

Änderungen, die früher einen halben Tag dauerten, brauchen jetzt zwei oder drei Tage. Jede Anpassung zieht unerwartete Seiteneffekte nach sich. Der Code ist so eng verzahnt, dass eine Änderung an Stelle A Fehler an Stelle B verursacht. Das ist ein typisches Zeichen für fehlende Trennung der Zuständigkeiten im Code.

3. Fehlende oder unzureichende Tests

Ein häufiger Fehler, den ich in Audits sehe: Es gibt keine automatisierten Tests. Jede Änderung wird manuell getestet, was zeitaufwendig ist und trotzdem Fehler übersieht. Ohne Tests ist jedes Update ein Blindflug. Besonders kritisch wird das bei einem PHP-Versionsupgrade, weil sich Verhaltensänderungen der Sprache nicht automatisch erkennen lassen.

4. Entwickler finden sich nicht mehr zurecht

Wenn neue Teammitglieder wochenlang brauchen, um produktiv zu werden, stimmt etwas mit der Code-Struktur nicht. Typische Symptome: Geschäftslogik in Templates oder Controllern, keine klare Architektur, fehlende Dokumentation, tausende Zeilen in einzelnen Dateien. Erfahrene PHP-Entwickler meiden solche Projekte oder verlangen deutlich höhere Stundensätze für die Arbeit daran.

5. Abhängigkeiten auf veralteten Bibliotheken

Ihre Anwendung nutzt Packages, die seit Jahren nicht mehr gepflegt werden. Composer zeigt bei jedem Update Warnungen und Konflikte. Oder schlimmer: Sie können Composer gar nicht nutzen, weil der Code Dependencies manuell einbindet. Veraltete Bibliotheken sind ein Einfallstor für Sicherheitslücken und blockieren den Umstieg auf neuere PHP-Versionen.

6. Keine saubere Trennung von Umgebungen

Änderungen werden direkt auf dem Produktionsserver getestet. Es gibt keine Staging-Umgebung, kein automatisiertes Deployment, keine Versionskontrolle oder nur ein einzelnes Branch-Chaos in Git. Das ist kein technisches Problem, sondern ein organisatorisches. Aber es zeigt, dass die Entwicklungsprozesse mit dem System gealtert sind.

7. Performance-Probleme unter Last

Die Anwendung wird bei steigender Nutzerzahl merklich langsamer. Datenbankabfragen sind nicht optimiert, Caching fehlt, und die Architektur skaliert nicht. Oft liegt das daran, dass das System für deutlich weniger Last konzipiert wurde als es heute bewältigen muss.

Refactoring, Rewrite oder Strangler Pattern: Welcher Ansatz passt?

Wenn Sie sich für eine Modernisierung entschieden haben, stellt sich die nächste Frage: Wie? Es gibt drei grundlegende Ansätze, jeder mit eigenen Vor- und Nachteilen.

Refactoring: Schrittweise verbessern

Beim Refactoring verändern Sie die innere Struktur des Codes, ohne das äußere Verhalten zu ändern. Sie räumen auf: Klassen werden extrahiert, Zuständigkeiten getrennt, Tests nachgezogen. Der Vorteil: Das System bleibt jederzeit lauffähig. Das Risiko eines Totalausfalls ist gering. Der Nachteil: Es dauert. Sie arbeiten sich Stück für Stück durch den bestehenden Code.

Refactoring eignet sich, wenn die grundlegende Architektur tragfähig ist und der Code "nur" aufgeräumt werden muss. In meiner Erfahrung ist das bei den meisten KMU-Projekten der richtige Ansatz. Typische Refactoring-Maßnahmen sind: Geschäftslogik aus Controllern in Service-Klassen verschieben, SQL-Abfragen in Repository-Klassen kapseln, globale Variablen durch Dependency Injection ersetzen und hartcodierte Konfigurationswerte zentralisieren.

Rewrite: Komplett neu schreiben

Den gesamten Code verwerfen und von Grund auf neu bauen. Was verlockend klingt, ist in der Praxis das riskanteste Vorgehen. Joel Spolsky hat das einmal als den schlimmsten strategischen Fehler bezeichnet, den ein Softwareunternehmen machen kann. Und er hat in den meisten Fällen recht.

Ein Rewrite bedeutet: Monate oder Jahre der Entwicklung, in denen zwei Systeme parallel existieren. Features, die im alten System selbstverständlich funktionieren, müssen im neuen System nachgebaut werden. Geschäftsregeln, die nirgendwo dokumentiert sind, gehen verloren. Und das neue System hat am Anfang garantiert mehr Bugs als das alte.

Ein Rewrite kann sinnvoll sein, wenn die vorhandene Codebasis so marode ist, dass ein Refactoring mehr kosten würde als ein Neubau. Aber das ist seltener der Fall, als die meisten annehmen.

Strangler Fig Pattern: Das Alte schrittweise ersetzen

Ein Mittelweg: Sie bauen neue Funktionen in einer modernen Architektur und leiten den Traffic schrittweise vom alten System auf das neue um. Das alte System wird nach und nach "erstickt" (daher der Name: Würgefeige). Der Vorteil: Sie haben jederzeit ein funktionierendes System. Das Risiko verteilt sich über einen längeren Zeitraum.

Aus meiner Erfahrung ist das Strangler Pattern besonders geeignet, wenn das alte System noch aktiv genutzt wird und Sie keine Downtime für die Migration einplanen können. Es erfordert allerdings eine saubere Schnittstelle zwischen altem und neuem System, was zusätzlichen Aufwand bedeutet.

Entscheidungshilfe: Welcher Ansatz für Ihre Situation?

Als Orientierung: Wenn Ihr System unter 50.000 Zeilen Code hat und die Grundstruktur erkennbar ist, beginnen Sie mit einem Refactoring. Wenn einzelne Module komplett veraltet sind, aber der Rest noch funktioniert, prüfen Sie das Strangler Pattern. Einen kompletten Rewrite empfehle ich nur, wenn die Codebasis keine erkennbare Struktur mehr hat und die Geschäftslogik ohnehin neu spezifiziert werden muss. In der Praxis ist das deutlich seltener der Fall als vermutet.

Kosten und Zeitrahmen realistisch einordnen

Die Frage, die jeder IT-Entscheider zuerst stellt: Was kostet das? Eine pauschale Antwort gibt es nicht. Aber ich kann Ihnen realistische Größenordnungen aus meiner Praxis nennen.

Code-Audit als erster Schritt

Bevor Sie ein Budget für die Modernisierung freigeben, brauchen Sie eine Bestandsaufnahme. Ein Code-Audit für eine typische KMU-Anwendung (10.000 bis 50.000 Zeilen Code) kostet zwischen 1.500 und 3.000 Euro. Dafür erhalten Sie eine fundierte Einschätzung: Wie ist der Zustand des Codes? Wo liegen die kritischen Stellen? Welcher Ansatz (Refactoring, Strangler, Rewrite) ist sinnvoll? Und eine grobe Aufwandsschätzung für die Umsetzung.

Typische Projektgrößen

Für PHP-Modernisierungsprojekte im KMU-Bereich sehe ich regelmäßig folgende Größenordnungen:

1. PHP-Versionsupgrade (ohne strukturelle Änderungen): 2.000 bis 5.000 Euro. Das umfasst die Anpassung an Breaking Changes, das Testen der gesamten Anwendung und das Deployment. Je mehr veraltete Funktionen genutzt werden, desto aufwendiger wird es.
2. Gezieltes Refactoring kritischer Module: 3.000 bis 8.000 Euro. Hier werden die problematischsten Teile des Codes überarbeitet. Typischerweise betrifft das die Geschäftslogik, die am häufigsten geändert werden muss.
3. Umfassende Modernisierung mit Framework-Migration: 8.000 bis 15.000 Euro und mehr. Wenn eine Anwendung von einer selbstgeschriebenen Architektur auf ein modernes Framework (etwa Symfony) migriert wird, ist der Aufwand entsprechend höher. Dafür sinken die langfristigen Wartungskosten deutlich.

Diese Zahlen basieren auf PHP-Freelancer-Stundensätzen von 80 bis 100 Euro im DACH-Raum (Freelancer-Kompass 2025, freelancermap). Eine Agentur wird für die gleiche Leistung in der Regel 30 bis 50 Prozent mehr berechnen.

Was passiert, wenn Sie nichts tun?

Auch Nichtstun hat einen Preis. Jede Woche, in der Ihr System auf einer nicht unterstützten PHP-Version läuft, steigt das Risiko eines Sicherheitsvorfalls. Jede Funktion, die auf einer fragilen Codebasis gebaut wird, kostet mehr als nötig. Und mit jedem Monat, der vergeht, wird eine Migration aufwendiger, weil sich die Lücke zwischen Ihrer Version und der aktuellen PHP-Version weiter öffnet.

Ein konkretes Beispiel: Der Sprung von PHP 7.4 auf 8.0 brachte erhebliche Breaking Changes (striktere Typ-Konvertierung, entfernte Funktionen, neues Fehlerverhalten). Wer damals nicht migriert hat, steht heute vor dem Sprung von 7.4 auf 8.4 oder 8.5. Das sind fünf Major-Versionen mit kumulierten Inkompatibilitäten. Je länger Sie warten, desto größer wird der Sprung.

Risiken minimieren: So strukturieren Sie ein Modernisierungsprojekt

Die größte Gefahr bei einer Modernisierung ist nicht die Technik. Es ist der Versuch, alles auf einmal zu ändern. Ein bewährter Ansatz in fünf Schritten:

Schritt 1: Audit durchführen

Lassen Sie den Code von einem erfahrenen Entwickler analysieren. Nicht, um eine perfekte Lösung zu entwerfen. Sondern um die kritischsten Stellen zu identifizieren und eine Reihenfolge festzulegen. Was muss zuerst angefasst werden? Was kann warten?

Schritt 2: Tests nachziehen

Bevor Sie etwas refactoren, schreiben Sie Tests für den bestehenden Code. Diese Tests dokumentieren das aktuelle Verhalten der Anwendung. Wenn später etwas bricht, erkennen Sie es sofort. Dieser Schritt fühlt sich unproduktiv an, weil Sie keine neuen Features liefern. Aber er ist die Grundlage für alles, was danach kommt.

Schritt 3: PHP-Version aktualisieren

Mit Tests im Rücken können Sie die PHP-Version anheben. Schritt für Schritt: erst von 7.4 auf 8.0, dann auf 8.1, dann auf 8.2 oder höher. Jeder Schritt wird getestet und deployed, bevor der nächste beginnt. So begrenzen Sie das Risiko auf überschaubare Änderungen.

Schritt 4: Architektur schrittweise verbessern

Jetzt können Sie die Struktur des Codes verbessern. Geschäftslogik aus Controllern extrahieren. Datenbank-Zugriffe in eigene Schichten verlagern. Konfiguration zentralisieren. Auch hier gilt: ein Modul nach dem anderen. Nicht alles gleichzeitig.

Schritt 5: Monitoring und Dokumentation

Richten Sie Logging und Fehler-Monitoring ein, damit Sie Probleme frühzeitig erkennen. Tools wie Sentry oder ein einfaches strukturiertes Logging mit Monolog reichen für den Anfang. Dokumentieren Sie die Architekturentscheidungen, die Sie getroffen haben: Warum wurde diese Struktur gewählt? Welche Alternativen wurden verworfen? Wo liegen bekannte technische Schulden, die bewusst in Kauf genommen wurden? Das klingt selbstverständlich, wird aber in der Praxis fast immer vernachlässigt.

PHP 8.x: Was bringt das Upgrade konkret?

Wenn Ihr System noch auf PHP 7.x läuft, fragen Sie sich zurecht: Lohnt sich der Aufwand? Die Antwort: Ja. PHP 8.x ist nicht einfach eine neue Versionsnummer. Es ist eine spürbare Verbesserung in drei Bereichen.

Performance

PHP 8.0 hat den JIT-Compiler (Just-in-Time) eingeführt. Bei rechenintensiven Aufgaben bringt JIT erhebliche Geschwindigkeitsgewinne. Bei typischen Webanwendungen (Datenbankabfragen, Template-Rendering, HTTP-Verarbeitung) ist der Effekt geringer, aber messbar. Benchmarks mit Symfony-Anwendungen zeigen unter PHP 8.4 mit aktiviertem JIT Performance-Gewinne von bis zu 95 Prozent gegenüber deaktiviertem JIT (Quelle: PHPBenchLab, 2026). Für Standard-Webanwendungen liegt der Gewinn realistischer bei 10 bis 20 Prozent durch die kumulierten Engine-Optimierungen von PHP 8.0 bis 8.5.

Typisierung und Code-Qualität

PHP 8.x hat die Möglichkeiten zur Typisierung stark erweitert. Union Types (8.0), Enums (8.1), Readonly-Klassen (8.2), typisierte Klassenkonstanten (8.3) und Property Hooks (8.4) machen den Code lesbarer und fehlerresistenter. Statische Analyse-Tools wie PHPStan oder Psalm können typisierten Code deutlich besser prüfen.

Ein Vorher-Nachher-Beispiel verdeutlicht den Unterschied:

// PHP 7.x: Untypisiert, unklar was rein- und rausgeht
function getUser($id) {
    $row = $db->query("SELECT * FROM users WHERE id = " . $id);
    return $row;
}

// PHP 8.x: Typisiert, klar definiert, sicher
function getUser(int $id): ?UserDTO {
    return $this->userRepository->find($id);
}

Der moderne Code ist kürzer, verständlicher und verhindert ganze Fehlerklassen (SQL-Injection, Typfehler, unklare Rückgabewerte) bereits zur Entwicklungszeit.

Entwicklerproduktivität

Named Arguments, Match Expressions, Nullsafe Operator, Fibers: PHP 8.x bietet Features, die den Entwicklungsalltag spürbar erleichtern. Erfahrene PHP-Entwickler erwarten diese Features. Wenn Ihr System auf PHP 7.x läuft, schränken Sie den Pool an verfügbaren Entwicklern ein, weil viele schlicht nicht mehr mit veralteten Versionen arbeiten möchten.

Das ist kein theoretisches Problem. Ein häufiger Fehler, den ich in Audits sehe: Unternehmen suchen monatelang einen PHP-Entwickler und wundern sich über die geringe Resonanz. Ein Blick auf den Tech-Stack zeigt dann PHP 7.2, kein Framework, kein Composer. Für qualifizierte Entwickler ist das ein Ausschlusskriterium.

Wann ein Refactoring sich nicht lohnt

Der Vollständigkeit halber: Es gibt Szenarien, in denen Sie nicht modernisieren sollten.

Wenn das System in absehbarer Zeit (6 bis 12 Monate) komplett abgelöst wird, lohnt sich die Investition in ein Refactoring nicht. Gleiches gilt, wenn die Anwendung stabil läuft, nicht mehr weiterentwickelt wird und in einem abgeschotteten Netzwerk ohne Internetzugang betrieben wird. In diesem Fall bleibt das Sicherheitsrisiko beherrschbar.

Für alle anderen Fälle gilt: Je länger Sie warten, desto teurer wird die Modernisierung.

Fazit: Legacy PHP modernisieren ist eine Investition, kein Kostenfaktor

Ein Modernisierungsprojekt fühlt sich zunächst wie ein Kostenfaktor an, weil keine neuen Features entstehen. Aber die Rechnung geht andersherum auf: niedrigere Wartungskosten, schnellere Entwicklung neuer Features, geschlossene Sicherheitslücken und ein System, an dem qualifizierte Entwickler arbeiten wollen.

Die wichtigsten Erkenntnisse zusammengefasst: Prüfen Sie zuerst die PHP-Version. Alles unter PHP 8.2 ist dringend. Lassen Sie ein Code-Audit durchführen, bevor Sie Entscheidungen treffen. Wählen Sie Refactoring über Rewrite, außer die Codebasis ist strukturell nicht mehr rettbar. Investieren Sie in Tests, bevor Sie den Code ändern. Und modernisieren Sie schrittweise statt alles auf einmal.

Starten Sie klein. Lassen Sie einen Code-Audit durchführen. Ziehen Sie Tests nach. Aktualisieren Sie die PHP-Version. Und verbessern Sie die Architektur Schritt für Schritt. Dieser pragmatische Ansatz minimiert das Risiko und liefert nach jeder Iteration einen messbaren Fortschritt.

Wenn Sie ein PHP-System betreiben, das modernisiert werden muss, und Unterstützung bei Audit, Refactoring oder Migration suchen: Sprechen Sie mich an. Ich schaue mir Ihr System an und gebe Ihnen eine ehrliche Einschätzung, was sinnvoll ist und was nicht.