Komplett neu schreiben? Meist ein Fehler.
Wer schon länger PHP- oder JavaScript-Projekte betreut, kennt das: Altlasten, teils wild zusammengewachsen, Funktionen, die keiner mehr versteht, und jeder neue Bugfix fühlt sich an wie eine Operation am offenen Herzen. Der Reflex: Alles auf Anfang, einmal sauber neu bauen. Passiert oft, gerade wenn neue Leute ins Projekt kommen. In der Realität sieht’s meist anders aus. Der große Wurf bleibt stecken. Monate gehen ins Land, manchmal wird es ein Jahr – und am Ende ist vieles noch unfertiger als vorher. Die alten Fehler kommen zurück, neue schleichen sich ein, und die Kunden fragen nach längst versprochenen Features.
Erfahrung aus fast 30 Jahren: Komplett-Rewrites kosten Nerven und Budget. Die seltenen Ausnahmen bestätigen die Regel. Gerade bei komplexen PHP-Backends oder verfrickeltem Frontend-JS klappt der Reset-Button fast nie. Besser: Stückweise stabilisieren. Mit Tests und Tools, die auch bei Chaoscode greifen. Kein Zauber, aber in der Praxis der einzige Weg, nicht im Kreis zu laufen.
Automatisierte Tests: Rettungsleine für Legacy-Code
Viele Altprojekte: Null Tests. Jeder Fix ein Risiko. Wer’s einmal erlebt hat, weiß – jeder Commit kann den halben Shop zerschießen. Das nervt, kostet Zeit und bringt das Team auf Temperatur. Automatisierte Tests sind kein Luxus für Hipster-Startups. Gerade bei Legacy-Kram machen sie den Unterschied. PHPUnit (PHP), Jest oder Mocha (JS) – egal. Hauptsache überhaupt Tests.
Nicht auf 100 % Coverage schielen. Das erreicht niemand, schon gar nicht nachträglich. Lieber die Hotspots absichern: Kernlogik, Zahlungsabwicklungen, Schnittstellen, wo Fehler richtig teuer werden. Code-Coverage-Tools zeigen, wo es noch brennt. Schrittweise Lücken schließen – und nebenbei die schlimmsten Überraschungen ausmerzen. Erfahrung: Schon 15 % Tests bringen mehr Ruhe als gar keine.
Moderne Toolchain: Kein Selbstzweck, sondern Alltagshilfe
Jenkins, GitLab CI, GitHub Actions – gibt’s alles, auch für Altprojekte. Automatisierte Testläufe bei jedem Commit – spart Nerven, wenn nachts Deployments laufen. Statische Codeanalyse: PHPStan fürs Backend, ESLint im Frontend. Macht Fehler sichtbar, die beim Durchklicken im Browser keiner sieht. Kein Grund, alles auf einmal einzubauen. Wer Composer (PHP) und npm/yarn (JS) nicht nutzt, arbeitet mit angezogener Handbremse.
Updates automatisieren: Libraries altern, Sicherheitslücken entstehen. Mit einer Staging-Umgebung werden neue Versionen ausprobiert, bevor sie live gehen. Spart Supporttickets und peinliche Nachtschichten. Wer das einmal ernsthaft aufgesetzt hat, will nicht zurück.
So läuft’s in der Praxis: Kein Big Bang, sondern Schraubenzieherarbeit
- Erstmal Altbestand sichten: Welche Module machen regelmäßig Ärger?
- Testfälle priorisieren: Zahlungslogik und andere kritische Teile zuerst.
- Testumgebung aufbauen: CI/CD, Testframeworks, fertig.
- Mit einfachen Unit-Tests starten. Nicht zu viel auf einmal wollen.
- Statische Analyse in den Commit-Prozess einbauen.
- Kleine Refactoring-Schritte, mit Tests absichern.
- Dokumentation und kurze Workshops – reicht oft, wenn alle das Grundprinzip verstanden haben.
Typischer Fall aus dem Agenturalltag: 15 Jahre altes PHP-Monster, keine Tests, 1000 Sonderlocken. Nach den ersten Dutzend Tests kommen Fehler ans Licht, die seit Jahren durchrutschen. Der Supportaufwand sinkt, neue Kollegen steigen schneller ins Projekt ein. Kein kompletter Rewrite nötig – und das Projekt lebt weiter, statt im Refactoring-Nirvana zu verschwinden.
Eigene Einschätzung aus 30 Jahren Webentwicklung
Wer 2026 noch ohne Tests im Legacy-Code fummelt, spielt mit dem Feuer. Agenturen profitieren: Weniger Stress, planbarere Deadlines, weniger Nachtschichten. Für Einzelkämpfer: Frühwarnsystem gegen Bugs, die sonst erst beim Kunden auffallen. Komplett-Neubau? Meist die teuerste und riskanteste Lösung. Stückweises Vorgehen, Tests, CI/CD, statische Analyse – klingt langweilig, funktioniert aber. Motivation im Team bleibt oben, weil die Angst vor Rückschritten weg ist.
Kleine Teams profitieren am meisten. Änderungen gehen raus, ohne dass gleich alles wackelt. Zu viel Tooling bringt aber auch nichts. Die Balance zwischen Aufwand und Nutzen muss stimmen. Schon mit überschaubarem Aufwand lässt sich viel bewegen.
Mehr zum Thema?
Weitere Einblicke und Praxisberichte:
PHP 8.4 statt Framework-Feuerwerk: Stabilität für alte Projekte, weniger Chaos
und
PHP-8-Upgrade im Bestand: Migration ohne Aussetzer.
Fazit: Tests sind der bessere Plan
Legacy-Projekte in PHP und JavaScript müssen nicht neu gebaut werden. Mit gezielten Tests und den richtigen Tools bleibt der Code beherrschbar, Features lassen sich sicher ergänzen, und technische Schulden werden Stück für Stück abgebaut. Komplettabriss? Nur im Ausnahmefall sinnvoll. Wer Schritt für Schritt stabilisiert, spart Zeit, Geld und Nerven – und das Team bleibt handlungsfähig.
bye
mo