Strangler-Fig-Pattern: Eine PHP-Anwendung schrittweise ablösen – ohne Big Bang

Irgendwann kommt der Moment, in dem der zuständige Entwickler sagt: „Das kann ich nicht mehr verantworten." Gemeint ist die PHP-Anwendung, die seit zwölf Jahren in Produktion läuft, deren Datenbankstruktur niemand vollständig kennt und die trotzdem täglich Hunderte von Bestellungen, Buchungen oder Kundendaten verarbeitet. Abschalten ist keine Option. Komplett neu schreiben – auf einen Schlag – ist teuer, riskant und dauert mindestens ein Jahr, in dem zwei Systeme parallel gepflegt werden müssen.

Genau für diese Situation ist das Strangler-Fig-Pattern entwickelt worden. Der Begriff stammt von Martin Fowler, der sich an einem Feigenbaum orientierte, der seinen Wirtsbaum langsam umwächst und schließlich ersetzt – ohne dass der Wirt von einem Tag auf den anderen fällt. Übertragen auf Software bedeutet das: Neue Funktionen entstehen außerhalb des Altsystems, der Traffic wird schrittweise umgeleitet, bis der Monolith leerläuft und abgebaut werden kann.

Dieser Artikel erklärt, wie eine PHP-Anwendung schrittweise abgelöst werden kann – mit konkreten Entscheidungshilfen zu Routing, Authentifizierung, Datenhoheit und Observability, ohne in abstrakte Architektursprache zu verfallen.

Warum eine PHP-Migration ohne klaren Plan regelmäßig scheitert

Der häufigste Fehler ist nicht der Technologiewechsel selbst, sondern der falsche Startpunkt. Teams beginnen mit der Frage „Welches Framework nehmen wir?" statt mit der Frage „Welche Funktion migrieren wir zuerst – und warum?".

Ein weiteres typisches Problem: Die Altanwendung ist tief mit ihrer eigenen Datenbank verwoben. Sessions, Benutzerkonten, Geschäftsdaten – alles in derselben MySQL-Instanz, ohne klare Domänengrenzen. Wer zuerst die Technik wechselt und dann die fachliche Struktur klärt, schreibt die schlechten Entscheidungen von 2012 in modernem Code neu.

Und dann gibt es den politischen Druck: Geschäftsführung und Kunden akzeptieren keine Ausfallzeiten. Der Big-Bang-Ansatz – alles auf einmal umschalten – lässt sich deshalb kaum rechtfertigen, selbst wenn das Team technisch dazu in der Lage wäre. Ein fehlgeschlagener Launch bedeutet im schlimmsten Fall: Rollback zum Altsystem, Vertrauensverlust, Budgetentzug.

Das Strangler-Pattern löst keines dieser Probleme durch Magie. Es gibt aber eine Struktur, die den Umbau in Abschnitte aufteilt, die einzeln testbar, einzeln lieferbar und einzeln rückbaubar sind.

Der Reverse Proxy als Schalthebel

Der technische Kern des Strangler-Patterns ist ein vorgelagerter Proxy oder ein API-Gateway, das eingehende Anfragen entweder an die alte PHP-Anwendung oder an neue Dienste weiterleitet. Nginx eignet sich als Einstieg, weil es einfach konfigurierbar ist und kaum eigene Fehlerquellen einführt.

Ein einfaches Routing-Beispiel: Alle Anfragen unter /api/v2/orders gehen an den neuen Service, alles andere landet weiterhin beim PHP-Monolithen. Dieser Zustand ist explizit, dokumentiert und jederzeit umkehrbar.

location /api/v2/orders {
    proxy_pass http://new-order-service:3000;
}

location / {
    proxy_pass http://legacy-php:80;
}

Was sich einfach liest, erfordert in der Praxis sorgfältige Planung. Fragen, die vor dem ersten Routing-Wechsel beantwortet sein müssen:

• Welche URLs gehören fachlich zusammen – und können sie als Einheit migriert werden?
• Gibt es gemeinsam genutzte Assets (CSS, JS, Bilder), die weiterhin vom Altsystem ausgeliefert werden?
• Wie verhält sich der Proxy bei Fehlern des neuen Dienstes – fällt er auf das Altsystem zurück?

Ein Fallback auf das Altsystem klingt praktisch, führt aber zu undefiniertem Verhalten, wenn beide Systeme gleichzeitig schreibend auf dieselben Daten zugreifen. Diese Frage – wer darf wann schreiben? – ist die wichtigste architektonische Entscheidung im gesamten Projekt.

Fachliche Schnitte: Wie man die richtigen Grenzen zieht

Technische Schichten (Frontend, Backend, Datenbank) sind keine guten Schnittgrenzen. Sie erzeugen halbfertige Systeme, die nicht unabhängig betrieben werden können.

Fachliche Domänen sind der bessere Ausgangspunkt. Typische Kandidaten für eine erste Migration in einem PHP-Monolith:

Ein guter erster Kandidat für die Ablösung erfüllt drei Kriterien: Er hat klare Ein- und Ausgaben, er schreibt möglichst nicht in geteilte Tabellen, und er hat – oder bekommt – eine automatisierte Testsuite, die das Verhalten des Altsystems dokumentiert.

Charakterisierungstests sind dabei ein unterschätztes Werkzeug: Bevor irgendeine neue Zeile Code entsteht, wird das aktuelle Verhalten des PHP-Codes durch Tests dokumentiert. Diese Tests beschreiben nicht, was das System sollte, sondern was es tut – einschließlich aller Eigenheiten und undokumentierten Sonderregeln. Sie werden anschließend gegen den neuen Service ausgeführt, um sicherzustellen, dass das Verhalten identisch ist.

Geteilte Authentifizierung im Parallelbetrieb

Zwei Systeme, eine Benutzersession – das ist die häufigste Quelle für Bugs in frühen Migrations-Phasen. PHP-Anwendungen speichern Sessions oft serverseitig, in der Datenbank oder in Dateien. Ein neuer Node.js- oder Python-Service kann diese Sessions nicht einfach lesen.

Es gibt drei praktikable Ansätze:

1. Shared Session Store. Beide Systeme greifen auf denselben Redis-Store zu. Das funktioniert, solange das Session-Format kompatibel ist – was bei PHP-serialisierten Daten und JSON-basierten modernen Services selten automatisch der Fall ist. Ein Adapter, der PHP-Sessions deserialisiert und als JWT neu ausstellt, ist lösbar, aber kein Selbstläufer.

2. Auth-Proxy. Ein zentraler Auth-Dienst stellt nach erfolgreichem Login sowohl die PHP-Session (für das Altsystem) als auch ein JWT (für neue Services) aus. Jeder Request geht zuerst durch den Proxy, der das Token validiert. Der Nutzer merkt nichts.

3. Schrittweise User-Migration. Neue Nutzer werden direkt im neuen Auth-System angelegt. Bestehende Nutzer werden beim nächsten Login migriert. Das ist der sauberste Ansatz, funktioniert aber nur, wenn das Altsystem keine schreibenden Auth-Operationen mehr durchführt – was früh im Projekt erreicht werden muss.

Für die meisten mittelständischen PHP-Projekte empfiehlt sich ein Auth-Proxy, weil er keine sofortige Datenmigration erfordert und der Altzustand erhalten bleibt, bis er sicher abgebaut werden kann.

Datenhoheit: Wer besitzt welche Daten?

Die größte Langzeitgefahr im Parallelbetrieb ist Daten-Drift: Altsystem und neues System schreiben in dieselben Tabellen, mit leicht unterschiedlicher Logik, und nach wenigen Wochen sind die Daten inkonsistent.

Die Regel ist einfach, aber schwer konsequent umzusetzen: Jede Domäne hat genau einen Eigentümer. Alle anderen lesen über eine API.

In der Praxis bedeutet das:

• Solange der Bestellprozess noch im PHP-Monolithen läuft, schreibt nur der Monolith in die Orders-Tabelle. Der neue Service liest per REST-Endpoint oder über einen Datenbank-View, den der Monolith bereitstellt.
• Sobald der Bestellprozess in den neuen Service migriert ist, wird der PHP-Code für diesen Bereich auf Read-only gestellt – und anschließend entfernt.
• Geteilte Referenzdaten (z. B. Produktkategorien) bekommen einen eigenen Eigentümer, nicht implizit beide.

Dieses Prinzip zwingt dazu, Schnittstellen explizit zu machen, was den späteren Rückbau erheblich vereinfacht.

Praxisbeispiel: Bestellhistorie als erster Migrationsschritt

Angenommen, eine PHP-E-Commerce-Plattform aus dem Jahr 2014 soll schrittweise abgelöst werden. Die Anwendung verwaltet Kunden, Produkte, Bestellungen und Benachrichtigungen – alles in einer gemeinsamen MySQL-Datenbank.

Hinweis: Das folgende Szenario ist ein hypothetisches Beispiel, das typische Abläufe in diesem Projekttyp illustriert.

Schritt 1 – Analyse: Das Team kartiert alle Datenbankzugriffe auf die orders-Tabelle. Ergebnis: 23 PHP-Dateien lesen aus ihr, 4 schreiben in sie. Die 4 schreibenden Stellen liegen alle im Checkout-Prozess, der vorerst nicht migriert wird.

Schritt 2 – Neuer Service: Ein neuer Service – in diesem Fall ein NestJS-Dienst – wird aufgesetzt, der die Bestellhistorie per REST-Endpoint bereitstellt. Er liest direkt aus der bestehenden MySQL-Datenbank, schreibt aber nicht.

Schritt 3 – Routing: Nginx leitet alle Anfragen auf /mein-konto/bestellungen an den neuen Service. Die restliche Anwendung läuft unverändert.

Schritt 4 – Verifikation: Charakterisierungstests vergleichen die Ausgaben beider Systeme für dieselben Benutzerkonten. Abweichungen werden als Bugs behandelt und behoben.

Schritt 5 – Beobachtung: Nach zwei Wochen zeigen die Logs des neuen Services: 0 Fehler, Ladezeit um 40 % gesunken (weil der neue Service keine Session-Logik mitschleppt). Die PHP-Codepfade für die Bestellhistorie werden als deprecated markiert.

Schritt 6 – Rückbau: Nach weiteren vier Wochen wird der PHP-Code für die Bestellhistorie entfernt. Die zugehörigen Datenbankindizes werden für den neuen Service optimiert.

Dieser Zyklus – Analysieren, aufbauen, routen, vergleichen, beobachten, rückbauen – ist der eigentliche Kern des Strangler-Patterns. Er wird für jede Domäne wiederholt, bis der Monolith keine Funktionen mehr enthält.

Observability: Sehen, was im Parallelbetrieb passiert

Zwei Systeme laufen gleichzeitig – und beide müssen beobachtbar sein. Wer nur auf Applikationslogs vertraut, merkt Probleme zu spät.

Empfohlene Messpunkte im Parallelbetrieb:

• Fehlerrate pro Route: Steigt die 5xx-Rate nach einem Routing-Wechsel, ist das ein sofort sichtbares Signal.
• Latenz-Vergleich: Neue Services sind nicht automatisch schneller. Datenbankabfragen ohne die jahrelang optimierten PHP-Pfade können langsamer sein.
• Anfrage-Differenzen: Werden Requests vom Proxy an den falschen Dienst geroutet? Ein Log auf Proxy-Ebene (in Nginx konfigurierbar) zeigt das sofort.
• Daten-Divergenz: Regelmäßige Vergleiche zwischen den Ausgaben beider Systeme – automatisiert als nächtlicher Job – decken Inkonsistenzen auf, bevor Kunden sie melden.

Prometheus und Grafana sind für diesen Zweck gut geeignet und in den meisten Cloud-Umgebungen einfach aufzusetzen. Das Ziel ist nicht Perfektion beim ersten Schritt, sondern sofortige Sichtbarkeit, wenn etwas nicht stimmt.

Der Rückbau: Wie man den PHP-Monolithen wirklich leert

Viele Teams migrieren Funktionen in neue Services, lassen aber den PHP-Code parallel bestehen – „nur für den Fall". Das ist menschlich verständlich, aber technisch kontraproduktiv. Toter Code wird gewartet, wenn Bibliotheken aktualisiert werden müssen. Er verursacht Verwirrung, wenn neue Entwickler ihn für aktiv halten.

Der Rückbau ist deshalb kein optionaler letzter Schritt, sondern Teil jeder Migrations-Iteration. Konkrete Kriterien für die Freigabe zum Rückbau:

1. Der neue Service läuft seit mindestens 30 Tagen ohne kritische Fehler in Produktion.
2. Kein produktiver Traffic erreicht mehr die alten PHP-Routen (verifiziert durch Access-Logs).
3. Die zugehörigen Charakterisierungstests gegen beide Systeme sind grün.
4. Das Team hat einen Rollback-Plan dokumentiert, falls nach dem Rückbau doch Abhängigkeiten auftauchen.

Besondere Vorsicht gilt bei impliziten Seiteneffekten im PHP-Code: Ein Controller, der eigentlich nur eine Seite rendert, schreibt vielleicht nebenbei in eine Log-Tabelle oder triggert einen Cronjob. Diese Effekte werden bei der Analyse häufig übersehen und tauchen erst nach dem Rückbau als fehlende Funktionalität auf.

Kritische PHP-Sicherheitslücken als Beschleuniger

Was viele Migrationsprojekte ins Stocken bringt, ist der fehlende akute Druck. Das ändert sich, wenn kritische Sicherheitslücken bekannt werden.

Am 21. Oktober 2026 veröffentlichte das PHP-Projekt zwei kritische Sicherheitsupdates: CVE-2026-109618 und CVE-2026-109619. Beide ermöglichen nicht authentifizierte Remote-Code-Ausführung mit CVSS-v4.0-Basiswert 9,2. Behoben wurden sie in PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12. PHP 8.1 und ältere Versionen erhalten vom PHP-Projekt keine regulären Updates mehr – Distributionen und Hoster liefern teils eigene Backports, eine vollständige Absicherung ohne Versionsupdate ist laut Advisory jedoch nicht möglich.

Wer eine PHP-Anwendung betreibt, die auf einer ungepatchten Version läuft, muss sofort updaten. Das ist keine Migrationsstrategie, sondern eine Sofortmaßnahme. Der Migrationsdruck bleibt davon unberührt – aber er wird durch solche Ereignisse sichtbarer. Eine Anwendung, die auf PHP 7.4 oder 8.0 läuft, wird auch nach dem Patch nicht sicherer, was langfristige Architekturentscheidungen betrifft.

Den vollständigen Überblick zu diesen Sicherheitslücken, betroffenen Versionen und Sofortmaßnahmen findest du im Artikel Modernisierungsplan für kritische PHP-Systeme.

Wann das Strangler-Pattern nicht die richtige Wahl ist

Das Muster ist kein Universalwerkzeug. Es gibt Situationen, in denen ein schrittweiser Umbau mehr kostet als ein gesteuerter Neubau:

• Die PHP-Anwendung hat unter 20 aktive Nutzer und keinen kritischen Produktiveinsatz. Dann ist ein Neubau in zwei Monaten wirtschaftlicher als ein sechsmonatiger Parallelentrieb.
• Die Datenbankstruktur ist so verfilzt, dass jede Domäne mit jeder anderen Tabelle verzahnt ist und keine sinnvollen Schnitte möglich sind, ohne die Geschäftslogik vollständig zu rekonstruieren.
• Das Team hat keine Kapazität, beide Systeme gleichzeitig zu betreiben und zu beobachten. Zwei parallele Codebases mit halber Aufmerksamkeit sind gefährlicher als eine.

Die ehrliche Frage vorab lautet: Gibt es fachlich abgrenzbare Teilbereiche, die unabhängig voneinander betrieben werden könnten? Wenn die Antwort nein ist, ist das Strangler-Pattern das falsche Werkzeug.

Was SW Business Solutions in solchen Projekten tut

Individuelle Softwareentwicklung für eine schrittweise Migration bedeutet nicht, einfach neue Dienste zu schreiben. Es bedeutet, zuerst zu verstehen, was der PHP-Monolith wirklich tut – einschließlich der undokumentierten Stellen.

Unser Vorgehen in Legacy-Migrationsprojekten:

1. Technische Bestandsaufnahme: Wir analysieren den vorhandenen PHP-Code, kartieren Datenbankzugriffe und identifizieren fachliche Schnitte. Das Ergebnis ist eine priorisierte Migrations-Roadmap, keine vage Architekturskizze.
2. Proxy-Setup und Routing: Wir richten den Routing-Layer ein und sorgen dafür, dass der erste Wechsel reversibel ist. Der Altsystem-Traffic bleibt jederzeit wiederherstellbar.
3. Neue Dienste nach Geschäftsprozessen: Neue Module entstehen entlang fachlicher Domänen – nicht als technische Schichten. Dabei nutzen wir je nach Anforderung NestJS, Node.js, Python oder andere Laufzeiten.
4. Observability von Beginn an: Prometheus und Grafana werden von Anfang an mitgeplant, nicht nachgerüstet.
5. Rückbau als Projektbestandteil: Jede Iteration endet mit dem Entfernen von Altsystem-Code – nicht mit dem Hinzufügen neuer Schichten auf alte.

Ergänzend zu Legacy-Systeme modernisieren und Systemintegration im Mittelstand bieten wir eine Erstberatung an, in der wir gemeinsam bewerten, ob das Strangler-Pattern für Ihr konkretes System das richtige Vorgehen ist – oder ob ein anderer Ansatz wirtschaftlicher wäre.

Entscheidungshilfe: Bin ich bereit für eine schrittweise Migration?

Vor dem Start lohnt eine ehrliche Bestandsaufnahme anhand dieser Fragen:

Wer drei oder mehr Fragen mit „Nein" beantwortet, sollte zuerst in die Analyse investieren, bevor neuer Code entsteht. Eine Migration, die ohne klare Schnitte startet, produziert einen neuen Monolithen neben dem alten – und löst das eigentliche Problem nicht.

Nächster Schritt

Eine PHP-Anwendung schrittweise ablösen ist ein Projekt, das mit einem klaren Plan beginnt – nicht mit einem Framework-Wechsel. Wenn Ihre Anwendung produktiv läuft, Ausfallzeiten ausgeschlossen sind und ein Komplett-Neubau das Budget sprengen würde, ist das Strangler-Pattern der belastbarste Weg.

Wir helfen Ihnen, diesen Plan zu entwickeln: von der technischen Bestandsaufnahme über den ersten Routing-Wechsel bis zum vollständigen Rückbau des Monolithen. Sprechen Sie uns an – der erste Schritt ist ein Gespräch über Ihre konkrete Situation, ohne Verkaufsdruck und ohne vorgefertigte Lösung.