Alles, was Führungskräfte aus Engineering und Transformation im Jahr 2026 wissen müssen – von der Wahl des richtigen Ansatzes über den Einsatz von AI und menschliche Kontrollinstanzen bis hin zur revisionssicheren Rückverfolgbarkeit. Entwickelt von den Architekten des Modernization Frameworks.
Fragt man einen Finanzvorstand, wofür das IT-Budget ausgegeben wird, lautet die Antwort meist „die Zukunft“. Schaut man sich jedoch die tatsächliche Buchhaltung an, ist die Antwort die Vergangenheit: Unternehmen mit hohem Altlastenanteil geben routinemässig 60–80 % ihres IT-Budgets allein dafür aus, bestehende Systeme am Laufen zu halten. Mit diesem Geld wird nichts Neues geschaffen. Es dient lediglich dazu, die Folgen von Entscheidungen zu bezahlen, die vor fünfzehn Jahren getroffen wurden.
Diese Falle hat einen Mechanismus, der sich immer weiter verstärkt. Die Aufrechterhaltung veralteter Plattformen wird von Jahr zu Jahr teurer – höhere Supportkosten der Anbieter, Mangel an Fachkräften, Hardware-Wartung, deren Kosten nach Ablauf der Garantien jährlich um 10–15 % steigen. Gleichzeitig wird jede neue Vorschrift als Änderungsanforderung an ein System gestellt, das sich gegen Veränderungen sträubt, sodass Compliance-Massnahmen die Produktentwicklung verdrängen. In einer regulierten Branche ist dies nicht nur ein Kostenproblem; es führt zu zunehmenden Prüfungs- und Sicherheitsrisiken, die mit einem entsprechenden Budgetposten verbunden sind.
Der dritte Treiber ist unauffälliger und oft entscheidend: die Ingenieure. Die Menschen, die in der Lage sind, Ihre Systemlandschaft zu modernisieren, wollen ihre Karriere nicht damit verbringen, sie zu „betreuen“ – und in einem Markt, in dem um erfahrene Fachkräfte konkurriert wird, ist „Komm und pflege unseren Stack aus dem Jahr 2009“ eine Stellenanzeige für Ihre Konkurrenten. Die Wartungsfalle ist daher dreifach: Sie verschlingt das Budget, sie erhöht das Risiko und sie schreckt genau die Menschen ab, die ihr ein Ende setzen könnten.
Die zitierfähige Version für Ihre nächste Lenkungsausschusssitzung: „Die grössten Kosten eines Altsystems entstehen nicht durch dessen Betrieb, sondern durch alles, was es Sie daran hindert, Neues aufzubauen.“
Zukünftige Artikel zu diesem Unterthema werden hier verlinkt
Jede Modernisierung beginnt mit derselben Entscheidung: Entweder wird das System in einem koordinierten Umstellungsschritt ersetzt (Big-Bang-Neuprogrammierung) oder Stück für Stück migriert, während es weiterläuft (das „Strangler-Fig“-Muster). Die ehrliche Antwort lautet: Ein „Big-Bang“ ist gelegentlich die richtige Wahl – für kleine, gut durchschaubare Systeme mit toleranten Ausfallfenstern und stabilen Anforderungen. Das trifft auf so gut wie kein reguliertes Unternehmen zu.
In allen anderen Fällen hat das Strangler-Modell in der einzigen Dimension die Nase vorn, die für einen Vorstand zählt: die Risikostruktur. Bei einer Neuprogrammierung konzentrieren sich alle Risiken auf einen einzigen Go-Live-Termin – den Tag, an dem jahrelange Annahmen auf einmal auf den Produktionsverkehr treffen. Die Strangler-Migration verteilt dieses Risiko auf viele kleine, reversible Umstellungen: Man unterteilt die Systemlandschaft in Domänen, leitet jeweils eine Domäne zum neuen System um, testet sie unter realer Auslastung und schaltet dann den alten Pfad ab. Wenn ein Schritt fehlschlägt, rollt man eine Domäne zurück, nicht das gesamte Unternehmen.
Der Kompromiss, ganz klar gesagt: Der Strangler-Ansatz erfordert mehr technische Disziplin. Man benötigt klare Domänengrenzen, eine Integrationsschicht, die nach Domänen leiten kann, und die Geduld, zwei Systeme parallel zu betreiben (Kapitel 6 beziffert genau das). Modulare, ereignisgesteuerte Zielarchitekturen machen die Aufteilung überschaubar – die nachfolgende ausführliche Betrachtung behandelt die Muster. Aber Disziplin ist ein Kostenfaktor, den Sie kontrollieren können. Ein gescheiterter „Big Bang“ hingegen nicht.
Die Berechnung aus Kapitel 6 als Vorlage – für Ihren Budgetantrag.
Business Case öffnenZukünftige Artikel zu diesem Unterthema werden hier verlinkt
Mechanik statt Magie. AI unterstützt die Modernisierung an vier konkreten Stellen, und genau zu wissen, wo diese liegen, unterscheidet ein glaubwürdiges Programm von einem, das nur aus Folien besteht.
Die Analyse ist der eindrucksvollste Bereich: Die LLM-gestützte Codebasis-Analyse erfasst ein System mit über 7.000 Dateien in etwa zwei Stunden und erstellt einen strukturierten Bericht – Architektur, Abhängigkeiten, toter Code, Risikohotspots –, für den zuvor Wochen an „archäologischer“ Arbeit durch erfahrene Entwickler erforderlich waren. Dies verändert die Wirtschaftlichkeit der Entscheidung selbst: Man kann es sich leisten, ein System zu verstehen, bevor man Budget dafür bereitstellt. Refactoring ist der Bereich, in dem AI den Umfang der mechanischen Umgestaltungen – Framework-Migrationen, API-Extraktion aus monolithischen Modulen, Abhängigkeits-Upgrades – in einem Tempo generiert, das kein menschliches Team erreichen kann. Testgenerierung geht das klassische Zeitfresser-Problem an: Charakterisierungstests, die festhalten, was das Altsystem tatsächlich tut, bevor man es ändert. Dokumentation fällt aus dem Prozess heraus, anstatt auf unbestimmte Zeit aufgeschoben zu werden.
Und die ehrliche Seite: Was AI nicht zuverlässig leisten kann. Sie kennt Ihre geschäftlichen Absichten nicht – sie sieht, was der Code tut, nicht, was er eigentlich tun sollte, und Altsysteme sind Archive undokumentierter Ausnahmen, die von Bedeutung sind. Sie kann keine Risikoentscheidung treffen. Und ohne Überprüfung erzeugt sie selbstbewusst plausibel wirkende Änderungen, die auf subtile Weise falsch sind. Deshalb läuft jeder der oben genannten Mechanismen hinter menschlichen Kontrollinstanzen ab – das Thema des nächsten Kapitels.
Zukünftige Artikel zu diesem Unterthema werden hier verlinkt
Mechanik statt Magie. AI unterstützt die Modernisierung an vier konkreten Stellen, und genau zu wissen, wo diese liegen, unterscheidet ein glaubwürdiges Programm von einem, das nur aus Folien besteht.
Die Analyse ist der eindrucksvollste Bereich: Die LLM-gestützte Codebasis-Analyse erfasst ein System mit über 7.000 Dateien in etwa zwei Stunden und erstellt einen strukturierten Bericht – Architektur, Abhängigkeiten, toter Code, Risikohotspots –, für den früher Wochen an „archäologischer“ Arbeit durch erfahrene Ingenieure erforderlich waren. Dies verändert die Wirtschaftlichkeit der Entscheidung selbst: Man kann es sich leisten, ein System zu verstehen, bevor man Budget dafür bereitstellt. Refactoring ist der Bereich, in dem AI den Umfang der mechanischen Transformation generiert – Framework-Migrationen, API-Extraktion aus monolithischen Modulen, Abhängigkeits-Upgrades – in einem Tempo, das kein menschliches Team erreichen kann. Testgenerierung geht das klassische Zeitfressproblem an: Charakterisierungstests, die festhalten, was das Altsystem tatsächlich tut, bevor man es ändert. Dokumentation ergibt sich aus dem Prozess, anstatt auf unbestimmte Zeit aufgeschoben zu werden.
Und die ehrliche Seite: Was AI nicht zuverlässig leisten kann. Sie kennt Ihre geschäftlichen Absichten nicht – sie sieht, was der Code tut, nicht, was er eigentlich tun sollte, und Altsysteme sind Archive undokumentierter Ausnahmen, die von Bedeutung sind. Sie kann keine Risikobewertung vornehmen. Und ohne Überprüfung erzeugt sie selbstbewusst plausibel wirkende Änderungen, die auf subtile Weise falsch sind. Deshalb läuft jeder der oben genannten Mechanismen hinter menschlichen Kontrollinstanzen ab – das Thema des nächsten Kapitels.
In einer beaufsichtigten Branche lautet die Frage niemals nur: „Funktioniert das neue System?“, sondern: „Können Sie nachweisen, wie es entstanden ist?“ Die FINMA-Leitlinie 08/2024 erwartet von Instituten, die AI einsetzen, dass sie Bestandsaufnahmen führen, Prozesse dokumentieren, die Erklärbarkeit sicherstellen und kritische Anwendungen einer unabhängigen Überprüfung unterziehen. Auf die Modernisierung übertragen bedeutet dies: Jede AI-gestützte Änderung benötigt einen Nachverfolgungspfad, dem ein Prüfer nachgehen kann.
Konkret verknüpft unsere Nachweiskette jede Änderung mit einem Commit-SHA: Welches Tool (und welche Version) hat die Änderung vorgeschlagen, welcher Entwickler hat sie geprüft und genehmigt, wann und gemäss welcher Gate-Richtlinie. Analyseberichte sind versionierte Artefakte. Der Modellzugriff erfolgt ausschliesslich im Retrieval-Modus – Client-Code wird weder vertraglich noch technisch zu Trainingszwecken verwendet. Die gesamte Nachverfolgungskette lässt sich als Paket exportieren, das Ihr Prüfer ohne unsere Anwesenheit auswerten kann. Compliance ist hier keine nachträgliche Ergänzung der Methode – sie ist ein integraler Bestandteil der Methode selbst. Teams, die auf diese Weise modernisieren, beantworten die AI-Frage der Aufsichtsbehörde an einem Nachmittag. Teams, die dies nicht tun, rekonstruieren die Historie ein ganzes Quartal lang.
Die Zahl, die in den meisten Business-Cases auf Folie neun versteckt wird, gehört eigentlich auf Folie eins: Während der Migration werden zwei Systeme parallel betrieben, und laut einer Studie von McKinsey belaufen sich die daraus resultierenden Mehrkosten während der Übergangsphase auf etwa 14 % pro Jahr – Gartner nennt dies die „Migrationsblase“. Die ehrliche Kostenkurve verläuft also J-förmig: zunächst steigt sie an (Investition plus Parallelbetrieb), fällt dann unter den Status quo und entwickelt sich anschliessend zu Ihren Gunsten. Wenn Sie eine glattere Kurve präsentieren, hört ein kompetenter Finanzvorstand auf zuzuhören.
Das Ziel rechtfertigt die J-Kurve: Benchmarks von McKinsey, Kyndryl und Accenture zeigen durchweg um 30–40 % niedrigere Infrastruktur- und Wartungskosten nach der Modernisierung, und das Budgetverhältnis kehrt sich um – von 60–80 % der IT-Ausgaben für den laufenden Betrieb auf etwa 20–30 %, wodurch der Grossteil des Budgets für den Aufbau frei wird. Daraus ergibt sich die strategische Schlussfolgerung, auf die dieser gesamte Leitfaden hinarbeitet: Der grösste Hebel in der Wirtschaftlichkeit der Modernisierung ist nicht die Höhe der Investition – es ist die Dauer des Parallelbetriebs. Genau das verkürzt die AI-beschleunigte Umsetzung: schnellere Analyse, schnellere Transformation, frühere Umstellungen einzelner Bereiche, ein schmaleres und flacheres „J“. Die Risiken, die es ehrlich zu benennen gilt: unterschätzte Datenmigration, zeitlich festgefrorene Scope Creeps auf der Legacy-Seite und organisatorische Ermüdung – allesamt Funktionen der Zeit, die alle durch denselben Hebel verkürzt werden. Berechnen Sie Ihre eigenen Zahlen mit dem Business-Case-Planer.
Domäne für Domäne: Erste Umstellungen innerhalb von Monaten, vollständige Modernisierung in ein bis drei Jahren, je nach Umfang und Kopplung. Die aussagekräftige Masseinheit ist nicht das Enddatum – es ist die Zeit im Parallelbetrieb pro Bereich, denn genau dort liegen die Kosten und das Risiko. AI-gestützte Analyse und Refactoring verkürzen genau dieses Zeitfenster.
In der Regel 60–80 % Ihres IT-Budgets, die in der Wartung gebunden sind und auf veralteten Plattformen jährlich um 10–15 % steigen – dazu kommen alle Initiativen, die das alte System stillschweigend blockiert, von AI-Funktionen bis hin zu schnelleren Compliance-Massnahmen. Der Status quo ist nicht kostenlos; er ist die teuerste Option mit der am wenigsten sichtbaren Rechnung.
Ja – sofern Sie Herkunft, Überprüfung und Genehmigung für jede Änderung nachweisen können. Die Schweizer Regulierung (FINMA-Leitfaden 08/2024) ist technologieneutral: Sie verbietet AI nicht, sondern fordert Governance und Nachweise. Kapitel 5 zeigt die Nachweiskette auf; der ausführliche Artikel „Ist AI-generierter Code in einer Bank zulässig?“ behandelt die bankspezifische Antwort.