Legacy-Modernisierung — Strangler-Fig statt Big-Bang

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)

1. Reverse Engineering: Wir verstehen die Legacy-Anwendung gemeinsam mit Ihrem Team.
2. Façade aufbauen: Eine moderne API-Schicht (Spring/Java) sitzt vor der Legacy.
3. Modul für Modul ersetzen: Neue Implementierung nimmt Anfragen der Façade an, alte Implementierung läuft parallel weiter.
4. Cutover pro Modul: Sobald das neue Modul stabil läuft, wird das alte abgeschaltet.
5. 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.