CodeMigra
📅 März 2026  ·  Kategorie: COBOL Migration  ·  Lesezeit: ca. 7 Minuten

COBOL Migration Deutschland: Strategien zur Mainframe Ablösung (2026)

In Deutschland laufen noch heute Millionen geschäftskritischer Transaktionen täglich über COBOL-Programme — in Sparkassen, Volksbanken, bei der Deutschen Rentenversicherung und unzähligen Versicherungskonzernen. Was einst als stabil und verlässlich galt, wird zunehmend zum strategischen Risiko. Dieser Artikel erklärt, warum die COBOL Modernisierung für deutsche Finanzinstitute keine Option mehr ist, sondern eine Notwendigkeit.

Das stille Fachkräfteproblem: Wer pflegt die Systeme in zehn Jahren?

COBOL-Spezialisten in Deutschland: Die Zahlen

Das durchschnittliche Alter eines aktiven COBOL-Entwicklers in Deutschland liegt nach Schätzungen des Branchenverbands Bitkom zwischen 55 und 62 Jahren. Die Pensionierungswelle ist in vollem Gange. Gleichzeitig lernt kaum ein Absolvent heute noch COBOL — Universitäten haben es längst aus den Lehrplänen gestrichen.

Wissensverlust als operatives Risiko

Was bedeutet das konkret? Eine Sparkasse, die heute 30 COBOL-Entwickler beschäftigt, wird in fünf Jahren vielleicht noch fünf haben. Der institutionelle Wissenstransfer ist in vielen Häusern bereits jetzt brüchig: Dokumentation ist lückenhaft, Logik ist in undokumentierten Codepfaden versteckt, und neue Mitarbeiter lehnen COBOL-Stellen zunehmend ab — egal wie hoch das Gehalt.

Zahlen, die nachdenklich stimmen: IBM schätzt, dass weltweit noch 800 Milliarden Zeilen COBOL-Code in Produktion sind. Allein in Deutschland verarbeiten Kernbankensysteme täglich Transaktionen im Milliardenbereich über COBOL-Batch-Prozesse.

Die Volksbanken-Finanzgruppe, die Sparkassen-Finanzgruppe und große Einzelinstitute wie die DZ Bank stehen vor demselben strukturellen Problem: Die Systeme funktionieren — aber niemand mehr traut sich, sie anzufassen. Jede Änderung ist ein Minenfeld.

Regulatorischer Druck: BaFin und DORA lassen keinen Spielraum

BaFin-Anforderungen an IT-Betrieb und Legacy-Systeme

Die regulatorische Landschaft verschärft den Druck erheblich. Die BaFin (Bundesanstalt für Finanzdienstleistungsaufsicht) hat in ihrem IT-Rundschreiben sowie in den BAIT (Bankaufsichtliche Anforderungen an die IT) klare Anforderungen an Betriebsstabilität, Notfallmanagement und IT-Auslagerungen formuliert. Legacy-Mainframe-Systeme ohne aktuelle Sicherheitspatches, ohne angemessene Monitoring-Möglichkeiten und ohne Katastrophenschutz erfüllen diese Anforderungen oft nicht mehr vollständig.

DORA: Was Finanzinstitute ab 2025 umsetzen müssen

Noch folgenreicher ist der EU Digital Operational Resilience Act (DORA), der seit Januar 2025 in Kraft ist. DORA verlangt von Finanzinstituten detaillierte IKT-Risikobewertungen, Penetrationstests und Nachweise über Wiederherstellbarkeit kritischer Systeme. Für ein COBOL-System auf einem Mainframe aus den 1990er-Jahren, das von zwei verbliebenen Spezialisten betreut wird, ist das eine erhebliche Herausforderung — oder ein offenes Compliancerisiko.

Versicherungsunternehmen, die unter Solvency II fallen, stehen vor ähnlichen Anforderungen. Systeme, die Versicherungsmathematik und Bestandsverwaltung auf COBOL-Basis abbilden, können im Zuge einer DORA-Prüfung als kritische Schwachstellen eingestuft werden.

Die wahren Kosten des Betriebs: Mainframe-Lizenzen fressen Innovationsbudget

IBM Mainframe-Lizenzkosten: MIPS-Abrechnung und ihre Folgen

IBM-Mainframe-Lizenzen werden nach MIPS (Millions of Instructions Per Second) abgerechnet. Mit zunehmenden Transaktionsvolumina und neuen digitalen Kanälen steigen diese Kosten exponentiell. Viele deutsche Banken zahlen heute zweistellige Millionenbeträge jährlich allein für Mainframe-Betriebslizenzen — Geld, das weder in neue Features noch in Kundenerlebnisse fließt.

Total Cost of Ownership: Mainframe vs. Cloud-Infrastruktur

Hinzu kommen die Kosten für Legacy-Middleware, proprietäre Datenbanksysteme (IMS, VSAM) und den Betrieb von Rechenzentren, die oft nicht konsolidierbar sind, weil die Abhängigkeiten zu komplex sind. Ein moderner Java-basierter Stack auf Cloud-Infrastruktur (AWS, Azure oder Deutsche Telekom Open Telekom Cloud) kostet bei gleichem Transaktionsvolumen typischerweise 60–80% weniger.

Wie eine COBOL-zu-Java-Migration konkret aussieht

Strangler-Fig-Pattern: Modul für Modul ohne Betriebsunterbrechung

Eine COBOL-Migration ist kein Big-Bang-Projekt, bei dem alles auf einmal umgestellt wird. Seriöse Ansätze arbeiten mit Strangler-Fig-Patterns: Modul für Modul wird extrahiert, neu implementiert und parallel betrieben, bis der Altsystem-Anteil auf null gesunken ist.

Hier ein vereinfachtes Beispiel: Ein COBOL-Programm, das einen Kontostand abruft und prüft, ob eine Auszahlung möglich ist, könnte so aussehen:

* COBOL — Kontostand-Prüfung (vereinfacht)
IDENTIFICATION DIVISION.
PROGRAM-ID. KONTO-PRUEFUNG.

DATA DIVISION.
WORKING-STORAGE SECTION.
  01 WS-KONTONUMMER    PIC X(10).
  01 WS-KONTOSTAND     PIC 9(10)V99.
  01 WS-BETRAG         PIC 9(8)V99.
  01 WS-ERGEBNIS       PIC X(20).

PROCEDURE DIVISION.
    MOVE "DE1234567890" TO WS-KONTONUMMER
    MOVE 2500.00        TO WS-KONTOSTAND
    MOVE 300.00         TO WS-BETRAG

    IF WS-BETRAG <= WS-KONTOSTAND
        MOVE "AUSZAHLUNG OK"    TO WS-ERGEBNIS
    ELSE
        MOVE "DECKUNG FEHLT"    TO WS-ERGEBNIS
    END-IF

    DISPLAY WS-ERGEBNIS
    STOP RUN.

Das äquivalente Java-Modul, das als Microservice deployed werden kann:

// Java — KontoPruefungService.java
public class KontoPruefungService {

    public AuszahlungsErgebnis pruefeAuszahlung(
            String kontonummer,
            BigDecimal kontostand,
            BigDecimal betrag) {

        if (betrag.compareTo(kontostand) <= 0) {
            return AuszahlungsErgebnis.OK;
        }
        return AuszahlungsErgebnis.DECKUNG_FEHLT;
    }

    public enum AuszahlungsErgebnis {
        OK, DECKUNG_FEHLT
    }
}

Das Java-Modul ist testbar, versionierbar, dokumentierbar und kann in jede CI/CD-Pipeline integriert werden. Es läuft auf Standard-JVM-Infrastruktur und benötigt keine proprietäre Mainframe-Lizenz.

Migrations-Strategien im Überblick

Automated Translation, Wrapping und Domain-driven Rewrite im Vergleich

Es gibt nicht den einen richtigen Weg. Abhängig von der Systemkomplexität, dem verfügbaren Budget und der internen Expertise kommen verschiedene Ansätze in Frage:

Für die meisten deutschen Institute empfiehlt sich ein hybrider Ansatz: kurzfristig Wrapping für Stabilität, mittelfristig modulweiser Rewrite der geschäftskritischsten Pfade, langfristig vollständige Mainframe-Ablösung.

Was jetzt zu tun ist

Der erste Schritt ist eine ehrliche Bestandsaufnahme: Wie viel COBOL-Code ist in Produktion? Wer kennt ihn noch? Welche Systeme sind miteinander verwoben? Diese Analyse sollte von erfahrenen Migrationsexperten begleitet werden — nicht von demselben Team, das die Systeme täglich betreibt und zu nah dran ist.

Warten ist keine Strategie. Jedes Jahr ohne Handlung erhöht das Risiko: weniger COBOL-Spezialisten, steigende Mainframe-Kosten, wachsende Compliance-Lücken. Banken und Versicherungen, die heute mit der Planung beginnen, haben noch die Wahl. Die, die warten, werden irgendwann gezwungen sein — unter schlechteren Bedingungen.

Bereit für Ihre COBOL-Modernisierung?

CodeMigra hat Legacy-Migrationsprojekte für Finanzinstitute in Deutschland und Europa begleitet. Wir analysieren Ihren COBOL-Bestand, entwickeln eine realistische Migrationsstrategie und begleiten die Umsetzung — Schritt für Schritt, ohne Betriebsunterbrechung.

Kostenlose Erstberatung anfragen