Das System, an das sich keiner herantraut, Fähigkeit für Fähigkeit erneuern.
Ob Bank, Versicherer oder staatliche Verwaltung: Viele Häuser in Luxemburg verlassen sich auf Programme in COBOL, PL/I, Oracle Forms oder frühem Java und .NET, in denen das Fachwissen von Jahrzehnten steckt. Wir machen dieses Wissen sichtbar, sichern es durch Tests und holen Funktion um Funktion hinter eine Fassade. Alter Code geht erst vom Netz, wenn der Vergleich im Parallellauf stimmt.
Für Organisationen in Luxemburg mit kritischen Systemen, die oft Kunden und Gesellschaften in mehreren Ländern bedienen und bei denen weder Ausfälle noch verlorene Regeln in Frage kommen.
Am Anfang stehen eine Bestandsaufnahme und ein vereinbartes Zielbild. Mit KI-Unterstützung werden Regeln aus dem Programmcode herausgearbeitet, Fachleute bestätigen jede einzelne. Tests, die das heutige Verhalten festhalten, sichern alles Weitere ab. Danach entsteht eine Funktion nach der anderen neu, abgeschirmt durch eine Fassade und im Parallellauf mit dem Altsystem. Erst wenn alle Differenzen geklärt sind und die fachliche Leitung zustimmt, wird umgeschaltet und das alte Stück abgebaut.
Vorher und nachher
Was sich an Ihrer Arbeitsweise ändert
Heute
Mit dem System
Heute
Heute: Jede Änderung ein Wagnis
Ein neues Rundschreiben, eine kleine Gesetzesänderung, und schon vergehen Monate, weil keiner weiß, welche Nebenwirkungen drohen.
Mit dem System
Mit dem System: Änderungen mit Testschutz
Tests dokumentieren das heutige Verhalten. Was eine Anpassung bewirkt, sieht man vor dem Release, nicht danach.
Heute
Heute: Das Wissen geht in Rente
Die letzten Kenner des Codes verabschieden sich bald, und die Unterlagen beschreiben längst ein anderes System.
Mit dem System
Mit dem System: Regeln aufgeschrieben und bestätigt
Aus dem Code gewonnene Geschäftsregeln stehen in verständlicher Sprache da, bestätigt von den Fachleuten.
Heute
Heute: Großprojekte kommen nicht an
Komplettablösungen versprechen einen einzigen Umstellungstermin, der sich immer weiter verschiebt, während die Kosten steigen.
Mit dem System
Mit dem System: Nutzen in Etappen
Funktionen ziehen einzeln hinter eine Fassade um. Jede Etappe geht für sich live und lässt sich zurückdrehen.
Heute
Heute: Daten in alten Strukturen gefangen
Neue Dienste und KI-Anwendungen kommen nur über wacklige Exporte und nächtliche Stapelläufe an die Daten.
Mit dem System
Mit dem System: Daten über Schnittstellen
Migrierte Bereiche liefern ihre Daten über beschriebene Schnittstellen und werden bis zur Abschaltung des Altsystems laufend mit ihm verglichen.
Workflow
So läuft der Ablauf
Das Prinzip heißt Strangler Fig: Der Nachfolger umschließt das Altsystem nach und nach. Der Großteil der Arbeit passiert im Kreislauf aus Parallellauf, Klärung und Nachbesserung.
Beispielhafter Ablauf
7 Schritte · 3 menschliche Prüfungen
Legende
System
Agent
Person
Menschliche Prüfung
Ausnahmepfad
Altsystemmodernisierung: Beispielablauf mit Abgleichsschleife
Diagramm als Text lesen
Regelweg: Bestandsaufnahme, Regeln aus dem Code herausarbeiten, Verhalten durch Tests festhalten, eine Funktion hinter der Fassade neu bauen, beide Fassungen parallel rechnen lassen, umschalten und den Altteil abbauen.
An drei Stellen entscheiden Menschen: beim Zielbild, bei jeder herausgearbeiteten Regel und bei jeder Umschaltung.
Rechnen beide Fassungen unterschiedlich, geht der Abschnitt in die Klärung durch Entwicklung und Fachseite und danach zurück in den Neubau. Das wiederholt sich, bis die Ergebnisse deckungsgleich sind.
01
Schritt 1: Anwendungslandschaft bewertenPerson
Bestandsaufnahme der Anwendungen, Abhängigkeiten und Datenflüsse und eine Entscheidung je Anwendung: stilllegen, behalten, umziehen, auf neue Plattform heben, neu bauen oder ersetzen. Die Fachdomänen zeigen, wo sich das System sinnvoll in Etappen schneiden lässt.
Menschliche Prüfung
Ihr Architekturgremium gibt Zielarchitektur und Reihenfolge der Etappen frei.
02
Schritt 2: Geschäftsregeln zurückgewinnenAgent
Ein KI-Werkzeug arbeitet sich durch COBOL, PL/I, JCL, Oracle Forms sowie ältere Java- und .NET-Bestände und liefert erste Fassungen von Beschreibung, Aufrufbeziehungen und Regelverzeichnis.
Menschliche Prüfung
Entwicklerinnen, Entwickler und Fachleute prüfen jede gewonnene Regel, bevor sie als Vorgabe dient. Was nicht bestätigt ist, bleibt als unbestätigt gekennzeichnet.
03
Schritt 3: Sicherheitsnetz knüpfenSystem
Anonymisierte Eingaben und Ergebnisse aus dem Echtbetrieb werden zu Charakterisierungstests. Sie halten fest, wie das System heute rechnet, einschließlich seiner Macken, noch bevor eine Zeile geändert wird.
04
Schritt 4: Eine Etappe hinter der Fassade neu bauenSystem
Vor das Altsystem kommt eine Routing-Fassade oder API-Schicht. Eine Funktion entsteht als neuer Dienst, ihre Daten werden migriert und synchron gehalten.
05
Schritt 5: Parallel betreiben und abgleichenSystem
Beide Systeme bekommen identische Buchungen. Ein automatischer Vergleich prüft Resultate und Datenstände und listet Differenzen nach Regel und Datensatz auf.
06
Schritt 6: Abweichungen einordnenPerson
Entwicklung und Fachleute entscheiden bei jeder Differenz: Fehler im neuen Dienst, Fehler im alten oder gewollte Änderung. Danach geht die Etappe zur Nacharbeit zurück.
Ausnahmepfad: Ergebnisse weichen ab· Zurück zu Schritt 4
07
Schritt 7: Umstellen und stilllegenPerson
Ab dem Stichtag schickt die Fassade alle Aufrufe dieser Funktion zum Nachfolger. Läuft er eine vereinbarte Zeit ohne Auffälligkeiten, wird der Altteil samt Datenbestand archiviert und abgeschaltet.
Menschliche Prüfung
Umgeschaltet wird nur mit Zustimmung der fachlichen Leitung, die sich auf die Vergleichsergebnisse stützt. Solange der Altteil existiert, kann die Fassade jederzeit zurückschalten.
Komponenten
Was wir bauen würden
01
Landkarte der Anwendungen und Abhängigkeiten
Übersicht über Anwendungen, Schnittstellen und Datenwege plus ein Fachmodell mit den Stellen, an denen sich Abschnitte sauber trennen lassen.
Salesforce als neues FrontofficePlattformSalesforce
Integrationsplattform und API-Gateway
Ziel-Cloud oder Rechenzentrum
Kontrollen
Eingebaute Kontrollen
Zugriffsgrenzen
Analysiert wird in einer Umgebung, die Sie kontrollieren, und Quelltext erreicht nur Dienste mit Ihrer ausdrücklichen Zustimmung. Echte Daten für Testzwecke verlassen die Produktion ausschließlich anonymisiert.
Menschliche Prüfung
Entwicklung und Fachleute bestätigen gewonnene Regeln, bevor daraus Vorgaben werden. Jede Umstellung genehmigt die fachlich verantwortliche Person auf Basis der Abgleichsergebnisse, und ein Weg zurück bleibt offen.
Nachvollziehbarkeit
Zu jedem Katalogeintrag sind Herkunft im Quelltext und Name der bestätigenden Person hinterlegt. Vergleichsberichte belegen jede Umschaltung und stehen der Innenrevision ebenso zur Verfügung wie einer Prüfung durch die Aufsicht, am Finanzplatz etwa durch CSSF oder CAA.
Datenschutz
Die Datenmigration folgt einer dokumentierten Zuordnung mit Datensatzzahlen und Prüfsummen; in Testdaten werden personenbezogene Angaben auf das Nötige reduziert. Aufbewahrungsregeln ziehen mit den Daten um.
KI-Transparenz
Von KI vorgeschlagene Texte oder Programmteile tragen eine Kennzeichnung, durchlaufen ein Review und liegen versioniert im Repository wie jede andere Entwicklungsarbeit.
Kennzahlen
Woran wir den Erfolg messen würden
Welche Werte wir verfolgen, steht nach der Bestandsaufnahme fest; berichtet wird pro Abschnitt und nicht bloß für das Programm insgesamt.
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 deutlichste Zeichen dafür, dass sich das System leichter ändern lässt.
Wie wir sie messen würdenZeit vom genehmigten Änderungsantrag bis zur Produktion, für alte und modernisierte Teile.
02Stand des Abgleichs
Warum sie zähltBelegt, dass der Nachfolger dort gleich rechnet, wo er gleich rechnen muss.
Wie wir sie messen würdenAnteil übereinstimmender Transaktionen und Datensätze im Parallelbetrieb, offene Differenzen nach Ursache.
03Abdeckung der Regeln
Warum sie zähltUnbekannte Regeln sind das größte Risiko jeder Ablösung.
Wie wir sie messen würdenAnteil der gewonnenen 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 wirklich abgeschaltet sind.
Wie wir sie messen würdenStillgelegte Funktionen, Codepfade, Stapeljobs und Lizenzen, erfasst je Etappe.
Ziele werden erst nach einer Ausgangsmessung festgelegt.
Einführung
So würden wir einführen
Phase 01
Bewertung
Anwendungslandschaft, Abhängigkeiten, Fachdomänen und Risiken. Wir wählen eine erste Etappe, die fachlich zählt, sich aber zurückdrehen lässt.
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, die parallel zum Altsystem läuft.
Abschlusskriterien
Abgleich innerhalb der vereinbarten Toleranz
Fachlich verantwortliche Person gibt die Umstellung frei
Rückweg getestet
Phase 03
Etappe für Etappe
Jeder weitere Abschnitt bekommt seinen eigenen Parallellauf und seine eigene Freigabe.
Abschlusskriterien
Jede Etappe abgeglichen und umgestellt
Wissen an Ihr Team übergeben
Phase 04
Stilllegung
Alte Codepfade, Stapeljobs und Datenbestände werden archiviert und abgeschaltet.
Selbst entwickelte Fachsoftware einer staatlichen Verwaltung, in der Gesetze und großherzogliche Verordnungen seit Jahrzehnten im Code stecken, während neue Änderungen nachkommen.
Eigenentwicklungen rund um das ERP und Werkssysteme, die zusammen mit einer Migration auf SAP S/4HANA umziehen.
Beispiel zur Veranschaulichung
Das Portfoliosystem einer Bank, Abschnitt für Abschnitt
Ausgangslage
Eine Bank in Luxemburg verwaltet Wertpapierdepots ihrer Kundschaft aus mehreren Ländern in einer Eigenentwicklung, die über Jahrzehnte gewachsen ist. Für mehrere Produktarten stehen Regeländerungen an, und zwei der wenigen Personen, die den Code noch kennen, gehen in den Ruhestand.
System
Die Regeln werden je Produktart zurückgewonnen und bestätigt. Eine Fassade leitet zuerst die Berechnungen einer Produktart an einen neuen Dienst, der parallel zum Altsystem läuft, bis die Ergebnisse übereinstimmen.
Menschliche Kontrolle
Fachleute aus dem Produktmanagement bestätigen die Regeln ihrer Produktart. Die fachlich verantwortliche Person gibt jede Umstellung frei; der Weg zurück über die Fassade bleibt offen, und Ausstiegsplan und Informationsregister nach DORA werden laufend aktualisiert.
Was wir messen würden
Stand des Abgleichs je Produktart, Abdeckung der Regeln und Durchlaufzeit für die nächste regulatorische Änderung.
Luxemburg
Modernisieren unter Luxemburger und EU-Regeln
Am Finanzplatz Luxemburg bedient ein Kernsystem oft Kundinnen, Kunden und Gesellschaften in mehreren Ländern, und für jedes stehen eigene regulatorische Änderungen an. Wir planen die Modernisierung so, dass Länder- und Produktvarianten einzeln umziehen und alt und neu für jede Variante abgeglichen sind, bevor etwas abgeschaltet wird.
Für Banken, Fondsverwalter und Versicherer gilt seit dem 17. Januar 2025 die DORA, beaufsichtigt von CSSF und CAA; Ausstiegspläne und ein sauber dokumentiertes Informationsregister gehören deshalb von der ersten Etappe an dazu. Für Einrichtungen in den von NIS2 erfassten Sektoren gilt das Gesetz vom 5. Mai 2026 (loi du 5 mai 2026), für die meisten dieser Sektoren mit dem Institut Luxembourgeois de Régulation (ILR) als zuständiger Stelle; die neuen Dienste laufen auf Plattformen, die diese Sicherheitspflichten berücksichtigen. Die Wechselregeln des Data Act sprechen dafür, Daten von Anfang an übertragbar zu halten, und wo Datensätze personenbezogene Daten enthalten, folgen Migrationszuordnung und Testdaten der DSGVO.
01Warum nicht das ganze System auf einmal ersetzen?
Ein Komplettwechsel legt das ganze Risiko auf einen Tag, und bis dahin hat das Haus jahrelang nichts davon. Schrittweise bewährt sich jeder Abschnitt zuerst im Parallellauf, startet für sich und kann notfalls zurückgenommen werden.
02Kann KI unser COBOL in Java übersetzen?
Maschinell eins zu eins übertragenes COBOL ist hinterher meist ebenso schwer zu pflegen wie vorher, nur in einer anderen Sprache. KI setzen wir deshalb zum Verstehen ein: Sie liest und beschreibt den Bestand und schlägt Regeln und Testfälle vor. Die Architektur der Nachfolger gestalten Menschen, und keine Regel geht ungeprüft in die Spezifikation.
03Unsere Fachleute gehen bald in Rente. Wie sichern Sie ihr Wissen?
Wir setzen uns mit ihnen in festen Terminen über das Regelverzeichnis und die Testfälle. Was sie wissen, steht danach in Unterlagen und automatischen Tests, die Ihrem Team gehören, und hängt nicht an unseren Leuten.
04Gilt das auch für SAP ECC?
Ja. Wer Eigenentwicklungen aufräumt und auf SAP S/4HANA wechselt, profitiert von denselben Prinzipien: ungenutzten Code erkennen, Wesentliches dokumentieren und testen, dann in überschaubaren Schritten migrieren. Das gilt auch für Gruppen mit Gesellschaften in Luxemburg und Deutschland auf einem gemeinsamen System.
05Wie lange laufen alt und neu nebeneinander?
So lange, bis die Differenzen unter der mit der fachlichen Leitung vereinbarten Grenze liegen, und in jedem Fall über wiederkehrende Termine wie Monatsende oder Jahresabschluss hinweg. Bei Fonds und Banken gehören dazu auch Stichtage für das Reporting.
Beschreiben Sie das System, das Sie aufhält, und alles, was daran hängt. Sie erhalten einen Vorschlag für den ersten Abschnitt und dafür, wie er sich gefahrlos nachweisen lässt, gleich für wie viele Länder das System rechnet.