Software-Modernisierung für US- und EU-Unternehmen

Die Preise sind festscoped und all-in, angegeben in USD über drei Stufen. Ein Audit plus Quick Wins beginnt ab 2.300 $; systemisches Refactoring der ersten Bounded Contexts ab 9.200 $; eine vollständige durchgängige Modernisierung ab 28.700 $. Die genaue Zahl richtet sich nach Systemgröße und Kopplung, dem Datenmigrationsrisiko, dem Compliance-Scope und der Zielplattform. Sie sehen das Budget als Einzelposten am Ende der Discovery und geben es frei, bevor eine Zeile Code geschrieben wird. Es gibt keinen Recruiting-Aufschlag, keine Tool-Zuschläge, und Cloud-Gebühren laufen über Ihre eigenen Konten, sodass Sie den Kostenhebel behalten.

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.

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.

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.

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.

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.

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.

Ja, und das ist der Standardfall. Strangler-Fig ermöglicht es, Feature-Team und Modernisierungs-Track parallel laufen zu lassen: Neue Features landen ab Tag eins auf extrahierten Microservices, während Legacy-Code die noch nicht migrierten Bounded Contexts bearbeitet. Wir koordinieren Branch-Konventionen, Service-Grenzen und eine Sperrliste für Legacy-Module, damit sich die beiden Tracks nicht überschneiden. Typischerweise werden 20–30 % der Sprint-Kapazität des Feature-Teams für Modernisierungs-Integrationsarbeit reserviert; wir berücksichtigen das im Phasenplan.

Externe Integrationen werden in der Discovery katalogisiert und nach Migrationsrisiko klassifiziert. Integrationen mit dokumentierten APIs werden zuerst hinter einer internen Adapter-Schicht gekapselt, sodass neue Microservices den Adapter statt den Legacy-Konnektor direkt aufrufen. End-of-Life-Vendor-APIs werden markiert und während der Migration entweder ersetzt oder mit einem Kompatibilitäts-Shim versehen. Integrationen, die nicht während der Migration ersetzt werden können, bleiben im Legacy-System und werden zuletzt migriert.

Das kommt vor, und wir planen dafür. Im Dual-Run läuft ein Reconciliation-Job, der die Ausgaben von Legacy- und neuem Pfad für jede Transaktion vergleicht. Abweichungen werden in erwartete Unterschiede (bewusste Verhaltensänderungen), jetzt sichtbare Legacy-Bugs und neue Bugs im migrierten Code klassifiziert. Legacy-Bugs, die während der Migration entdeckt werden, werden dokumentiert und mit Ihnen triagiert — manche werden im neuen Service behoben, andere als bekannte Probleme für Post-Cutover-Patches notiert.

Wir definieren zu Beginn drei Ebenen von Erfolgsmetriken: technisch (Testabdeckung, Deploy-Frequenz, MTTR, Fehlerrate bei migrierten Services), operativ (Vorfallsreduktion, Infrastrukturkostendelta, Bereitschaftsaufwand) und geschäftlich (Feature-Velocity auf dem neuen Stack, Time-to-Market für neue Funktionen). Diese werden in monatlichen Programm-Reviews berichtet. Jede Phase endet mit einem demonstrierbaren Cutover und einem Health-Dashboard, das den Legacy-Traffic-Prozentsatz zeigt.