Strangler-Fig-Migration
Bounded Contexts einzeln extrahieren, schrittweise hinter einer Routing-Schicht umstellen und an jedem Schritt einen Rollback verfügbar halten. Das Legacy-System bleibt während der gesamten Migration live.
Leistungen
Software-Modernisierung für US- und EU-Unternehmen
Legacy-Anwendungen modernisieren ohne das Risiko eines vollständigen Neubaus. YuSMP Group migriert geschäftskritische Systeme nach dem Strangler-Fig-Muster — inkrementelle Microservice-Extraktion, Framework-Upgrades und Cloud-Migration, die die Produktion durchgehend am Laufen halten. Typische Projekte: COBOL und Delphi zu Java oder .NET, PHP zu Node, Monolithen zu Microservices, On-Premises zu AWS, Azure oder GCP sowie .NET Framework zu .NET 8. Compliance ist von Anfang an eingebettet: DSGVO-konform, ISO-27001-bereit, SOC 2 Type II in Vorbereitung, HIPAA-fähig.
Die meisten Modernisierungsprojekte scheitern, wenn Teams vollständige Neuentwicklungen versuchen — der Scope explodiert, die Roadmap friert ein und das Unternehmen verliert die Geduld, bevor das neue System bereit ist. Wir setzen stattdessen standardmäßig auf Strangler-Fig-Refactoring: Bounded Contexts in Microservices extrahieren und Fähigkeiten einzeln hinter einer Routing-Schicht migrieren. Das Legacy-System bleibt während des gesamten Prozesses in der Produktion. Unser Ansatz ist architekturzentriert: Eine rein lesende Discovery-Phase kartiert das bestehende System und seine Abhängigkeiten, ein Migrationsplan quantifiziert Risiken und sequenziert die Phasen, und inkrementelle Cutovers beinhalten an jedem Schritt einen Rollback. Referenzmodernisierungen umfassen Fertigung (REHAU), Industriesysteme (CheckList) und Betriebsplattformen (xRouten). Sehen Sie es in der Praxis in unserer Refactoring xRouten Fallstudie.
Modernisierungspfade, die wir liefern
Framework-Upgrades
.NET Framework 4.x zu .NET 8, Java 8 zu Java 21 auf Spring Boot, PHP 5/7 zu PHP 8, AngularJS und Knockout zu React oder Vue. In-Place-Upgrades, wenn der ROI das Refactoring übertrifft.
Monolith → Microservices
Nur wo der ROI es rechtfertigt. Wir sagen Ihnen, wann ein sauberer modularer Monolith die bessere Antwort ist — Microservices verursachen Betriebskosten und zahlen sich erst bei echter Skalierung aus.
Cloud-Migration
Lift-and-Shift, Replatform oder Refactoring auf AWS, Azure oder GCP. Wir wählen das richtige Muster pro Workload — keine Einheitslösung, die die Cloud-Rechnung verschwendet.
Datenbank-Modernisierung
Oracle zu PostgreSQL, On-Premises SQL Server zu verwaltetem Azure SQL oder RDS, Mainframe DB2 zu Cloud-nativen Datenspeichern. Change Data Capture, Dual-Run und Reconciliation integriert.
Frontend-Modernisierung
jQuery, Knockout und AngularJS zu React, Vue oder Next.js. Design-System-Extraktion, Micro-Frontend-Grenzen und SSR, wo es bei Core Web Vitals seinen Einsatz rechtfertigt.
Modernisierungs-Technologie-Stack
.NET 8
C#
Java 21
Spring Boot
Node.js
TypeScript
Python
Go
PostgreSQL
MongoDB
Kafka
Kubernetes
AWS
Azure
GCP
Terraform
Strangler Fig
Domain-Driven Design
OpenTelemetry
Datadog
GitHub Actions
Argo CD
Wie wir Legacy-Systeme modernisieren
-
01
Rein lesende Discovery
Architektur-Mapping, Abhängigkeitsgraph, Hot-Path-Tracing und Risikobewertung über Module und Datenflüsse. Keine Code-Änderungen — wir lesen, profilieren und dokumentieren nur das System so, wie es tatsächlich läuft.
-
02
Planung
Eine Strangler-Fig-Roadmap mit quantifizierten Migrationsphasen, Abhängigkeits-Sequenzierung, Rollback-Strategie und Budgetrahmen pro Phase. Sie genehmigen den Plan, bevor eine einzige Zeile neuen Codes geschrieben wird.
-
03
Migration
Inkrementelle Cutovers pro Bounded Context mit wöchentlichen Demos, Dual-Run-Validierung und Reconciliation-Jobs. Jede Phase liefert eine echte Fähigkeit in die Produktion hinter Feature Flags – kein Slideware-Meilenstein.
-
04
Stabilisierung
SRE-Praktiken, Observability mit OpenTelemetry und Datadog, Error-Budget-Richtlinien und geordnete Deaktivierung von Legacy-Pfaden, sobald das neue System sich mindestens ein Quartal in der Produktion bewährt hat.
Engagement-Modelle
Festpreis Discovery + Plan
4–6 Wochen. Architektur-Audit, Abhängigkeitsgraph, Risikobewertung und ein phasenweiser Modernisierungsplan mit quantifizierten Budgets. Liefergegenstand, den Sie bei jedem Anbieter einsetzen können — nicht nur bei uns.
Zeit & Material Migration
Standardmodell für die Migration selbst. Monatliche Abrechnung pro Rolle und Seniorität, volle Transparenz über Stunden und Kapazität, Scope passt sich an, sobald Bounded Contexts ihre wahre Gestalt offenbaren.
Dediziertes Modernisierungs-Squad
Für langfristige, mehrjährige Programme. Ein dauerhaftes Squad – Backend, Frontend, DBA, DevOps, Delivery Lead – verantwortet die Modernisierungs-Roadmap gemeinsam mit Ihren internen Entwicklern.
Ausgewählte Projekte
Logistik · Last-Mile · Mobile
xRouten
Android + iOS Refactoring und Neuentwicklung für einen deutschen Last-Mile-Logistiker — Mehrpunkt-Routenplanung, Echtzeit-Fahrerverfolgung und In-App-Rechnungsstellung im EU-Betrieb.
Industrie · Fertigung
CheckList
Offline-first-Ökosystem, das Papierjournale für die Reaktorprozesskontrolle ersetzt — Android, Admin, Controller-Dashboard.
Fertigung · E-Commerce
REHAU
B2B-E-Commerce und Produktkonfigurator für einen globalen Polymerhersteller mit Multi-Regionen-Preisgestaltung, Lagerbestand und Händler-Workflows.
Warum US- und EU-Betreiber YuSMP für Software-Modernisierung wählen
DSGVO-konform · ISO-27001-bereit · SOC 2 Type II in Vorbereitung · HIPAA-fähig · PCI-DSS-Scope-bereit · CCPA-berücksichtigt
Strangler Fig statt Neuentwicklung
Wir pitchen keine Big-Bang-Neuentwicklungen. Der Standard ist inkrementelle Strangler-Fig-Migration mit durchgehend laufendem Legacy-System — geringeres Risiko, schnellerer ROI, kein Roadmap-Einfrieren.
Quantifiziertes Risiko vor Projektstart
Der Discovery-Liefergegenstand enthält ein Risikoregister, einen Abhängigkeitsgraph und phasenbezogene Budgetrahmen. Sie genehmigen den Plan mit Zahlen, nicht mit Bauchgefühl, bevor die Migration beginnt.
Compliance-bewusst
DSGVO, SOC 2, HIPAA und PCI-DSS-Scope vom ersten Tag an berücksichtigt. EU-Datenhaltung, US-Optionen auf Anfrage, prüfungsfertige Logs, verschlüsselte Endpunkte und AV-Verträge verfügbar.
Bei Zahlungs-, Kredit- und Healthcare-Modernisierungen arbeiten wir innerhalb Ihres bestehenden Compliance-Scopes — PCI-DSS-QSA, HIPAA-Business-Associate oder HITRUST — ohne Zertifizierungen zu unterbrechen.
Häufig gestellte Fragen
Sollen wir unsere Legacy-Anwendung neu schreiben oder modernisieren?
In den meisten Fällen modernisieren. Vollständige Neuentwicklungen scheitern in weit über 50 % der Fälle, weil sie die Roadmap einfrieren, den Scope vervielfachen und einen einzigen hochriskanten Cutover erzwingen. Wir bevorzugen standardmäßig das Strangler-Fig-Muster: das Legacy-System am Laufen lassen, neuen Traffic an extrahierte Microservices pro Bounded Context umleiten und Legacy-Code erst deaktivieren, wenn der neue Pfad in der Produktion bewiesen ist. Eine Neuentwicklung ist nur gerechtfertigt, wenn der Legacy-Stack nicht wartbar ist, keine Entwickler mehr vorhanden sind oder Compliance sie erzwingt — und selbst dann gehen wir phasenweise vor.
Was bedeutet Strangler-Fig-Migration konkret?
Strangler Fig ist ein inkrementelles Refactoring-Muster: Eine Routing-Schicht sitzt vor dem Legacy-System und leitet Anfragen für bestimmte Fähigkeiten schrittweise an neue Microservices um. Der Legacy-Code läuft für alles weiter, was noch nicht migriert ist. Jeder Bounded Context — Bestellungen, Abrechnung, Identität — wird extrahiert, deployt, im Dual-Run validiert und dann umgestellt. Ein Rollback ist eine Routing-Änderung, kein Redeploy. Über Monate hinweg “würgt” das neue System das alte, bis die Legacy-Anwendung sicher stillgelegt werden kann.
Wie lange dauert eine typische Modernisierung?
Discovery und Migrationsplan dauern 4–6 Wochen. Die Migration selbst hängt von der Systemgröße und der Risikobereitschaft ab: Ein mittelgroßer .NET-Framework- oder PHP-Monolith mit 200–400 KLOC landet typischerweise in 9–18 Monaten inkrementeller Migration. Mainframe- und COBOL-Programme sind von Natur aus mehrjährig. Wir arbeiten in 2–3-Monats-Phasen mit einem demonstrierbaren Cutover am Ende jeder Phase, sodass der Geschäftsnutzen kontinuierlich entsteht, statt auf ein Big-Bang-Release zu warten.
Können Sie das System modernisieren, ohne es offline zu nehmen?
Ja, das ist der Sinn von Strangler Fig. Das Legacy-System bleibt während der gesamten Modernisierung in der Produktion. Der Traffic verschiebt sich hinter einer Routing-Schicht (API-Gateway, Reverse Proxy oder Feature Flag), sobald jeder Bounded Context online geht. Wir betreiben den alten und neuen Pfad im Dual-Run, vergleichen Ausgaben und kehren den kanonischen Schreibpfad erst um, wenn die Parität bestätigt ist. Wartungsfenster beschränken sich auf Datenbank-Cutovers und dauern in der Regel unter einer Stunde, geplant mit Ihrem Betriebsteam.
Unterstützen Sie bestimmte Legacy-Stacks (COBOL, Delphi, .NET Framework, Oracle Forms)?
Ja. Wir haben Modernisierungen durchgeführt von .NET Framework 4.x zu .NET 8, Java 8 zu Java 21 auf Spring Boot, PHP 5/7 zu PHP 8 und Node.js, Delphi/Pascal zu C# und TypeScript, Oracle Forms und PL/SQL zu PostgreSQL mit Node- oder Java-Services, klassischem ASP und VB6 zu modernen Web-Stacks sowie AngularJS/Knockout/jQuery zu React, Vue oder Next.js. COBOL- und Mainframe-Workloads werden bei Bedarf in Partnerschaft mit spezialisierten Re-Hosting-Anbietern bearbeitet.
Wie handhaben Sie Datenmigration und Dual-Run-Phasen?
Daten sind der riskanteste Teil jeder Modernisierung, daher behandeln wir sie als erstklassigen Workstream. Wir beginnen mit Change Data Capture (Debezium, nativem Log-Shipping oder Anbieter-CDC), um neue und alte Datenspeicher synchron zu halten. Im Dual-Run gehen Schreiboperationen in beide Systeme, und ein Reconciliation-Job meldet Abweichungen innerhalb einer Stunde. Wir frieren den Legacy-Schreibpfad erst nach einem Paritätsfenster ein — typischerweise 2–4 Wochen — und halten die Legacy-Datenbank für 90 Tage nach dem Cutover als schreibgeschützten Fallback vor.