Monolithen zerlegen – ohne Abrissbirne
Altprojekte auf PHP – laufen meistens irgendwie. Aber irgendwann reicht das Gefrickel nicht mehr. Komplett neu bauen? Klingt schick, sorgt aber oft für Kopfschmerzen. Und die Kiste muss weiterlaufen, egal was passiert. Abschalten? Kunden flippen aus. Also: Wie umbauen, ohne dass alles abraucht?
Im Agenturprojekt 2026 lag genau so ein Patient auf dem Tisch. Zehn Jahre PHP-Monolith, alles ineinander verzahnt wie Spaghetti mit Käsesauce. Ziel: Microservices und modernes JavaScript-Frontend – aber bitte keinen Stillstand. Heldenmut war nicht gefragt, sondern Geduld, Schraubenzieher und viel Gaffa-Tape.
Die Ausgangslage: Ein Monolith, der aus allen Nähten platzt
Das System: Serverseitiges PHP, Backend und Frontend in einer großen Suppe. Wartung? Zäh wie Kaugummi. Das UI: aus der Zeit gefallen. Performance? Mal so, mal so. Die Anforderungen wuchsen, aber der Code? Kam nicht mehr hinterher.
Das neue Zielbild:
- Node.js-Services als API-Schicht
- React-Frontend, getrennt deploybar
- Docker, damit sich die neuen Services nicht gegenseitig ins Gehege kommen
- Und das Ganze weiter mit der alten MySQL-Datenbank verheiratet
Wichtig: Alles live umziehen. Kein Shutdown, kein Wartungsfenster – maximal „einmal neu laden“ für die User.
Datenmodell: Die Achillesferse beim Umbau
Der Haken kam schnell: Das Datenmodell. Über Jahre wild gewuchert, mit Redundanzen und fester Kopplung ans UI. Controller, die nicht wussten, ob sie Daten holen oder gleich das ganze Formular speichern sollen. Trennung? Nicht vorhanden.
Erst mal alles dokumentieren, auseinanderklamüsern, Domänen abgrenzen. Dabei: Inkonsistenzen und doppelt gehaltene Daten. Klar, typisch bei Altlasten. Exportieren und fertig? Vergiss es – sonst ist die Datenbasis im Eimer.
Was geholfen hat: API-Gateways vor dem Backend. Die nehmen alle Anfragen entgegen, setzen Regeln durch und steuern, welche Daten wohin dürfen. Damit lässt sich der Umbau dosieren, ohne dass jemand aus Versehen das halbe System lahmlegt.
Feature Toggles: Umschalten auf Sicht
Der große Schnitt? Kam nicht infrage. Alte und neue Teile liefen nebeneinander. Mit Feature Toggles wurde gesteuert, was schon neu läuft und was noch alt bleibt. So konnte jeder Bereich einzeln getestet werden – und bei Ärger ging’s per Schalter zurück.
A/B-Tests im Livebetrieb? Kein Problem. Für Nutzer kaum sichtbar, für Entwickler Gold wert. Wer am neuen Service schraubt, kommt sich mit dem Altcode nicht in die Quere. Spart Nerven, hält das Team beweglich.
Performance: Was bringt der Aufwand wirklich?
Vorher: Jeder Klick lädt fette PHP-Skripte, alles blockiert sich gegenseitig. Nachher: Das React-Frontend zieht sich gezielt die Daten, die es braucht. Node.js liefert APIs, Docker trennt sauber die Prozesse. Ergebnis: Ladezeiten gehen spürbar runter, Lastspitzen lassen sich abfedern.
Messung? Ladezeiten in manchen Bereichen halbiert. Node.js profitiert vom JIT, Caching an den Gateways nimmt weiter Druck raus. Wer noch bei PHP 7.x hängt, sollte sich das Thema 8.4 anschauen – mehr dazu im Beitrag PHP 8.4: JIT-Upgrade – Altprojekte werden wirklich schneller? Praxischeck 2026.
Meine Einschätzung nach fast 30 Jahren Webentwicklung
Solche Umbauten sind kein Selbstläufer. Ohne Planung und Dokumentation läuft man ins offene Messer. Feature Toggles, Gateways, Docker – alles nett, aber das meiste Kopfzerbrechen macht die saubere Domänenanalyse. Wer einfach drauflos sägt, bekommt Datenmüll und Supporttickets.
Agenturen mit fünf bis zehn Leuten: Besser mehr Zeit ins Architekturkonzept und Tests stecken als in Quick-and-Dirty-Sprints. Erfahrung mit asynchronen Deployments ist Pflicht – sonst gibt’s Chaos, wenn Alt und Neu auf einmal laufen. Wer als Einzelkämpfer unterwegs ist, sollte Aufwand und Nutzen ehrlich durchrechnen. Nicht jedes Projekt braucht Microservices.
Performancegewinne? Ja, aber erst, wenn Frontend und Backend wirklich getrennt sind. Dann wird das UI flexibel, und moderne Patterns lassen sich einbauen.
Empfehlungen aus dem Projekt
- Erst das Datenmodell auseinandernehmen – nicht gleich alles zerlegen.
- Feature Toggles nutzen, um neue Features stufenweise freizuschalten.
- API-Gateways als Kontrollpunkt – Alt und Neu koppeln, ohne Chaos.
- Performance wird erst spürbar, wenn das Frontend abgekoppelt und Caching gezielt genutzt wird.
- Zeit für Koordination und Testing einplanen. Technik allein zieht den Karren nicht aus dem Dreck.
Weiterlesen: Sicherheit und Trends im Frontend
Wer modernisiert, sollte die Sicherheit nicht vergessen. SQL-Injection & Co. im Griff? Nachlesen unter PHP-Altprojekte absichern: OWASP-Check für SQL-Injection, XSS und Session-Fixation.
Frontend 2026: Weniger JavaScript, mehr Übersicht – wie das im Alltag geht, steht hier: Frontend-Fatigue 2026: Weniger JavaScript, mehr Übersicht im echten Weballtag.
Fazit
Ein Monolith muss nicht auf einen Schlag weg. Mit Geduld, Planung und Feature Toggles lässt sich ein Altprojekt bei laufendem Betrieb umbauen. Die Performancegewinne sind messbar – aber Aufwand und Risiko sollte keiner unterschätzen. Vor allem kleine Teams fahren mit der Schritt-für-Schritt-Methode besser. Wer sauber arbeitet, bekommt ein System, das wieder Spaß macht – und nachts schlafen lässt.
bye
mo