NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Grüne Gleisweiche mit Schild Strangler Fig, eine Route zweigt ab

Strangler Fig Pattern: Definition

Das Strangler Fig Pattern ist ein Architekturmuster, bei dem ein Altsystem Stück für Stück durch neue Module ersetzt wird, während es weiterläuft. Ein Gateway vor der Anwendung leitet einzelne Routen auf den neuen Code um, alles andere bleibt vorerst beim Alten.

Martin Fowler prägte den Begriff 2004 nach einer Reise durch den australischen Regenwald. Die Würgefeige keimt in den Ästen eines Wirtsbaums, wächst nach unten, umschließt ihn und steht am Ende allein. Genau so soll Modernisierung laufen: kein Stichtag, kein Big Bang, sondern eine dünne Scheibe nach der anderen. Für PHP Teams heißt das konkret: eine Route wandert auf PHP 8, der Rest der Anwendung merkt davon nichts. Geht etwas schief, schaltet ein einziger Toggle den Verkehr zurück auf das Altsystem.

Inhalt

Strangler Fig mit NCA: Schnelle Hilfe vom Experten

Never Code Alone arbeitet seit über 20 Jahren an gewachsenen PHP Anwendungen. Unser eigener Stack läuft auf Symfony und Sulu CMS, abgesichert durch PHPUnit, PHPStan, Psalm und Rector, dazu E2E Tests mit Cypress. Diese Werkzeuge nutzen wir täglich in Produktion, nicht nur in Schulungsbeispielen. Genau deshalb wissen wir, wo eine Strangler Fig Migration in der Realität hakt: bei gemeinsamen Sessions, geteilten Datenbanken und Routen, die niemand mehr versteht.

Wir begleiten Teams beim PHP Consulting und beim Refactoring von Legacy Code. Bevor eine Zeile umzieht, bauen wir die Quality Gates auf: statische Analyse mit PHPStan, automatisierte Umbauten mit Rector PHP, Unit und Functional Tests mit PHPUnit und Architekturregeln über Deptrac. Für den Sprung auf aktuelle Versionen hilft der Überblick zu den PHP 8 Versionen.

Lass uns sprechen

Finde das passende Angebot für dein Projekt

Anfrage-Konfiguration

Starten Sie Ihre Anfrage

Projektart
Infos
Nachricht

Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.

CORE EXPERTISE

Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.

BFSG COMPLIANT

Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.

ENTERPRISE READY

Warum der große Rewrite so oft scheitert

Alte PHP Anwendungen sind wertvoll, weil sie über Jahre echte Geschäftsprobleme gelöst haben. Genau deshalb stecken in ihnen auch Sonderfälle, Schnellschüsse und Integrationen, die einmal dringend waren. Das Ergebnis ist Code, der läuft, aber bei jeder Änderung zittern lässt.

Ein kompletter Neubau klingt nach Befreiung. In der Praxis passiert Folgendes: Das Team baut zwei Jahre am Ersatz, während das Altsystem weiter Features bekommt. Das neue System muss diese Features nachziehen und kommt nie an. Am Ende steht ein Stichtag, an dem alles auf einmal umschaltet. Fehlt eine Kleinigkeit, steht der Betrieb.

Das Strangler Fig Pattern dreht die Frage um. Nicht: Wie bauen wir alles neu? Sondern: Welche einzelne Route können wir heute sicher umleiten? Modernisierung wird damit zum Routing Problem statt zur Heldentat.

Drei Prinzipien tragen den Ansatz:

  • Erst umleiten, dann umbauen. Wer steuert, welche Anfrage wohin geht, kann fast alles ändern, ohne dass etwas ausfällt.
  • An den Rändern übersetzen. Alte Begriffe und Datenstrukturen bleiben draußen, das neue Modell bleibt sauber.
  • Modelle parallel führen. Neu läuft neben Alt, die Ergebnisse werden verglichen, erst dann wird umgeschaltet.

So funktioniert die Umleitung technisch

Vor der alten Anwendung steht ein Reverse Proxy. Er ist der Schalter. Anfangs zeigt jede Regel auf das Altsystem. Dann kommt die erste Ausnahme: ein Pfad wandert auf den neuen Dienst, alles andere bleibt unverändert.

Ein minimales Beispiel mit nginx zeigt das Prinzip. Beide Ziele werden als Upstream definiert, danach entscheidet die Reihenfolge der Regeln, wer welche Anfrage bekommt.

Code: 
          
upstream legacy_app  { server 10.0.0.10:8080; }
upstream new_service { server 10.0.0.20:8080; }

server {
    listen 80;

    location = /newsletter/signup {
        proxy_pass http://new_service;
    }

    location / {
        proxy_pass http://legacy_app;
    }
}

Die erste Regel greift auf genau einen Pfad, die zweite fängt den gesamten Rest ab. Wächst die Migration, kommen weitere Ausnahmen dazu, bis irgendwann nur noch die letzte Regel übrig bleibt und das Altsystem abgeschaltet werden kann.

Der Rückweg ist genauso wichtig wie der Hinweg. Eine Regel auskommentieren, Proxy neu laden, und der Verkehr läuft wieder komplett auf dem Altsystem. Wer diese Umkehr nicht in unter fünf Minuten schafft, hat die Scheibe zu groß geschnitten.

Sessions, Datenbank und Dateien bleiben in dieser Phase meist gemeinsam. Der neue Dienst greift auf dieselben Quellen zu wie die alte Anwendung. Das ist kein Schönheitsfehler, sondern der Grund, warum die Migration überhaupt in Scheiben funktioniert. Sauber halten lässt sich das neue Modell trotzdem, nämlich über einen Anti Corruption Layer.

Die erste Scheibe richtig wählen

Die erste Migration entscheidet über das ganze Projekt. Läuft sie sauber, wächst das Vertrauen im Team und beim Management. Geht sie schief, gilt der Ansatz als gescheitert, bevor er richtig begonnen hat.

Drei Kriterien haben sich bewährt. Der Schnitt braucht klare Ein und Ausgaben, damit sich das Verhalten überhaupt festhalten lässt. Er sollte auf eine sichtbare Kennzahl wirken, sonst fehlt das Argument für die nächste Runde. Und er muss sich mit einem Handgriff zurückdrehen lassen.

Gute und schlechte erste Scheibe im Vergleich

Kriterium Gute erste Scheibe Schlechte erste Scheibe
Schnittstelle Klar definierte Ein und Ausgaben, etwa ein API Endpunkt Seite mit Session Logik, Templates und Nebenwirkungen
Wirkung Messbare Kennzahl wie Antwortzeit oder Fehlerrate Interner Randbereich, den niemand bemerkt
Rücknahme Ein Toggle schickt den Verkehr zurück zum Altsystem Datenbankschema wurde bereits umgebaut
Absicherung Verhalten ist über Tests festgehalten Niemand weiß, was der Code heute genau tut

Ohne Quality Gates kein Strangler Fig

Das Muster verspricht Sicherheit durch kleine Schritte. Diese Sicherheit entsteht aber erst durch das Netz darunter. Wer eine Route umleitet, ohne das alte Verhalten zu kennen, hat kein Pattern angewendet, sondern geraten.

Die Reihenfolge ist bei uns immer dieselbe. Zuerst die Quality Gates, dann der Umbau:

  • Statische Analyse mit PHPStan oder Psalm, zunächst auf moderatem Level, damit das Team überhaupt startet
  • Unit und Functional Tests mit PHPUnit für die Logik, die umziehen soll
  • Charakterisierungstests für Code, dessen Verhalten niemand mehr beschreiben kann
  • E2E Tests mit Cypress als Black Box über die Oberfläche, unabhängig von der Technik darunter
  • Architekturregeln über Deptrac, damit alte Namen nicht ins neue Modell sickern

Besonders die E2E Ebene zahlt sich hier aus. Ein Cypress Test klickt durch den Bestellprozess und weiß nicht, ob dahinter PHP 5 oder PHP 8 antwortet. Genau deshalb überlebt er den Umzug einer Route unverändert und meldet sofort, wenn sich das Verhalten ändert. Mehr dazu im Bereich Cypress Testing und in unserem PHP Consulting.

KI unterstützt dabei, ersetzt die Disziplin aber nicht. Modelle sind stark darin, Bestandscode zu erklären und Testfälle vorzuschlagen. Den Umbau selbst führt das Team, Schritt für Schritt, mit Review. Ein Agent, der eine Legacy Codebasis autonom abarbeitet, ist kein realistisches Szenario, sondern ein Risiko.

Typische Fehler in Strangler Fig Projekten

Die Scheiben sind zu groß. Wenn sich eine Migration nicht auf einen kleinen Teil des Verkehrs begrenzen lässt, ist der Schnitt falsch gewählt. Kleiner schneiden, notfalls auf eine einzige Funktion.

Grenzen werden undicht. Alte Feldnamen und Datentypen wandern ins neue Modell. Nach einem Jahr sieht der neue Code aus wie der alte, nur in neuer Syntax. Übersetzer an den Rändern und Architekturregeln in der Pipeline verhindern das.

Erst hundert Prozent Testabdeckung. Wer vor dem ersten Umzug die ganze Anwendung testen will, kommt nie los. Kritisches Verhalten festnageln, den Rest während der Migration nachziehen.

Alles refactorn wollen. Zuerst zieht das Verhalten um, aufgeräumt wird im neuen Modul, wo Tests schützen. Beides gleichzeitig macht jeden Fehler unauffindbar.

Fortschritt bleibt unsichtbar. Ohne Zahlen wirkt eine Migration in Scheiben wie Stillstand. Ein Dashboard mit dem Anteil migrierter Routen und der Fehlerrate beider Seiten hält die Diskussion sachlich.

An alternative route is to gradually create a new system around the edges of the old.

Martin Fowler, Chief Scientist bei Thoughtworks – Strangler Fig Application

Die NCA Erfahrung mit Legacy Migrationen

Wir begleiten Teams bei genau dieser Arbeit: Bestand verstehen, Verhalten absichern, dann Scheibe für Scheibe umziehen. Aus vielen Projekten hat sich ein Werkzeugkasten ergeben, den ihr im Glossar nachlesen könnt.

Für die Analyse des Bestands helfen Churn PHP beim Finden der heißen Stellen und PHP Metrics beim Bewerten der Komplexität. Die Abhängigkeiten prüfen Deptrac und PHP Architecture Tester. Automatisierte Umbauten übernimmt Rector PHP, die Typsicherheit sichern PHPStan und Psalm. Getestet wird mit PHPUnit, ergänzt um Functional Tests und die Qualitätsprüfung vor jedem Commit über GrumPHP. Wer den Sprung auf eine aktuelle Sprachversion plant, findet im Vergleich der PHP 8 Versionen die Breaking Changes im Überblick.

CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.

Erreichen Sie unsere PHP Consultant Spezialisten

Wir sind Experten für PHP und helfen Ihnen, Ihre digitalen Herausforderungen zu meistern. Unser erfahrenes Team unterstützt Sie bei PHP Updates, PHP Refactoring und berät Sie remote zu allen Fragen rund um PHP. Mit unseren vollautomatischen CI/CD Deployments und einer robusten Docker-Infrastruktur bringen wir Ihre PHP-Projekte auf das nächste Level. Vertrauen Sie auf unsere Expertise für zuverlässige und skalierbare PHP-Lösungen.

Demo Team Workshop Anrufen

Häufige Fragen zum Strangler Fig Pattern

Die Fragen, die uns im Consulting am häufigsten begegnen, wenn Teams eine Legacy Migration planen.

Was ist das Strangler Fig Pattern 2026 in einem Satz?

Ein Architekturmuster, bei dem ein Altsystem im laufenden Betrieb Route für Route durch neue Module ersetzt wird. Ein Gateway steuert, welche Anfrage wohin geht. Das Altsystem schrumpft dabei über Monate, bis es abgeschaltet werden kann. Der entscheidende Vorteil gegenüber einem Neubau ist, dass jeder Schritt einzeln zurückgenommen werden kann.

Lohnt sich Strangler Fig 2026 noch, wo KI beim Refactoring hilft?

Ja, und zwar mehr als vorher. KI beschleunigt das Verstehen von Bestandscode und das Schreiben von Tests erheblich. Die Frage, welcher Teil wann sicher umziehen kann, bleibt aber eine Architekturentscheidung. Ohne Umleitung und Rückweg wird jede KI gestützte Änderung an Legacy Code zum Risiko.

Wie lange dauert eine Strangler Fig Migration 2026?

Das hängt vom Umfang der Anwendung ab, seriös lässt sich das nur nach einem Blick in den Code schätzen. Was sich sagen lässt: Die erste Scheibe sollte in Wochen laufen, nicht in Monaten. Dauert sie länger, war der Schnitt zu groß. Wir schätzen den Aufwand nach einem kostenlosen Kennenlernen und rechnen minutengenau ab.

Welche Werkzeuge braucht ein PHP Team 2026 dafür?

Einen Reverse Proxy wie nginx als Gateway, eine Möglichkeit für Feature Flags, dazu die üblichen Quality Gates: PHPStan oder Psalm für statische Analyse, PHPUnit für Tests, Rector für automatisierte Umbauten und Cypress für E2E Tests über die Oberfläche. Ein Monitoring, das beide Seiten sichtbar macht, gehört ebenfalls dazu.

Funktioniert Strangler Fig 2026 auch ohne Microservices?

Ja. Das Muster wird oft mit Microservices erklärt, ist aber unabhängig davon. Der neue Teil kann genauso ein zweites Symfony Projekt sein, ein neues Modul im selben Repository oder eine separate Anwendung auf aktuellem PHP. Entscheidend ist die Umleitung, nicht die Betriebsform.

Was passiert mit der gemeinsamen Datenbank?

In der Regel greifen alt und neu zunächst auf dieselbe Datenbank zu. Das ist gewollt und macht die Migration in Scheiben erst möglich. Schemaänderungen laufen später über Parallel Change: erst neue Spalten ergänzen und doppelt schreiben, dann Altdaten nachziehen, zuletzt die Lesezugriffe umstellen und alte Felder entfernen.

Wie unterscheidet sich Strangler Fig vom Anti Corruption Layer?

Strangler Fig regelt, welcher Verkehr wohin geht. Der Anti Corruption Layer regelt, wie beide Seiten miteinander sprechen. In der Praxis werden sie gemeinsam eingesetzt: Das Gateway leitet die Route um, Übersetzer an den Rändern sorgen dafür, dass Begriffe aus dem Altsystem nicht ins neue Modell wandern.

Woran erkenne ich, dass eine Scheibe fertig ist?

Wenn der Verkehr vollständig auf dem neuen Pfad läuft, die Fehlerrate nicht gestiegen ist und die alte Implementierung entfernt werden kann. Solange der alte Code noch als Rückfallebene existiert, ist die Scheibe abgeschlossen, aber nicht aufgeräumt. Diesen Aufräumschritt sollte man einplanen, sonst wachsen zwei Systeme parallel weiter.

Was tun, wenn niemand mehr versteht, was der alte Code macht?

Dann kommen Charakterisierungstests zum Einsatz. Sie prüfen nicht, was der Code tun sollte, sondern halten fest, was er heute tatsächlich tut, inklusive der schrägen Sonderfälle. Erst mit diesem Netz lässt sich eine Route sicher umleiten. KI Modelle sind beim Erklären des Bestands und beim Vorschlagen solcher Testfälle eine echte Hilfe.

Wie überzeuge ich die Geschäftsführung von diesem Weg?

Über Risiko und Sichtbarkeit. Ein Neubau liefert zwei Jahre lang nichts und schaltet dann alles auf einmal um. Strangler Fig liefert nach wenigen Wochen die erste messbare Verbesserung und lässt sich jederzeit stoppen. Ein Dashboard mit dem Anteil migrierter Routen macht Fortschritt für Nichtentwickler nachvollziehbar.

Kann das Pattern auch bei Shopsystemen oder CMS eingesetzt werden?

Ja. Bei Shopware, TYPO3 oder gewachsenen Eigenentwicklungen funktioniert der Ansatz genauso. Häufig startet man mit APIs oder dem Checkout, weil dort die Schnittstellen klar sind und die Wirkung auf Kennzahlen sofort sichtbar wird. Bei stark verwobenen Templates ist der Schnitt schwieriger und braucht mehr Vorbereitung.

Was kostet eine Begleitung durch Never Code Alone?

Wir arbeiten ohne Festpreise und ohne Pakete. Am Anfang steht ein kostenloses Kennenlernen, in dem wir den Bestand ansehen und den Aufwand schätzen. Abgerechnet wird transparent nach Minuten, ohne Mindestlaufzeit. So bleibt jederzeit steuerbar, wie viel Begleitung ein Team wirklich braucht.