Zum Hauptinhalt springen

Migration mit Strangler Fig

Grundprinzip​

Das bestehende System wird schrittweise umwachsen,
statt es in einem Big-Bang neu zu bauen.

Der neue Teil übernimmt Stück für Stück Funktionalität,
bis der alte Teil überflüssig wird.

Der Name stammt aus der Natur:
Eine Würgefeige wächst um einen bestehenden Baum herum,
bis dieser verdrängt ist.

Ziel

  • Risiko minimieren
  • Business-Kontinuität sichern
  • Schrittweise Ownership aufbauen
  • Migration in kontrollierbaren Inkrementen durchführen

Strangler Fig ist keine Refactoring-Technik.
Es ist eine Evolutionsstrategie für Architektur.

Architekturelles Prinzip

Kernaussage:

  • Ein zentraler Routing-Punkt entscheidet
  • Alt- und Neuwelt existieren parallel
  • Migration erfolgt kontrolliert über Traffic-Steuerung

Typische Schritte

1️⃣ Domäne und Schnittgrenzen definieren​

  • Klare Fähigkeit wählen (kein technischer Layer!)
  • Abhängigkeiten identifizieren
  • Ownership klären

Fehler: „Wir extrahieren das User-CRUD.“

Richtig: „Wir extrahieren die Fähigkeit X mit klarer Business-Verantwortung.“

2️⃣ Thin Slice wählen​

Eine vertikale Scheibe mit:

  • klar messbarem Nutzen
  • begrenzter Abhängigkeit
  • überschaubarem Risiko

Kein „Infrastruktur-Service“ zuerst.

3️⃣ Anti-Corruption Layer (ACL)​

Der neue Service darf das Altmodell nicht übernehmen.

Der ACL:

  • übersetzt Datenmodelle
  • kapselt Legacy-Logik
  • verhindert implizite Kopplung

Ohne ACL entsteht:

Verteilter Monolith statt Evolution.

4️⃣ Neue Fähigkeit vollständig bauen​

Nicht nur Code:

  • Monitoring
  • Logging
  • SLOs
  • Rollback-Strategie
  • Deployment-Pipeline

Migration ohne Betriebsreife erzeugt technische Schulden.

5️⃣ Traffic schrittweise umlegen​

  • Canary Releases
  • Prozentuale Umschaltung
  • Shadow Traffic
  • Feature Toggles

Stabilität ist messbar, nicht gefühlt.

6️⃣ Altfunktion entfernen​

Erst wenn:

  • Gleichstand erreicht
  • SLOs stabil
  • Rollback getestet
  • Incidents analysiert

Alten Code aktiv löschen – nicht „deprecated“ liegen lassen.

Exit-Kriterien pro Schritt

  • Funktionaler Gleichstand für den migrierten Scope
  • SLOs für neue Strecke eingehalten
  • Observability vollständig
  • Incident- und Rollback-Pfad getestet
  • Altcode deaktiviert oder entfernt
  • Ownership klar beim neuen Team verankert

Typische Fehler

  • Migration rein technisch, ohne Team-Ownership
  • Zu große Schnitte („Wir extrahieren gleich alles“)
  • Kein Routing-Layer, sondern direkter Zugriff
  • Shared Database bleibt Integrationsweg
  • Alter Code wird nie gelöscht
  • Mehr neue Services als aktive Teams

Organisatorische Realität

Strangler Fig funktioniert nur, wenn:

  • Teams langfristig Ownership übernehmen
  • Plattform-Reife vorhanden ist
  • Monitoring und Resilienz mitziehen

Ohne organisatorische Anpassung bleibt es ein Parallelbetrieb.

Wann Strangler sinnvoll ist

  • Großer Legacy-Monolith
  • Hoher Änderungsdruck
  • Wunsch nach schrittweiser Modernisierung
  • Kein Budget für Big-Bang-Neubau

Fazit

Strangler Fig ist:

  • inkrementell
  • risikominimierend
  • evolutionsorientiert

Es ist kein Migrations-Shortcut, sondern ein diszipliniertes Architektur-Vorgehen.

Erfolgreich ist es nur, wenn Technik und Ownership gemeinsam wachsen.