PHP Legacy-Modernisierung: Migration, Refactoring und Rewrite-Strategien

© bilanol

Wann wird PHP-Code zum Risiko?

Nicht jeder ältere PHP-Code ist automatisch problematisch. Eine Anwendung auf PHP 8.2 mit aktuellen Dependencies und solider Testabdeckung kann jahrelang stabil laufen. Das Risiko entsteht durch eine Kombination konkreter Faktoren:

End-of-Life der PHP-Laufzeitumgebung

PHP 5.6 erreichte sein End-of-Life im Dezember 2018, PHP 7.0 im Dezember 2019, PHP 7.4 im November 2022, PHP 8.0 im November 2023 und PHP 8.1 im Dezember 2025. Anwendungen auf diesen Versionen erhalten keine Sicherheitsupdates mehr. Jede bekannte Schwachstelle bleibt offen — dauerhaft. Für Unternehmen mit Compliance-Anforderungen (ISO 27001, NIS-2, DSGVO) ist der Betrieb auf einer EOL-Version ein dokumentierbarer Verstoss.

Verwaiste Frameworks

Neben der PHP-Version selbst stellt auch das verwendete Framework ein Risiko dar:

• Zend Framework 1 und 2: End-of-Life seit September 2016 bzw. März 2020. Der Nachfolger Laminas hat eine andere Architektur.
• CakePHP 2.x: Nicht mehr unterstützt. CakePHP 5 erfordert erhebliche Umbauten.
• CodeIgniter 3: Community-maintained, aber architektonisch veraltet. CodeIgniter 4 ist ein kompletter Rewrite.
• Yii 1.1: End-of-Life seit Dezember 2020.
• TYPO3 7 und 8: Kein Community-Support mehr, Extended LTS nur gegen Bezahlung und zeitlich begrenzt.
• Eigene Frameworks: Viele Unternehmen setzen proprietäre Frameworks ein, die von einzelnen Entwicklern gebaut wurden. Wenn diese Personen das Unternehmen verlassen, entsteht ein Wissensvakuum.

Sicherheitsimplikationen

Legacy-PHP-Code weist häufig Schwachstellen auf, die in modernen Frameworks architektonisch ausgeschlossen sind:

• SQL-Injection durch fehlende Prepared Statements
• Cross-Site-Scripting (XSS) durch ungefiltertes Output-Rendering
• Session-Hijacking durch veraltete Session-Konfigurationen
• Unsichere Dateiuploads ohne Validierung
• Fehlende CSRF-Protection

Eine Modernisierung ist nicht nur ein technisches, sondern auch ein Risikomanagement-Thema. Ausführlicher behandelt wird das übergreifende Thema im Leitfaden Legacy Software modernisieren aus dem Application-Management-Cluster.

Drei Wege aus der Legacy-Falle

Es gibt kein Patentrezept. Die richtige Strategie hängt von der Ausgangslage ab — Codebasis, Budget, Zeitdruck und verfügbare Kompetenz bestimmen den Weg.

Weg 1: Gezieltes Refactoring

Prinzip: Der bestehende Code wird schrittweise verbessert, ohne die Gesamtarchitektur zu ändern. Kritische Schwachstellen werden behoben, Testabdeckung aufgebaut, Abhängigkeiten aktualisiert.

Wann sinnvoll:

• Die Anwendung läuft auf einer noch unterstützten oder kürzlich abgelaufenen PHP-Version (8.0, 8.1)
• Die Grundarchitektur ist solide, aber der Code ist über Jahre gewachsen und schwer wartbar
• Das Framework wird noch aktiv gepflegt (z. B. Laravel 9 auf 11 bringen)
• Das Budget für eine vollständige Migration fehlt

Typische Maßnahmen:

• PHP-Versionskompatiblität herstellen (PHPCompatibility-Checks)
• Deprecation Warnings beseitigen
• Automatisierte Tests für Kernfunktionen schreiben
• Composer-Abhängigkeiten auf aktuelle Versionen bringen
• Sicherheitskritische Stellen refactorieren (SQL-Queries, Input-Validierung, Authentication)

Aufwand: 20-40 % des Aufwands einer Neuentwicklung, verteilt über mehrere Monate.

Weg 2: Strangler Fig Pattern

Prinzip: Neue Funktionalität wird in einer modernen Architektur entwickelt und schrittweise neben das Altsystem gestellt. Über einen definierten Zeitraum übernimmt die neue Anwendung immer mehr Verantwortung, bis das Legacy-System vollständig abgelöst ist.

Wann sinnvoll:

• Das Altsystem muss während der Migration weiterlaufen (keine Downtime möglich)
• Die Geschäftslogik ist komplex und kann nicht in einem Big-Bang-Release migriert werden
• Verschiedene Module haben unterschiedliche Modernisierungsprioritäten
• Das Team soll parallel am alten und neuen System arbeiten können

Umsetzung in der Praxis:

• Einen Reverse Proxy (nginx, Traefik) vor beide Systeme schalten
• Routing-Regeln definieren: Welche URLs auf das alte System zeigen, welche auf das neue
• Neue Features ausschließlich im neuen System implementieren
• Bestehende Features modulweise migrieren, beginnend mit den geschäftskritischsten
• Shared State (Sessions, Datenbank) über APIs oder gemeinsame Datenhaltung synchronisieren
• Nach vollständiger Migration das Legacy-System abschalten

Aufwand: 60-80 % einer Neuentwicklung, aber mit deutlich niedrigerem Risiko und ohne Big-Bang-Moment.

Weg 3: Kompletter Rewrite

Prinzip: Die Anwendung wird von Grund auf neu gebaut. Der alte Code dient als funktionale Spezifikation, wird aber nicht übernommen.

Wann sinnvoll:

• Die technische Schuld ist so hoch, dass Refactoring unwirtschaftlich wäre
• Das verwendete Framework ist vollständig veraltet und hat keinen Migrationspfad
• Die Geschäftsanforderungen haben sich so stark verändert, dass die alte Architektur nicht mehr passt
• Die Codebasis ist undokumentiert und das ursprüngliche Entwicklungsteam nicht mehr verfügbar

Risiken:

• Höchster Aufwand und längster Zeitrahmen
• Gefahr des “Second System Effect” (Feature Creep)
• Während der Neuentwicklung muss das Altsystem weiter gewartet werden
• Wissen über implizite Geschäftsregeln im alten Code kann verloren gehen

Aufwand: 100 %+ einer grünen-Wiese-Entwicklung (oft mehr, weil die Migration bestehender Daten und die Parallelität beider Systeme Zusatzaufwand erzeugen).

Migration zu Laravel oder Symfony

Die Frage “Welches Ziel-Framework?” stellt sich bei jeder Migration. Beide Optionen — Laravel und Symfony — haben klare Stärken für Migrationsprojekte. Eine detaillierte Gegenüber-stellung bietet der Framework-Vergleich.

Migration zu Laravel

Gut geeignet für: Anwendungen mit klaren CRUD-Workflows, die von Laravels Conventions profitieren. Projekte, bei denen schnelle sichtbare Fortschritte wichtig sind, um Stakeholder-Vertrauen zu sichern. Teams, die mit Active-Record-ORMs (Eloquent) vertraut sind.

Migrationsstrategie: Laravel bietet mit Eloquent einen Weg, bestehende Datenbankschemas ohne Schema-Änderung zu mappen. Das ermöglicht eine schrittweise Migration: Controllers und Views werden in Laravel neu gebaut, während die bestehende Datenbank unverändertert bleibt. Erst nach vollständiger Migration der Geschäftslogik wird das Schema optimiert.

Details zur Laravel-Entwicklung.

Migration zu Symfony

Gut geeignet für: Anwendungen mit komplexen Domänenmodellen, die von Doctrine ORM und dem Data-Mapper-Pattern profitieren. Projekte mit langer geplanter Lebensdauer (10+ Jahre), bei denen Symfonys LTS-Garantien Planungssicherheit geben. Systeme in regulierten Umgebungen, bei denen architektonische Nachvollziehbarkeit für Audits relevant ist.

Migrationsstrategie: Symfonys Komponentenarchitektur erlaubt eine besonders granulare Migration. Einzelne Symfony-Komponenten (HttpFoundation, Console, DependencyInjection) können in den bestehenden Code integriert werden, noch bevor eine vollständige Framework-Migration stattfindet. Damit lässt sich die Codebasis schrittweise “symfonifizieren”.

Details zur Symfony-Entwicklung.

Datenmigration und Schnittstellenkompatibilität

Die technisch anspruchsvollste Phase jeder Legacy-Modernisierung ist nicht der neue Code — sondern die Migration bestehender Daten und die Aufrechterhaltung externer Schnittstellen.

Datenbank-Schema-Migration

Legacy-Anwendungen haben häufig organisch gewachsene Datenbankschemas: fehlende Fremdschlüssel, gemischte Datentypen, redundante Tabellen, gespeicherte Logik in Stored Procedures. Eine Schema-Migration umfasst:

• Bestandsaufnahme: Vollständige Dokumentation des Ist-Schemas inklusive Trigger, Views und Stored Procedures.
• Ziel-Schema-Design: Normalisierung, Bereinigung von Redundanzen, Einführung von Foreign Keys und Constraints.
• Migrationsskripte: Reversible Migrationsskripte (Laravel Migrations, Doctrine Migrations), die Daten transformieren und validieren.
• Integritätsprüfung: Automatisierte Vergleiche zwischen Quell- und Zieldatenbank (Zeilenanzahl, Checksummen, Stichproben).
• Fallback-Strategie: Die Möglichkeit, auf den ursprünglichen Zustand zurückzukehren, bis die neue Datenhaltung validiert ist.

API-Kompatibilität

Bestehende Anwendungen stellen häufig Schnittstellen bereit, die von Drittsystemen konsumiert werden: Mobile-Apps, Partner-Integrationen, interne Tools. Diese Schnittstellen müssen während der Migration stabil bleiben.

Bewaherte Strategie: Einen API-Kompatibilitäts-Layer zwischen altem und neuem System einziehen. Das neue System implementiert die gleichen Endpoints mit identischen Request/Response-Strukturen. Erst nach Validierung durch alle Konsumenten werden die alten Endpoints abgeschaltet. Versionierung der API (z. B. /api/v1/ vs. /api/v2/) erlaubt es, neue und alte Schnittstellen parallel zu betreiben.

Weitere Informationen zur API- und Schnittstellenentwicklung finden sich auf der entsprechenden Serviceseite.

Kosten und Zeitrahmen realistisch einschätzen

Legacy-Modernisierung scheitert selten an der Technik — sie scheitert an unrealistischen Erwartungen. Eine ehrliche Einschätzung der Kostenstruktur:

Typische Projektgrößen

Diese Schätzungen umfassen Analyse, Entwicklung, Testing und Deployment. Nicht enthalten: Projektmanagement-Overhead, Stakeholder-Kommunikation und Parallelwartung des Altsystems.

ROI-Betrachtung

Die Investition in eine Modernisierung rechnet sich, wenn die laufenden Wartungskosten des Legacy-Systems die Modernisierungskosten innerhalb von 2-3 Jahren übersteigen würden. Faktoren, die den ROI positiv beeinflussen:

• Reduzierte Wartungskosten: Moderne Frameworks und aktuelle PHP-Versionen erfordern weniger manuellen Wartungsaufwand.
• Höhere Entwicklungsgeschwindigkeit: Neue Features lassen sich auf einer sauberen Codebasis schneller und zuverlässiger implementieren.
• Geringeres Sicherheitsrisiko: Weniger Schwachstellen bedeuten niedrigere potenzielle Schadenskosten und günstigere Cyber-Versicherungsprämien.
• Breitere Fachkräfteverfügbarkeit: Entwickler für Laravel und Symfony sind am Markt deutlich einfacher zu finden als Spezialisten für Zend Framework 1 oder CakePHP 2.

Versteckte Kosten bei Nicht-Modernisierung

Wer die Modernisierung aufschiebt, spart kurzfristig — zahlt aber langfristig:

• Steigende Stundensätze für Legacy-Spezialisten (30-50 % Aufschlag gegenüber Standard-PHP-Entwicklern)
• Zunehmende Sicherheitsvorfälle und deren Behebungskosten
• Verpasste Geschäftschancen durch langsame Feature-Entwicklung
• Compliance-Risiken bei EOL-Software (Bußgeldrisiko bei NIS-2, DSGVO-Verstoßen)

Legacy-Modernisierung bei TenMedia

TenMedia begleitet seit über 14 Jahren PHP-Migrationsprojekte — von der Analyse bis zum produktiven Betrieb der modernisierten Anwendung. Die ISO-27001-Zertifizierung stellt sicher, dass auch während der Migrationsphase Informationssicherheit und Datenschutz gewährleistet bleiben.

Vorgehen

• Legacy Assessment: Analyse der bestehenden Codebasis, Abhängigkeiten, Infrastruktur und Sicherheitslage. Ergebnis: Ein dokumentierter Zustandsbericht mit Handlungsempfehlung (Refactoring, Strangler Fig oder Rewrite).
• Strategiedefinition: Gemeinsam mit dem Auftraggeber wird die Migrationsstrategie festgelegt — inklusive Zeitrahmen, Budget und Akzeptanzkriterien.
• Iterative Migration: Umsetzung in Sprints mit regelmäßigen Reviews. Jeder Sprint liefert ein funktionsfähiges, testbares Inkrement.
• Qualitätssicherung: Automatisierte Tests, Code Reviews und Staging-Deployments sichern jeden Migrationsschritt ab.
• Wartungsübergang: Nach erfolgreicher Migration wird die Anwendung in einen regulären Wartungsvertrag überführt.

Das Inhouse-Modell (100 % eigene Entwickler, kein Freelancer-Einsatz, kein Offshoring) stellt sicher, dass Wissen über die migrierte Anwendung nicht nach Projektende verloren geht. Die Berufshaftpflicht sichert zusätzlich gegen Projektrisiken ab.

Weiterführende Informationen

• PHP-Framework-Vergleich – Entscheidungshilfe für das Ziel-Framework
• Symfony-Migration – Migrationspfade auf Symfony
• PHP-Wartung – Wartungsstrategien nach der Modernisierung
• Application Management – Laufende Betreuung modernisierter Anwendungen
• Datenmigration – Sichere Datenüberführung bei Systemwechseln