Monolith zu Microservices: ein Enterprise-Migrationsleitfaden

Marcus Chen Delivery- & Backend-Lead, YuSMP Group · Spezialist für verteilte Systeme und Enterprise-Architektur-Migrationen

TL;DR — was Migration wirklich bedeutet

Die Migration eines Enterprise-Monolithen zu Microservices ist vor allem keine Coding-Übung. Es ist eine organisatorische, datentechnische und operative Transformation, die bei einem großen System 18–36 Monate dauert. Hier ist, wofür Sie sich tatsächlich entscheiden:

• Service-Extraktion: Bounded Contexts identifizieren und nacheinander mit dem Strangler-Fig-Muster extrahieren
• Datendekomposition: die gemeinsame monolithische Datenbank in service-eigene Datenbanken aufteilen — das schwierigste technische Problem jeder Migration
• Organisationsausrichtung: Teams nach Services umstrukturieren (Conways Gesetz), andernfalls kehrt Ihre Code-Struktur zur Entsprechung Ihres Organigramms zurück
• Operative Reife: Distributed Tracing, Service Mesh, unabhängige CI/CD-Pipelines und On-Call-Runbooks — alles Voraussetzungen, keine Nachgedanken
• Kosten: typischerweise 15–25 % der ursprünglichen Build-Kosten pro Migrationsjahr für einen großen Enterprise-Monolithen

Wann migrieren (und wann nicht)

Die wichtigste Architekturfrage ist nicht wie man migriert, sondern ob man es sollte. Viele Enterprise-Monolithen sollten nicht migriert werden — zumindest nicht vollständig und nicht jetzt.

Starke Signale, dass Migration gerechtfertigt ist

• Deployment-Kopplung blockiert die Geschwindigkeit: Teams warten aufeinander beim Deployment, weil alles als ein Artefakt deployed wird. Der Bug eines Teams verzögert die Features fünf anderer Teams.
• Skalierung ist alles oder nichts: Ein Lastspitze in einem Subsystem (Zahlungsverarbeitung, Empfehlungs-Engine) zwingt die gesamte Anwendung zur Skalierung, mit unnötigen Infrastrukturkosten.
• Regulatorische Isolierung ist erforderlich: DSGVO-Datenresidenz, BDSG-Auftragsverarbeitung, PCI-DSS-Karteninhaberdaten-Isolierung oder SOC-2-Scope-Reduzierung verlangen die physische Trennung bestimmter Datenflüsse.
• Technologie-Lock-in blockiert Funktionalität: Ein kritisches neues Feature erfordert eine Runtime oder Sprache, die mit dem Stack des Monolithen inkompatibel ist, und die gesamte Anwendung neu aufzubauen ist unverhältnismäßig.

Starke Signale, dass Migration warten sollte

• Ihr Team hat weniger als 30 Entwickler — der Koordinationsaufwand von Microservices überwiegt den Deployment-Nutzen in dieser Größenordnung.
• Ihnen fehlen reife CI/CD-Pipelines, automatisierte Tests über 60 % Abdeckung oder zentrale Observability — Sie werden ein verteiltes Chaos schaffen, keine Microservices-Plattform.
• Niemand besitzt Bounded-Context-Mapping — ohne ein klares Domänenmodell werden Sie falsche Grenzen extrahieren und Jahre damit verbringen, was Sie falsch aufgeteilt haben, wieder zusammenzuführen.
• Der Monolith funktioniert und der Geschäftsschmerz ist bescheiden — wenn Ihr aktuelles Liefertempo akzeptabel ist, kann inkrementelle Legacy-Modernisierung mehr Wert pro Euro liefern als eine vollständige Dekomposition.

Die verteilte Spaghetti-Falle

Das häufigste Scheitermuster bei Enterprise-Microservices-Migrationen ist die Schaffung eines verteilten Monolithen: eines Systems, das in separate deploybare Einheiten aufgeteilt wurde, aber alle Kopplungen des ursprünglichen Monolithen behält, während es die operative Komplexität verteilter Systeme hinzufügt.

Symptome eines verteilten Monolithen umfassen:

• Services teilen sich eine einzige Datenbank oder Schema — Änderungen an einer Tabelle erfordern die Koordination von Releases über fünf Teams
• Synchrone REST-Ketten umfassen 4–8 Services pro Benutzeranfrage — ein Timeout in Service D kaskadiert zurück zu Service A
• Eine einzelne gemeinsame Bibliothek enthält das Domänenmodell, die Geschäftslogik oder die Konfiguration — jeder Service muss gemeinsam releasen, wenn sie sich ändert
• Services werden gemeinsam nach demselben Release-Schedule deployed, was den Unabhängigkeits-Deployment-Vorteil zunichte macht

Das Strangler-Fig-Muster: inkrementelle Extraktion

Martin Fowlers Strangler-Fig-Muster (benannt nach der tropischen Liane, die ihren Wirtsbaum umwächst und schließlich ersetzt) ist der Branchenstandard für Zero-Downtime-Migration großer Produktionssysteme. Der zentrale Gedanke: Sie schreiben das gesamte System nie neu; Sie leiten bestimmte Anfragepfade nacheinander an neue Services um.

Die Mechanik umfasst drei Elemente:

1. Facade: Ein API-Gateway, Reverse Proxy (Nginx, Envoy) oder eine BFF-Schicht steht vor dem Monolithen und den entstehenden Services und routet Anfragen basierend auf Pfad, Headern oder Feature Flags.
2. Extrahieren: Ein Bounded Context wird in einen eigenständigen Service mit eigenem Codebase, Deployment-Pipeline und (letztendlich) eigener Datenbank extrahiert. Der Code des Monolithen für diesen Kontext bleibt bestehen, aber der Traffic wird über die Facade umgeleitet.
3. Verifizieren und würgen: Sobald der neue Service 100 % des Traffics für diesen Kontext ohne Regression verarbeitet, wird der entsprechende Monolith-Code entfernt. Das «Würgen» ist für diesen Kontext abgeschlossen.

Praktische Regeln für die Extraktionsreihenfolge nach dem Strangler-Fig-Muster:

• Mit leselastigen, schreibarmen Services beginnen — Reporting, Katalog-Browsing, Benachrichtigungseinstellungen. Sie haben weniger transaktionale Abhängigkeiten und lassen sich sicherer zuerst extrahieren.
• Zuerst Blatt-Kontexte extrahieren — Services, die keine anderen internen Services aufrufen. Von außen nach innen in Richtung Core zu arbeiten reduziert den Blast-Radius früher Extraktionen.
• Den Zahlungs- oder Auth-Kontext nicht zuerst extrahieren — dies sind hochkritische, hochgekoppelte Domänen. Extrahieren Sie sie, nachdem Ihr Team mit einfacheren Kontexten Zuversicht gewonnen hat.
• Die Facade schlank halten — keine Geschäftslogik in den Router einbauen. Er wird zu einem neuen Monolithen.

Dekomposition der gemeinsamen Datenbank

Wenn das Strangler-Fig-Muster die am häufigsten diskutierte Herausforderung bei der Microservices-Migration ist, ist die Datendekomposition die praktisch schwierigste. Die meisten Enterprise-Monolithen teilen eine einzige relationale Datenbank mit Hunderten von Tabellen, domänenübergreifenden Fremdschlüsselbeziehungen und Stored Procedures, die Geschäftslogik einbetten.

Die Dekomposition verläuft in Stufen:

1. Eigentümerschaft identifizieren: Für jede Tabelle und Spalte einen einzelnen eigentümenden Service zuweisen. Dies ist eine Domänenmodellierungsübung, keine technische. Verwenden Sie Event-Storming-Sitzungen mit Geschäfts-Stakeholdern, um die wahre Eigentümerschaft zu ermitteln.
2. Zugriff abstrahieren: Bevor Datenbanken physisch getrennt werden, werden service-level Lese-/Schreibpfade über die API des neuen Services eingeführt. Andere Services fragen die gemeinsame Tabelle nicht mehr direkt ab, sondern rufen den eigentümenden Service auf. Dies deckt verborgene Kopplung auf.
3. Dual-Write-Übergang: Während des Cutover-Fensters wird sowohl in die gemeinsame Tabelle des Monolithen als auch in das private Schema des neuen Services gleichzeitig geschrieben. Konsistenz wird verifiziert, bevor das neue Schema als kanonisch festgelegt wird.
4. Migrieren und umstellen: Sobald Dual-Write stabil ist und Leseabfragen über den neuen Service geleitet werden, wird das private Schema kanonisch und Dual-Write wird entfernt. Die gemeinsame Tabelle wird schreibgeschützt, dann schließlich gelöscht.

Organisationsstruktur und Conways Gesetz

Conways Gesetz besagt, dass Organisationen Systeme entwerfen, die ihre eigene Kommunikationsstruktur widerspiegeln. Die praktische Implikation für die Migration: Wenn Sie Microservices extrahieren, ohne die Teamorganisation zu ändern, werden sich die Services schrittweise zur Form Ihres Organigramms hin entwickeln — und Sie bauen den Monolithen in verteilter Form neu auf.

Effektive Migration erfordert das inverse Conway-Manöver: die absichtliche Umstrukturierung von Teams entsprechend den gewünschten Service-Grenzen, damit Teamverantwortung, Kommunikationsmuster und Service-Eigentümerschaft übereinstimmen.

Das bedeutet:

• Jeder Service hat ein einzelnes eigentümendes Team — kein «Platform-Team», das alles besitzt
• Teams sind dimensioniert, um 1–3 Services end-to-end zu besitzen (Entwicklung, Deployment, On-Call)
• Inter-Service-Kommunikation wird zu einem formalen API-Vertrag, der vom produzierenden Team verwaltet wird, kein informaler Datenbank-Join
• Platform-Teams besitzen Infrastruktur-Primitive (Service Mesh, CI-Templates, Observability), aber keine Domänen-Services

Hier spielt auch die Strategie der Enterprise-System-Integration eine Rolle: Die Verträge zwischen Services werden zur langfristigen Integrationsschnittstelle, nicht das Datenbankschema.

Kosten- und Zeitplan-Benchmarks

Realistische Kosten-Benchmarks für Enterprise-Monolith-Migrationen variieren stark je nach Systemgröße und Kopplung, aber die folgenden Bereiche stimmen mit Branchendaten und unserer eigenen Projekterfahrung überein:

Diese Zahlen setzen voraus, dass die Migration teils vom bestehenden Team (Domänenwissen) und teils von einem externen Spezialpartner (Architekturmuster, Tooling) besetzt wird. Beachten Sie, dass «vollständige Dekomposition» selten das Ziel ist — die meisten Unternehmen streben nach selektiver Dekomposition hochwertiger Bounded Contexts und lassen stabile, veränderungsarme Subsysteme dauerhaft im Monolithen.

Infrastrukturkosten steigen während der Migration ebenfalls erheblich: Der parallele Betrieb von Monolith und Services sowie neues Tooling für Service Mesh, Distributed Tracing und Secret Management erhöht die operative Infrastrukturausgaben typischerweise um 30–50 % für die Dauer des Übergangs.

Observability und Rollback-Strategie

Sie können ein verteiltes System nicht sicher betreiben, das Sie nicht beobachten können. Vor der Extraktion des ersten Services muss Folgendes vorhanden sein:

• Distributed Tracing: OpenTelemetry mit einem Backend (Jaeger, Tempo, Datadog APM), damit Sie eine einzelne Benutzeranfrage über Service-Grenzen hinweg verfolgen können. Dies ist nicht verhandelbar.
• Zentralisierte Log-Aggregation: Strukturierte JSON-Logs aller Services, die an einen einzigen abfragbaren Speicher weitergeleitet werden (Loki, Elasticsearch, CloudWatch Logs).
• Service-level SLIs/SLOs: Fehlerrate, Latenz p95 und Verfügbarkeitsziele pro Service definieren, bevor er Produktionstraffic erhält. Alerts auf SLO-Burn-Rate auslösen, nicht auf Rohmetriken.
• Feature Flags an der Facade: Die Fähigkeit aufrechterhalten, Traffic für jeden extrahierten Kontext sofort zum Monolithen zurückzuleiten. Das Strangler-Fig-Muster funktioniert nur, wenn Sie es schnell umkehren können.

Die Rollback-Strategie muss für jede Extraktionsphase explizit sein. Dokumentieren Sie für jede Service-Extraktion:

• Die spezifische Facade-Routing-Regel zum Zurücksetzen (eine Zeile Änderung in der API-Gateway-Konfiguration)
• Den Dual-Write-Status — wenn Daten in beide Schemata geschrieben wurden, welches ist kanonisch
• Das akzeptable Daten-Staleness-Fenster, wenn die Datenbank des neuen Services abgewichen ist
• Den On-Call-Engineer, der die Rollback-Entscheidung trifft, und den Zeitschwellenwert, der automatischen Rollback auslöst

Phasierter Migrations-Fahrplan

Ein strukturierter Vier-Phasen-Fahrplan reduziert Risiken und stellt sicher, dass jede Phase messbaren Wert liefert, bevor die nächste beginnt.

1. Phase 1 — Fundament (Monate 1–3): Noch keine Services extrahieren. In Voraussetzungen investieren: zentralisierte Observability (Tracing, Logging, Alerting), unabhängige CI/CD-Pipeline-Templates, eine Container-Plattform (Kubernetes oder ECS), Domänen-Event-Katalog und Boundary-Mapping-Workshops mit Geschäfts- und Engineering-Stakeholdern. Deliverable: ein priorisierter Extraktions-Backlog mit Bounded-Context-Karte.
2. Phase 2 — Erste Extraktion (Monate 3–6): Einen risikoarmen, hochwertigen Bounded Context mit dem Strangler-Fig-Muster extrahieren. Das Extraktions-Playbook validieren (Facade-Routing, Dual-Write, Datenmigration, SLO-Monitoring, Rollback). Diese Phase ist ebenso ein Prozess-Trockenübung wie eine technische Lieferung. Deliverable: ein unabhängig deployedr Service in Produktion, dokumentiertes Extraktions-Runbook.
3. Phase 3 — Systematische Dekomposition (Monate 6–24+): Das validierte Playbook iterativ auf die verbleibenden Prioritäts-Bounded-Contexts anwenden. Jedes Extraktionsteam folgt demselben Muster. Die Datendekomposition beschleunigt sich, wenn die Eigentümerschaft der gemeinsamen Datenbank klarer wird. Die Organisationsumstrukturierung (inverses Conway-Manöver) findet parallel statt. Deliverable: 60–80 % der hochänderlichen Geschäftslogik läuft als unabhängige Services.
4. Phase 4 — Monolith-Residualisierung: Der verbleibende Monolith enthält stabile, veränderungsarme Subsysteme, die selten berührt werden. Für jeden Residualkontext explizit entscheiden, ob er weitere Extraktionskosten rechtfertigt. Für die meisten Unternehmen ist es die richtige wirtschaftliche Entscheidung, 20–30 % des ursprünglichen Systems in einem «Residual-Monolithen» zu belassen. Deliverable: dokumentierte Residual-Monolith-Richtlinie, Stilllegungsplan für nicht mehr verwendete gemeinsame Datenbanktabellen.

FAQ

Sollten wir unseren Monolithen zu Microservices migrieren?

Nicht automatisch. Migrieren Sie, wenn Sie konkreten organisatorischen Schmerz haben: Teams, die durch Deployment-Kopplung blockiert werden, Services, die unabhängig skalieren müssen, oder regulatorische Isolierungsanforderungen (DSGVO, BDSG). Wenn Ihr Team kleiner als 30 Entwickler ist, Ihre CI/CD-Reife fehlt oder Ihr Monolith gut funktioniert und der Geschäftsschmerz bescheiden ist, kostet die Migration mehr als sie bringt. Beginnen Sie mit einem ehrlichen Bounded-Context-Audit und einer klaren Liste der spezifischen Probleme, die Sie lösen möchten.

Was ist das Strangler-Fig-Muster?

Das Strangler-Fig-Muster platziert eine Routing-Facade vor Ihrem Monolithen und leitet schrittweise spezifische Anfragepfade zu neuen Microservices um, während der Monolith alles andere weiterhin verarbeitet. Mit der Zeit extrahieren Sie Kontext nach Kontext, bis der Monolith so wenig Traffic verarbeitet, dass er stillgelegt werden kann. Es ist der sicherste Ansatz zur Migration eines lebenden Produktionssystems, da er vollständig inkrementell und bei jedem Schritt umkehrbar ist.

Was ist ein verteilter Monolith?

Ein verteilter Monolith ist das schlimmste Ergebnis einer schlecht geplanten Migration: mehrere Services, die noch eine einzige Datenbank teilen, synchrone Aufrufketten, die das gesamte System umspannen, oder eine gemeinsame Bibliothek, die alle Services zum gemeinsamen Deployment zwingt. Sie erhalten die gesamte operative Komplexität verteilter Systeme ohne Deployment-Unabhängigkeit. Die Grundursache ist fast immer übersprungene oder unbegrenzt aufgeschobene Datendekomposition.

Wie lange dauert eine Migration?

Echter Mehrwert — ein unabhängig deployeter, unabhängig skalierbarer Service — kann in 3–6 Monaten mit dem Strangler-Fig-Muster geliefert werden. Die vollständige Dekomposition eines großen Enterprise-Monolithen dauert 18–36 Monate. Der Zeitplan wird mehr durch Datenkopplungskomplexität und organisatorisches Change-Management bestimmt als durch die Coding-Arbeit selbst. Planen Sie für die org. Änderung genauso lange wie für die technische Arbeit.

Wie vermeiden wir Ausfallzeiten während der Migration?

Die Routing-Facade des Strangler-Fig-Musters ist Ihr primärer Mechanismus: Traffic kann in Sekunden zum Monolithen zurückgeleitet werden, wenn der neue Service versagt. Ergänzen Sie dies mit Dual-Write während Datenbank-Cutover-Phasen, Blue-Green-Deployments auf Service-Ebene, Feature Flags an der Facade und umfassendem Distributed Tracing, um Regressionen zu erkennen, bevor sie alle Nutzer betreffen. Niemals einen Big-Bang-Datenbank-Cutover auf einem Live-System durchführen — immer Dual-Write mit Validierungsfenster betreiben.

Zuletzt aktualisiert am 6. Juni 2026. Kosten-Benchmarks basieren auf YuSMP Group Projektdaten und öffentlich verfügbaren Branchenberichten (Gartner, CNCF, ThoughtWorks Technology Radar). Individuelle Migrationskosten variieren je nach Monolith-Größe, Kopplung, Teamstruktur und Observability-Reife.