Legacy-Modernisierung — Strangler-Fig statt Big-Bang
Schrittweise Ablösung von Legacy-Anwendungen mit Strangler-Fig-Pattern. Festpreis pro Modul, kein Big-Bang, kein Stillstand.
Big-Bang-Migrationen scheitern in 60–80 % der Fälle. Wir lösen Bestandssysteme Modul für Modul ab, ohne dass Ihr Geschäft stehen bleibt.
Wann brauchen Sie das?
Sie haben eine Bestandsanwendung
(Java EE, .NET-Monolith, Cobol, klassisches PHP), die kritisch fürs Geschäft ist, aber wartungsteuer wird.
Wissen über das System sitzt in 1–2 Personen
und die gehen bald in Pension.
Anpassungen dauern Wochen
statt Tage, weil jede Änderung Regressionen auslöst.
Eine komplette Neuentwicklung
ist zu teuer, zu riskant und würde 2 Jahre Stillstand bedeuten.
Was wir liefern
Ist-Analyse
Architektur, Schnittstellen, fachliche Module, Risiken — dokumentiert.
Strangler-Fig-Strategie
Welche Module zuerst, welche zuletzt, welche bleiben unverändert.
API-First-Vorbereitung
Wir kapseln die Legacy-Anwendung mit modernen APIs, bevor wir Module ablösen.
Schrittweise Migration
pro Modul ein Mini-Projekt mit eigenem Festpreis und Go-Live.
Datenbank-Migration
schemaschonend, mit Backwards-Compatibility-Layer wo nötig.
Test-Suite-Aufbau
für die Legacy-Logik, bevor sie ersetzt wird — kein „blindes" Ablösen.
Methodik (Strangler-Fig-Pattern)
- 01
Reverse Engineering
Wir verstehen die Legacy-Anwendung gemeinsam mit Ihrem Team.
- 02
Façade aufbauen
Eine moderne API-Schicht (Spring/Java) sitzt vor der Legacy.
- 03
Modul für Modul ersetzen
Neue Implementierung nimmt Anfragen der Façade an, alte Implementierung läuft parallel weiter.
- 04
Cutover pro Modul
Sobald das neue Modul stabil läuft, wird das alte abgeschaltet.
- 05
Vollständige Ablösung
Wenn alle Module migriert sind, wird die Legacy-Anwendung dekommissioniert.
Typische Use Cases
Versicherungs-Bestandsführung
Tariffmodul wird ersetzt, Inkasso bleibt zunächst Legacy
Industrie-ERP-Erweiterung
Eigenentwicklung neben SAP/Microsoft Dynamics, schrittweise
Java-EE-Monolith
zu Microservices — pro Bounded Context ein neuer Service
Cobol-Backoffice
zu modernem Spring/Java — Datenbankschema bleibt, Logik wandert
Was wir NICHT versprechen
Kein „Big-Bang-Cutover"
wer das verspricht, verschweigt das Risiko.
Keine Migration ohne Test-Coverage
wir bauen Tests, bevor wir ablösen.
Keine Lift-and-Shift-Cloud-Migration
ohne fachliche Verbesserung — das verschiebt nur Probleme.
Häufige Fragen
Wie lange dauert eine typische Legacy-Modernisierung?
12–36 Monate für einen größeren Monolith, in vielen kleinen Lieferungen. Aber: Erste produktive Verbesserung oft schon nach 8–12 Wochen.
Können Sie Cobol/.NET-Legacy lesen?
Ja, wir haben Erfahrung mit Cobol, klassischem .NET, Java EE, PHP-Monolithen. Wenn nicht, sagen wir das.
Bleiben unsere Daten erhalten?
Ja. Datenbank-Migration ist Teil jedes Modul-Schritts, mit Rollback-Option.
Was, wenn ein Modul nicht ablösbar ist?
Dann lassen wir es. Strangler-Fig ist iterativ — wir entscheiden pro Modul neu.
Welcher Prozess kostet Ihr Team jeden Tag Zeit?
Im kostenlosen Analysegespräch schauen wir gemeinsam darauf und klären, ob eine Automatisierung sinnvoll ist.
60 Minuten · unverbindlich