Das System, an das sich keiner herantraut, Schritt für Schritt erneuern.
In COBOL, PL/I, Oracle Forms und frühem Java oder .NET stecken Geschäftsregeln aus Jahrzehnten. Wir holen diese Regeln ans Licht, spannen ein Netz aus Tests auf und verlagern eine Funktion nach der anderen hinter eine Fassade. Abgeschaltet wird erst, wenn Parallelbetrieb und Abgleich stimmen.
Für Organisationen in Österreich, deren kritische Systeme auch Gesellschaften in Nachbarländern bedienen und bei denen weder Ausfall noch verlorene Regeln in Frage kommen.
Zuerst wird die Anwendungslandschaft bewertet und das Ziel vereinbart. KI hilft, Geschäftsregeln aus dem Code zu lesen, Menschen bestätigen sie. Charakterisierungstests bilden das Sicherheitsnetz. Jede Funktion entsteht hinter einer Fassade neu und läuft parallel zum Altsystem; Abweichungen werden geklärt und behoben, bevor die fachlich verantwortliche Stelle die Umstellung genehmigt und der alte Teil stillgelegt wird.
Vorher und nachher
Was sich an Ihrer Arbeitsweise ändert
Heute
Mit dem System
Heute
Heute: Jede Änderung ist ein Wagnis
Schon kleine gesetzliche Anpassungen dauern Monate, weil niemand absehen kann, was eine Änderung sonst noch auslöst.
Mit dem System
Mit dem System: Tests sichern jede Änderung ab
Charakterisierungstests halten fest, was das System heute tut. So zeigt jede Änderung ihre Wirkung, bevor sie in Betrieb geht.
Heute
Heute: Das Wissen geht in Pension
Wer den Code noch versteht, steht kurz vor dem Ruhestand, und die Dokumentation passt schon lange nicht mehr zum System.
Mit dem System
Mit dem System: Regeln schriftlich und bestätigt
Was an Geschäftsregeln aus dem Code gewonnen wird, steht in verständlicher Sprache da und ist von Fachleuten bestätigt.
Heute
Heute: Großprojekte kommen nicht vom Fleck
Programme für die Komplettablöse versprechen einen Stichtag für die Umstellung, der sich laufend verschiebt, während die Kosten steigen.
Mit dem System
Mit dem System: Nutzen in Etappen
Eine Funktion nach der anderen wandert hinter die Fassade. Jede Etappe geht für sich in Betrieb und lässt sich zurücknehmen.
Heute
Heute: Daten in alten Strukturen gefangen
Neue Services und KI-Anwendungen kommen an die Daten nur über wackelige Exporte und nächtliche Batchläufe heran.
Mit dem System
Mit dem System: Daten über Schnittstellen erreichbar
Bereits migrierte Fachbereiche stellen ihre Daten über dokumentierte APIs bereit und werden mit dem Altsystem abgeglichen, bis dieses abgeschaltet ist.
Workflow
Der Ablauf im Einzelnen
Wir arbeiten nach dem Strangler-Fig-Muster: Das neue System wächst Funktion für Funktion um das alte herum. Die meiste echte Arbeit steckt in der Schleife zwischen Parallelbetrieb und Neubau.
Beispielhafter Ablauf
7 Schritte · 3 menschliche Prüfungen
Legende
System
Agent
Person
Menschliche Prüfung
Ausnahmepfad
Altsysteme ablösen: illustrativer Ablauf mit Abgleichsschleife
Diagramm als Text lesen
Der Hauptpfad reicht von der Bewertung der Anwendungslandschaft und der Rückgewinnung der Geschäftsregeln über den Aufbau eines Sicherheitsnetzes aus Charakterisierungstests und den Neubau einer Funktion hinter der Fassade bis zum Parallelbetrieb von Alt und Neu und schließlich zur Umstellung und Stilllegung des alten Teils.
Menschen geben die Zielarchitektur frei, bestätigen jede zurückgewonnene Regel und genehmigen jede Umstellung. Das sind die menschlichen Kontrollpunkte.
Weichen die Ergebnisse im Parallelbetrieb voneinander ab, verlässt die Etappe den Hauptpfad. Entwicklung und Fachseite klären die Abweichung, und die Etappe kehrt zum Neubau zurück, bis Alt und Neu übereinstimmen.
01
Schritt 1: Anwendungslandschaft bewertenPerson
Bestandsaufnahme der Anwendungen, Abbildung von Abhängigkeiten und Datenflüssen und je Anwendung eine Entscheidung: stilllegen, behalten, umziehen, auf neue Plattform heben, neu bauen oder ersetzen. Die Fachbereiche werden so abgegrenzt, dass sichtbar wird, wo sich das System in Etappen zerlegen lässt.
Menschliche Prüfung
Zielarchitektur und Reihenfolge der Etappen gibt Ihr Architekturgremium frei.
02
Schritt 2: Geschäftsregeln zurückgewinnenAgent
Eine KI-gestützte Codeanalyse liest COBOL, PL/I, JCL, Oracle Forms und älteres Java oder .NET und erstellt Entwürfe für Dokumentation, Aufrufgraphen und einen Katalog der Geschäftsregeln.
Menschliche Prüfung
Bevor eine Regel als Vorgabe dient, prüfen Entwicklerinnen, Entwickler und Fachleute sie einzeln. Nicht bestätigte Regeln bleiben als solche gekennzeichnet.
03
Schritt 3: Sicherheitsnetz aufbauenSystem
Aus anonymisierten Ein- und Ausgaben des Echtbetriebs entstehen Charakterisierungstests. Das heutige Verhalten samt seinen Eigenheiten ist damit festgehalten, bevor sich irgendetwas ändert.
04
Schritt 4: Eine Etappe hinter der Fassade neu bauenSystem
Vor das Altsystem kommt eine Fassade oder API-Schicht, die Anfragen verteilt. Eine Funktion entsteht als neuer Service; ihre Daten werden migriert und synchron gehalten.
05
Schritt 5: Parallel betreiben und abgleichenSystem
Alt und Neu verarbeiten dieselben Transaktionen. Ergebnisse und Daten werden automatisch verglichen, jede Abweichung wird je Regel und je Datensatz ausgewiesen.
06
Schritt 6: Abweichungen klärenPerson
Entwicklung und Fachseite entscheiden bei jeder Abweichung, ob ein Fehler im neuen Service, ein Fehler im alten System oder eine gewollte Änderung vorliegt, und schicken die Etappe zur Nacharbeit zurück.
Ausnahmepfad: Ergebnisse weichen ab· Zurück zu Schritt 4
07
Schritt 7: Umstellen und stilllegenPerson
Die Fassade leitet die Anfragen für diese Funktion an den neuen Service. Nach einer stabilen Phase werden der alte Codepfad und seine Daten archiviert und stillgelegt.
Menschliche Prüfung
Jede Umstellung genehmigt die fachlich verantwortliche Stelle anhand der Abgleichsergebnisse. Bis zur Stilllegung bleibt der Weg zurück über die Fassade offen.
Komponenten
Was wir bauen würden
01
Landkarte der Anwendungen und Abhängigkeiten
Bestandsaufnahme, Abbildung von Schnittstellen und Datenflüssen und ein fachliches Modell, das zeigt, wo sich das System in Etappen schneiden lässt.
Salesforce als neues FrontofficePlattformSalesforce
Integrationsplattform und API-Gateway
Ziel-Cloud oder Rechenzentrum
Kontrollen
Eingebaute Kontrollen
Zugriffsgrenzen
Die Codeanalyse läuft in einer Umgebung, die Sie kontrollieren; Quellcode geht an keinen Dienst, den Sie nicht freigegeben haben. Produktionsdaten für Tests werden anonymisiert, bevor sie die Produktionszone verlassen.
Menschliche Prüfung
Zurückgewonnene Regeln bestätigen Entwicklung und Fachseite, bevor sie zur Vorgabe werden. Jede Umstellung genehmigt die fachlich verantwortliche Stelle auf Grundlage der Abgleichsergebnisse, mit offenem Rückweg.
Nachvollziehbarkeit
Jede Regel im Katalog lässt sich auf den Code zurückführen, aus dem sie stammt, und auf die Person, die sie bestätigt hat. Die Abgleichsberichte bleiben als Nachweis für jede Umstellung erhalten.
Datenschutz
Die Datenmigration folgt einer dokumentierten Zuordnung mit Satzzählungen und Prüfsummen; in Testdaten werden personenbezogene Daten auf das Nötige reduziert. Aufbewahrungsregeln wandern mit den Daten mit.
KI-Transparenz
Wo KI Dokumentation oder Code entwirft, wird das Ergebnis gekennzeichnet, geprüft und versioniert wie jedes andere technische Arbeitsergebnis.
Kennzahlen
Woran wir den Erfolg messen würden
Die Messgrößen vereinbaren wir bei der Bewertung mit Ihnen und verfolgen sie je Etappe, nicht nur für das Gesamtprogramm.
Woran wir den Erfolg messen würden
Kennzahl
Warum sie zählt
Wie wir sie messen würden
01Durchlaufzeit für Änderungen
Warum sie zähltDas klarste Zeichen dafür, dass sich das System leichter ändern lässt.
Wie wir sie messen würdenZeit vom genehmigten Änderungsantrag bis zum Echtbetrieb, getrennt für alte und modernisierte Teile.
02Stand des Abgleichs
Warum sie zähltZeigt, ob sich der neue Service dort wie der alte verhält, wo er das soll.
Wie wir sie messen würdenAnteil übereinstimmender Transaktionen und Datensätze im Parallelbetrieb, offene Abweichungen nach Ursache.
03Abdeckung der Regeln
Warum sie zähltUnbekannte Regeln sind bei jeder Ablöse das größte Risiko.
Wie wir sie messen würdenAnteil der zurückgewonnenen Geschäftsregeln, die Fachleute bestätigt haben und die durch Tests abgedeckt sind.
04Verbleibender Altbestand
Warum sie zähltModernisierung rechnet sich erst, wenn alte Komponenten tatsächlich abgeschaltet sind.
Wie wir sie messen würdenStillgelegte Funktionen, Codepfade, Batchjobs und Lizenzen, erfasst je Etappe.
Ziele werden erst nach einer Ausgangsmessung festgelegt.
Einführung
Wie wir es einführen würden
Phase 01
Bewertung
Anwendungslandschaft, Abhängigkeiten, Fachbereiche und Risiken. Als erste Etappe wählen wir etwas, das für das Geschäft zählt, aber zurückgenommen werden kann.
Abschlusskriterien
Zielarchitektur freigegeben
Reihenfolge der Etappen vereinbart
Zugang zu Tests und Daten geregelt
Phase 02
Erste Etappe
Regeln zurückgewinnen, Sicherheitsnetz, Fassade und eine neu gebaute Funktion im Parallelbetrieb mit dem Altsystem.
Abschlusskriterien
Abgleich innerhalb der vereinbarten Toleranz
Fachlich verantwortliche Stelle genehmigt die Umstellung
Rückweg getestet
Phase 03
Etappe für Etappe
Weitere Funktionen gehen denselben Weg, jede mit eigenem Parallelbetrieb und eigener Entscheidung über die Umstellung.
Abschlusskriterien
Jede Etappe abgeglichen und umgestellt
Wissen an Ihr Team übergeben
Phase 04
Stilllegung
Alte Codepfade, Batchjobs und Datenbestände werden archiviert und abgeschaltet.
Selbst entwickelte ERP-Erweiterungen und Werkssysteme eines Familienunternehmens, die parallel zum Umstieg auf SAP S/4HANA übersiedeln.
Beispiel zur Veranschaulichung
Polizzensystem einer Versicherung für drei Länder
Ausgangslage
Eine Versicherung berechnet Prämien für Österreich und zwei Tochtergesellschaften in Mittel- und Osteuropa auf einem gemeinsamen Hostsystem. In jedem Land warten Gesetzesänderungen, und zwei der Entwickler, die den Code kennen, gehen bald in Pension.
System
Die Regeln werden je Land zurückgewonnen und bestätigt. Eine Fassade leitet zuerst die Berechnungen eines Landes an einen neuen Service, der parallel zum Host läuft, bis die Ergebnisse übereinstimmen.
Menschliche Kontrolle
Fachleute in jedem Land bestätigen ihre Regeln. Die Umstellung genehmigt die fachlich verantwortliche Stelle des jeweiligen Landes; der Rückweg über die Fassade bleibt offen.
Was wir messen würden
Stand des Abgleichs je Land, Abdeckung der Regeln und Durchlaufzeit für die nächste Gesetzesänderung.
Österreich
Modernisieren nach österreichischen und EU-Vorgaben
Österreichische Versicherungen, Banken und Industriegruppen betreiben oft einen gemeinsamen Altkern für Österreich und mehrere Länder in Mittel- und Osteuropa, und jedes Land hat seine eigenen Gesetzesänderungen in der Warteschlange. Wir planen die Ablöse so, dass nationale Varianten Etappe für Etappe umziehen und Alt und Neu je Land abgeglichen sind, bevor etwas abgeschaltet wird.
Die neuen Services landen auf Plattformen, die auf die Sicherheitspflichten des NISG 2026 ausgelegt sind; seit 1. Oktober 2026 ist dafür das Bundesamt für Cybersicherheit (BCS) zuständig. Banken und Versicherungen planen zusätzlich nach DORA, unter Aufsicht der FMA. Die Wechselregeln des Data Act sprechen dafür, Daten ab der ersten Etappe übertragbar zu halten, und wo Datensätze personenbezogene Daten enthalten, folgen Migration und Testdaten der DSGVO.
01Warum nicht gleich das ganze System auf einmal ersetzen?
Eine Umstellung an einem einzigen Stichtag bündelt das gesamte Risiko auf diesen Tag, und bis dahin wartet das Geschäft jahrelang auf jeden Nutzen. Gehen Funktionen einzeln, muss sich jede Etappe im Parallelbetrieb bewähren, kann für sich in Betrieb gehen und bei Bedarf zurückgenommen werden.
02Kann KI unser COBOL nach Java übersetzen?
Eine Übersetzung Zeile für Zeile liefert meist Code, der sich genauso schwer ändern lässt wie das Original. Wir setzen KI ein, um alten Code zu lesen und zu dokumentieren und um Regeln und Tests zu entwerfen. Die neuen Services entwerfen wir dann ordentlich. Jede zurückgewonnene Regel bestätigt ein Mensch, bevor sie verwendet wird.
03Unsere Fachleute gehen bald in Pension. Wie sichern Sie ihr Wissen?
In strukturierten Terminen, bei denen diese Fachleute die zurückgewonnenen Regeln und die Charakterisierungstests durchgehen. Ihr Wissen landet in Dokumentation und Tests, die bei Ihrem Team bleiben, nicht in unseren Köpfen.
04Gilt das auch für SAP ECC?
Ja. Für die Bereinigung von Eigenentwicklungen und den Umstieg auf SAP S/4HANA gelten dieselben Grundsätze: feststellen, was noch genutzt wird, das Wichtige zurückgewinnen und testen und in kontrollierten Schritten umziehen.
05Wie lange laufen Alt und Neu nebeneinander?
So lange, bis die Abgleichsergebnisse die mit der fachlich verantwortlichen Stelle vereinbarte Toleranz einhalten, und mindestens so lange, dass periodische Läufe wie Monatsabschluss oder Jahresverarbeitung abgedeckt sind.
Sagen Sie uns, welches System Sie bremst und was alles daran hängt. Wir schlagen eine erste Etappe vor und zeigen, wie sie sich sicher nachweisen lässt, für Österreich und jedes weitere Land, das sie bedient.