Rewrite-Wunsch vs. Realität
Alte PHP-Anwendungen nerven. Jeder kennt’s: Das Team fordert einen kompletten Relaunch, alles neu, alles besser. Nach dem dritten Meeting merkt dann jemand, dass der Laden davon drei Monate stillsteht – und das Budget schon im ersten Monat platzt. Nebenbei altert das alte System weiter, Bugs stapeln sich. Nichts bewegt sich so richtig. Typisch.
Wer 2026 vor so einem Monolithen sitzt, braucht keinen Big Bang. Sondern etwas, das im Alltag funktioniert: Modernes JS-Frontend, Backend bleibt erstmal, aber bitte nicht alles auf einen Schlag. Ziel: Modernisierung in kleinen, sicheren Happen. Bloß keine bösen Überraschungen, keine tagelangen Downtimes.
Stück für Stück: Frontend und Backend trennen
Was in Agenturen und bei Selbstständigen seit Jahren funktioniert: Frontend schrittweise rauslösen. PHP bleibt als API-Server am Leben, das neue Frontend wächst langsam – React, Vue, Svelte, Lit, je nach Geschmack und Projektgröße. Wichtig: Die Backend-Logik wird nicht angerührt, sondern per Schnittstelle (REST, GraphQL) zugänglich gemacht. Keine komplette Kernsanierung, sondern gezielte Eingriffe.
Praktisch läuft das oft so:
- Vorher: Serverseitige Templates überall, alles verstrickt. Dann erste APIs bauen, möglichst klar und klein.
- Neues JS-Frontend wächst als SPA oder PWA. Nicht alles auf einmal, sondern Modul für Modul.
- Neue Features direkt ins JavaScript, das alte PHP muss nicht mehr alles können.
- Einzelne Seitenbereiche werden modernisiert, der Rest bleibt erstmal wie er ist.
Das Ganze passiert im laufenden Betrieb. Kein Shutdown, keine Ausfallzeit, kein großes Risiko. Und: Wer parallel entwickelt, kommt schneller voran.
API-Extraktion statt Abrissbirne
Die echte Arbeit steckt oft im Backend. Alte PHP-Krücken haben selten saubere Schnittstellen. Wer da mit der Abrissbirne reingeht, bereut es meist schnell. Besser: gezielt APIs aus dem Bestand rausziehen.
Was tatsächlich hilft:
– Für einzelne Module (z.B. Nutzerverwaltung, Formulare) eigene Endpunkte anlegen, die das neue Frontend abruft.
– Leichte Frameworks wie Slim, Mezzio, Symfony API-Platform nutzen, um kleine, übersichtliche JSON-APIs zu liefern.
– API-Versionierung von Anfang an einplanen. Sonst wird mit jedem Umbau alles wieder kaputt getreten.
Beispiel: Ein uraltes Formularmodul? REST-API davorgeschaltet, ins neue JS-Frontend integriert. Der Rest der Seite bleibt PHP. So können Features modernisiert werden, ohne gleich alles zu zerlegen.
Frontend: Funktion vor Hype
Kein Mensch braucht 2026 noch die x-te Fullstack-Mode. Was zählt: Das Frontend muss laufen. Nicht jedes Projekt braucht Typescript, Redux und drei Lagen Build-Tooling. Oft reicht ein schlankes Setup:
- Mit Web Components wie Lit kann Schritt für Schritt modernisiert werden, ohne alles zu zerreißen.
- React oder Vue eignen sich für dynamische Bereiche, nicht für jede Visitenkarte.
- Vite bringt Geschwindigkeit in den Build, Snowpack ist weiterhin brauchbar.
Das neue Frontend spricht über APIs mit dem Backend und sorgt via client-seitigem Routing und Caching für echte Geschwindigkeit. Offline? PWA ist 2026 Standard, keine Hexerei mehr.
30 Jahre Webentwicklung: Meine Sicht
Komplett-Rewrites? In Meetings beliebt, in der Praxis oft das Grab für Budgets und Nerven. Kaum ein Team zieht das sauber durch. Die kleinere, aber wirkungsvolle Lösung: Sanfte Migration, API-first, modernes JS-Frontend. Weniger Stress, weniger Risiko.
Agenturen mit fünf bis zehn Leuten haben selten Zeit für den großen Wurf. Schrittweise Umbauten halten Altprojekte am Laufen und bringen trotzdem Fortschritt. Wer allein unterwegs ist, fährt mit WordPress und REST-API nach gleichem Muster – alles in Mini-Schritten, keine Panik vor Altlasten.
Die echten Stolperfallen liegen im Alltag: APIs werden inkonsistent, Logik doppelt gepflegt, Tests fehlen komplett. Wer sich jetzt Tests gönnt (PHPUnit, Jest, Vitest), spart sich später nächtliche Bug-Sessions. Beispiel: Legacy-Code in PHP & JS weiterentwickeln: Tests statt Komplettabriss.
Tools & Methoden – kein Hexenwerk
- API: REST oder GraphQL – je nachdem wie wild das Projekt ist
- Backend: Slim, Mezzio, Symfony API-Platform, Laravel (API-only)
- Frontend: Lit Web Components für schrittweise Integration, React/Vue für die großen Brocken
- Build-Tools: Vite, Snowpack für kurze Wartezeiten
- Deployment: Docker für parallele Entwicklung, schnelles Rollback
- Tests: PHPUnit im Backend, Jest/Vitest im Frontend
Alles einzeln einbaubar. Niemand muss alles auf einmal machen.
Praxisbeispiel: Kundenportal ohne Nervenzusammenbruch
Ein klassisches Kundenportal (PHP-Monolith, seit Jahren gewachsen). Ziel: Modernere Oberfläche, keine Downtime, kein Totalschaden. Lösung: API-Schicht mit Slim gebaut, React-Frontend mit Login und Dashboard gestartet. Der Rest blieb erstmal alt.
Nach sechs Monaten: Deutlich bessere Bedienung, Backend und Frontend getrennte Entwicklung möglich. Keine nächtlichen Ausfälle, keine Kostenexplosion. Nach zwölf Monaten: Module wie Ticketsystem und Rechnungen kamen dazu – wieder ohne Komplettabriss.
Checkliste für den Alltag
- Bestehende Projekte abklopfen: Wo lassen sich APIs rausziehen?
- JS-Frontend-Strategie wählen, die zum Team und Projekt passt
- Infrastruktur prüfen: Containerisierung/Microservices Schritt für Schritt?
- Tests aufsetzen: Unit für PHP, E2E fürs Frontend
- Kunden rechtzeitig einbinden, Erwartungen klären
Wer’s so macht, bleibt bis 2030 ohne große Bauchschmerzen handlungsfähig.
Lesestoff zum Thema
Siehe Sanfte Migration: Vom PHP-Monolithen zu Microservices und JS-Frontend – Erfahrungsbericht 2026 und PHP-Altprojekte absichern: OWASP-Check für SQL-Injection, XSS, Session-Fixation.
Fazit: Keine Angst vorm Altprojekt
Totalsanierung ist fast immer Illusion. Praktischer und nervenschonender: Bestehendes PHP-Backend, modernes JS-Frontend, alles über APIs verbinden – und Schritt für Schritt modernisieren. Klare Schnittstellen, funktionierende Tests und ein aufgeräumtes Frontend. Dann wird aus dem Altprojekt keine Dauerbaustelle.
bye
mo