Rewrite? Meist ein Eigentor – warum Altprojekte besser wachsen als explodieren
Jahrelang läuft das eigene PHP-Projekt irgendwie. Altes Zeug, viel Wildwuchs, manchmal noch Reste aus PHP 4, selten Tests. Kennt jeder, der mal an so einer Kiste schraubt. Neue Features dauern ewig, keiner blickt durch, Fehler lauern überall, und der Entwickler mit dem Durchblick ist längst weg.
Die Standardidee: Alles weg, von vorn. Frisches Framework, PHP 8, endlich sauber. In der Theorie klingt das gut. In der Praxis: Die Realität haut einem gern einen Ziegelstein aufs Dach. Monatelang passiert für die Nutzer – nichts. Das alte System bleibt am Netz, das neue wird nie fertig oder ist halbgar. Die Hälfte der Funktionen fehlt, Bugs überall, Nutzer springen ab. Schon erlebt? Passiert öfter, als einem lieb ist.
Vor allem bei größeren Portalen, SaaS oder Shops. Da hängt zu viel dran. Live-Betrieb, Support, Zahlungen. Wer da alles auf links krempelt, unterschätzt fast immer die Schattenseiten: Explodierende Kosten, endlose Testphasen, Frust auf allen Seiten. Relaunch gegen die Wand gefahren? Gab’s schon in den 2000ern, heute nur noch teurer.
Refaktorieren: Altcode langsam geradebiegen – so geht das wirklich
Statt Kernsanierung: Stück für Stück bereinigen. Neues wächst im alten Code, kleine Module werden modernisiert, Tests wandern rein, Altlasten raus. Merkt von außen kaum jemand. Intern aber: Weniger Stress, mehr Kontrolle.
Was hilft wirklich?
- Unit-Tests dort, wo sich öfter etwas ändert
- Moderne PHP-Features einbauen – Typed Properties, Match, striktere Typisierung
- Riesige Klassen zerlegen, Verantwortung trennen
- Libraries und Selfmade-Lösungen nach und nach durch gepflegte Pakete ersetzen
- Performance nicht vergessen: Profiling ist Pflicht, nicht Kür
Das Ziel bleibt immer gleich: Risiken klein halten, Änderungen planbar machen. Und nicht alles auf eine Karte setzen.
2026: PHP modernisieren, ohne alles zu zerlegen
Mit PHP 8.2 und 8.3 lassen sich viele neue Features nach und nach einbauen. Meist reicht es, an einzelnen Stellen umzubauen: Typed Properties, Match, Union Types, Namespaces, Composer – alles kein Hexenwerk, wenn man nicht versucht, auf einen Schlag alles umzukrempeln.
Praxisbeispiel: Ein Shopsystem mit 20.000 Zeilen Altcode wurde 2026 in sechs Monaten fit für PHP 8.2 gemacht. Parallel: Tests ergänzt, alte Abhängigkeiten rausgeworfen. Der Shop lief weiter, kein einziger Ausfall nach außen. So soll’s sein.
Performance: Refaktorieren als Turbo, nicht als Bremse
Oft gehört: Modernisierung macht langsam. In der Praxis stimmt das selten. Alte Workarounds gehen raus, Datenbankabfragen werden gezielt getunt, Caching und OPcache (2026 absoluter Standard) laufen sauber – und plötzlich ist die Kiste flotter als vorher.
Wichtig: Nicht raten, sondern messen. Vorher und nachher Benchmarks fahren. Erst dann entscheiden, an welcher Stelle noch Luft ist. Wer schrittweise modernisiert, kann einzelne Engpässe gezielt angehen. Komplettumbau? Meist das Gegenteil von Tempo.
Organisation: Modernisieren, Support, neue Features – alles gleichzeitig?
Refaktorieren läuft nie im luftleeren Raum. Kunden nerven, Support will Bugfixes, neue Wünsche kommen rein. Was hat sich bewährt?
- Kleine Refaktorierungs-Pakete, klar umrissen
- Tests sind Pflicht, sonst bleibt der Altcode eine Zeitbombe
- Pairing und Code-Reviews für Wissenstransfer (gerade bei wechselnden Teams)
- Automatisiertes Testen und Deployments per CI/CD, sonst wird’s schnell wild
- Für neuen Code: klare Regeln, damit nicht wieder Wildwuchs entsteht
So bleibt das Modernisieren neben dem Tagesgeschäft überhaupt machbar.
30 Jahre Webentwicklung: Mein Fazit zu Rewrites und Refaktorieren
Komplette Rewrites funktionieren fast nie – das war schon mit PHP 3 so und hat sich bis 2026 nicht geändert. Wer eine Agentur mit 5–10 Leuten betreibt, erlebt schnell, dass laufende Features wichtiger sind als der perfekte Code. Kleine Modernisierungsschritte, sauber getestet, kosten weniger Nerven und Geld. Das reicht.
Freelancer oder Einzelkämpfer profitieren doppelt: Wer zwischendurch modernisiert und alles testet, bleibt flexibel. Kein monatelanger Blindflug, kein Stillstand. Tests und Automatisierung nehmen Angst vor Fehlern. Klar, Arbeit bleibt. Aber wenigstens planbar – und ohne Panik.
Mehr Praxis: Links und Tools
Wer wissen will, was PHP 8.4 an neuen Fallstricken bringt, findet Tipps unter PHP 8.4: Neue Stolpersteine, neue Chancen – was jetzt ansteht.
Sicherheit und Testen im Altcode? Siehe PHP-Altprojekte absichern: OWASP-Check für SQL-Injection, XSS und Session-Fixation.
Fazit
2026 bleibt der Komplett-Reset bei PHP-Altprojekten riskant und teuer. Wer stattdessen Schritt für Schritt modernisiert, sauber testet und den Alltag nicht aus den Augen verliert, fährt besser. Moderne PHP-Features: nach und nach einbauen. Altcode: wartbarer, schneller, weniger Stress. Wer dranbleibt, hat am Ende mehr davon – und weniger schlaflose Nächte.
bye
mo