Insights · Cluster: AI-nativ Modernization

Warum Zeit die wahren Kosten der Modernisierung sind – und wie AI diese senkt

Daria Muehlethaler
Daria Muehlethaler Head of Business Development & Sales · LinkedIn · 7 Min. Lesezeit · Oktober 2026

Hier ist der Satz, den die meisten Business Cases für Modernisierungsprojekte nicht auf die erste Folie schreiben möchten: Während der gesamten Migration zahlen Sie für zwei Systeme.

Die Legacy-Plattform läuft weiter – das muss sie auch, denn auf ihr basiert weiterhin das operative Geschäft. Parallel dazu wird die neue Plattform aufgebaut und eingeführt. Lizenzen, Infrastruktur, Betrieb und – am teuersten – Menschen: Jeder Monat im Dual Run bedeutet doppelte Kosten, zusätzliche kognitive Belastung und mehr On-Call-Aufwand.

Eine Studie von McKinsey zu Cloud- und Plattformmigrationen quantifiziert, was Teams aus der Praxis längst kennen: Unternehmen geben während Migrationsphasen jährlich etwa 14 % mehr aus, was wesentlich auf diese Dual-Run-Kosten zurückzuführen ist. Gartner bezeichnet dieses Phänomen als „Migration Bubble“. Ein Business Case, der vom ersten Tag an eine gleichmässig sinkende Kostenkurve zeigt, ist nicht optimistisch – er ist unrealistisch, und Finance-Teams erkennen das sehr schnell.

Ein realistischer Business Case für Modernisierung folgt deshalb einer J-Kurve: Die Kosten steigen zunächst über den Status quo – durch Investition und Dual Run –, fallen später darunter und entwickeln sich ab diesem Punkt zunehmend zugunsten der modernen Plattform.

Sobald man diese Kurve akzeptiert, wird die strategische Schlussfolgerung sehr klar:

Der grösste Hebel in der Wirtschaftlichkeit einer Modernisierung ist nicht die Höhe der Investition – sondern die Dauer des Dual Runs.

Die Zahlen auf beiden Seiten der J-Kurve

Das Zielbild ist gut dokumentiert. Branchen-Benchmarks von McKinsey, Kyndryl und Accenture berichten durchweg von 30–40 % niedrigeren Kosten für IT-Infrastruktur und Wartung nach einer Modernisierung.

Die strukturelle Veränderung hinter diesen Zahlen ist noch bedeutender: Organisationen mit einem hohen Anteil an Legacy-Systemen geben häufig 60–80 % ihres IT-Budgets dafür aus, bestehende Systeme am Laufen zu halten. Gut konzipierte moderne Plattformen können dieses Verhältnis auf etwa 20–30 % für Wartung umkehren – wodurch ein deutlich grösserer Teil des Budgets für den Aufbau neuer Fähigkeiten verfügbar wird. Auf Infrastrukturebene liegen die Kosten für Cloud-Betrieb häufig bei 30–50 % der vergleichbaren On-Premises-Kosten.

Doch all diese Vorteile beginnen erst nach dem Break-even. Davor dominiert die Phase zusätzlicher Dual-Run-Kosten. Deshalb können zwei Modernisierungsprogramme mit identischer Zielarchitektur und derselben Investitionssumme völlig unterschiedliche Wirtschaftlichkeitsprofile haben – allein deshalb, weil eines 24 Monate im Dual Run verbringt und das andere nur 11.

Verkürzt man dieses Zeitfenster, sinken drei Kostenarten gleichzeitig:

  • Die direkten Kosten sinken. Weniger Monate mit doppelter Infrastruktur, doppelten Lizenzen und parallelem Betrieb. Bei einem Programm mit einem siebenstelligen jährlichen Dual-Run-Aufschlag ist jeder eingesparte Monat eine Position, die der CFO direkt im Business Case sieht.
  • Die Komplexität hört auf, sich weiter aufzubauen. Während des Dual Runs kann jede Änderung beide Systeme betreffen – regulatorische Anpassungen, Produktänderungen oder neue Schnittstellen müssen auf beiden Seiten bewertet werden. Je länger der Dual Run dauert, desto stärker driften die Systeme auseinander, desto mehr Reconciliation Logic entsteht und desto mehr Legacy wird bereits während der Migration selbst aufgebaut. Die Komplexität des Dual Runs wächst nicht linear mit der Zeit – sie verstärkt sich selbst.
  • Menschen müssen nicht länger in zwei Welten arbeiten. Der organisatorische Aufwand wird häufig am wenigsten gemessen: Engineers warten das alte System, während sie gleichzeitig das neue aufbauen; Support-Teams müssen zunächst klären: „In welchem System ist das passiert?“; Business-Nutzer müssen wissen, welches System in welcher Phase massgeblich ist. Auch diese Unsicherheit verursacht Kosten – langsamere Incident Resolution, doppelte Abstimmungen und zusätzliche Belastung gerade für die Senior Engineers, die beide Systeme kennen.

Wo AI das Dual-Run-Fenster tatsächlich verkürzt

Genau darin liegt die Business-Logik hinter AI-beschleunigter Modernisierung. Sie muss nicht als Magie dargestellt werden: Das Dual-Run-Fenster ist lang, weil die Arbeit innerhalb dieses Fensters langsam ist – das Legacy-System verstehen, es transformieren, das Ergebnis testen und alles dokumentieren. Genau in diesen vier Bereichen kann AI den Aufwand besonders stark reduzieren.

In unserem Modernization Framework sieht der Ablauf so aus – die Zahlen stammen aus unserer Projektpraxis und werden pro Engagement verifiziert: Eine AI-gestützte Analyse erfasst eine Codebasis mit mehr als 7.000 Dateien in etwa zwei Stunden und erstellt einen rund 194-seitigen System Report. Für dieselbe Analyse wären früher Wochen manueller Arbeit durch Senior Engineers erforderlich gewesen.

Beim Refactoring generiert AI einen grossen Teil der mechanischen Transformation, während Human Gates jeden Merge bis zum Review durch einen benannten Senior Engineer zurückhalten. Jede Änderung bleibt bis zu einem Commit SHA rückverfolgbar, und der vollständige Audit Trail kann für Auditoren exportiert werden.

Testgenerierung und Dokumentation – klassische Zeitfresser in Migrationsprojekten und Bereiche, die sich kaum beschleunigen lassen, wenn die notwendige Disziplin fehlt – laufen AI-gestützt unter demselben Review-Modell. Testing und Validation machen typischerweise 40–50 % des gesamten Migrationsaufwands aus.

Die Auswirkungen auf den Business Case sind strukturell – nicht kosmetisch. Analysen, die früher ein Quartal dauerten, können innerhalb weniger Tage abgeschlossen werden. Dadurch lassen sich Sequencing-Entscheidungen früher treffen. Der Transformation Throughput steigt, Domänen werden früher migriert und verlassen den Dual Run schneller. Mit jeder vollständig migrierten Domäne reduziert sich die Basis der doppelten Kosten bereits während das Programm noch läuft.

Die J-Kurve behält ihre Form, wird aber schmaler und flacher: weniger Zeit oberhalb der Status-quo-Linie, ein früherer Break-even und ein geringerer insgesamt gezahlter Dual-Run-Premium.

Die organisatorische Seite der Gleichung

Nichts davon funktioniert als rein technisches Programm. Modernisierungen geraten gerade dann in Schwierigkeiten, wenn sie ausschliesslich als Technology Initiative behandelt werden. Drei organisatorische Entscheidungen müssen die technische Beschleunigung begleiten:

  • Definieren Sie pro Domäne, welches System authoritative ist. Ein Dual Run funktioniert nur mit expliziten Regeln dafür, welches System für welche Daten und Prozesse in welcher Phase massgeblich ist. Diese Regeln müssen vor der Migration festgelegt werden – nicht während eines Incidents ausgehandelt werden. Eine veröffentlichte Cut-over Map verwandelt Unsicherheit in einen konkreten Plan.
  • Setzen Sie auf der Legacy-Seite klare Change Discipline durch. Jede Funktion, die während des Dual Runs zum Legacy-System hinzugefügt wird, muss entweder auch im neuen System umgesetzt oder später abgeglichen werden. Ein vollständiger Freeze ist selten realistisch. Ein Governed Exception Process mit transparenten Kosten für jede Legacy-Änderung dagegen schon. Je kürzer das Dual-Run-Fenster, desto leichter lässt sich diese Disziplin aufrechterhalten.
  • Planen Sie Menschen neu ein – nicht nur Systeme. Das Team, das die Legacy-Plattform betreibt, braucht eine klare Zukunftsperspektive: Umschulung auf den neuen Tech-Stack, Einbindung in die Migration oder eine kontrollierte Transition-Phase. Bleibt diese Perspektive offen, entsteht für diejenigen, die das Legacy-System am besten kennen, kaum ein Anreiz, seine Ablösung aktiv voranzutreiben. Wird das Thema früh geklärt, werden genau diese Personen zu den wertvollsten Experten innerhalb der Migration.

AI verändert auch das Staffing Model. Wenn der mechanische Teil der Arbeit maschinell beschleunigt wird, kann die begrenzte Kapazität der Senior Engineers dort eingesetzt werden, wo sie den grössten Wert liefert: Architektur, Reviews, Risk Decisions und andere Formen professioneller Beurteilung. Das nutzt ihre Fähigkeiten besser und verkürzt gleichzeitig den Critical Path des Programms.

Dann muss auch das Zeitfenster selbst gemessen werden. Der KPI, der eine AI-beschleunigte Modernisierung auf Kurs hält, ist einfach: Time in Dual Run pro Domäne. Keine Story Points, keine Model Usage. Entscheidend sind die Monate im Dual Run – und dass diese Zahl kontinuierlich sinkt.

Was im Budgetgespräch zählt

Präsentieren Sie die J-Kurve, nicht die Fantasiekurve. Ihr CFO hat die Fantasiekurve bereits gesehen – und glaubt ihr nicht mehr.

Das Argument, das einer genaueren Prüfung standhält, ist ein anderes: Die Investition finanziert die moderne Plattform, aber die Beschleunigung holt die teuersten Monate des Programms zurück. Eine Modernisierung, die den Break-even im 14. statt im 26. Monat erreicht, spart nicht nur ein Jahr Dual-Run-Kosten. Sie verbringt auch ein Jahr weniger damit, Drift, Reconciliation Debt und organisatorische Erschöpfung aufzubauen – und beginnt ein Jahr früher, vom Run-Rate-Vorteil von 30–40 % zu profitieren.

Zwei Systeme parallel zu betreiben ist der Preis für eine sichere Modernisierung. Wie lange Sie diesen Preis zahlen, ist eine Entscheidung.

MIT IHREN EIGENEN ZAHLEN RECHNEN

Modellieren Sie Ihre eigene J-Kurve.

Unser Business-Case-Planer modelliert Dual-Run-Kosten, Break-even und den Einfluss AI-beschleunigter Delivery auf das Zeitfenster – mit transparenten, nachvollziehbaren und individuell anpassbaren Annahmen.

Business-Case-Planer öffnen
WEITERLESEN

AI-Ambitionen, Legacy-Realität: Was „nicht modernisieren“ tatsächlich bedeutet

Lesen →
WEITERLESEN

Ist AI-generierter Code in einer Bank erlaubt? Eine Antwort aus Sicht der Rückverfolgbarkeit.

Lesen →

Möchten Sie diese Fragen für Ihr System gemeinsam durchgehen?

Ein 30-minütiger Discovery Call.

Discovery Call vereinbaren