TL;DR

• COBOL- und Mainframe-Systeme lassen sich schrittweise mit dem Strangler-Fig-Pattern modernisieren, ohne den laufenden Betrieb zu gefaehrden
• Versicherungen brauchen Zero-Downtime-Migrationen -- ein Ausfall im Schadensystem kostet 50.000 bis 200.000 EUR pro Stunde
• VAG- und VAIT-Konformitaet erfordert lueckenlose Audit-Trails, Funktionstrennung und dokumentierte Aenderungsprozesse
• Managed Kubernetes ab 4.000 EUR/Monat ersetzt den Aufbau eines internen Plattform-Teams (Kosten: 450.000+ EUR/Jahr)
• Praxis-Ergebnis: Mittelstaendischer Versicherer migriert Schadenbearbeitung in 9 Monaten, senkt Bearbeitungszeit von 40 auf 3 Sekunden

Kubernetes fuer Versicherungen: Legacy-Modernisierung ohne Risiko fuer den Betrieb

Versicherungen gehoeren zu den konservativsten IT-Branchen in Deutschland. Das hat gute Gruende: Ein Ausfall im Schadensystem oder in der Policenverwaltung kostet direkt Geld und Kundenvertrauen. Gleichzeitig stehen viele Versicherer vor dem Problem, dass ihre Kernsysteme 20 bis 30 Jahre alt sind, auf COBOL oder PL/I basieren und jede Aenderung Monate dauert.

Kubernetes bietet einen Weg aus diesem Dilemma. Aber nur, wenn die Migration so geplant wird, dass der laufende Betrieb zu keinem Zeitpunkt gefaehrdet ist.

Die Legacy-Herausforderung in der Versicherungsbranche

Typische IT-Landschaft eines mittelstaendischen Versicherers

Ein Versicherungsunternehmen mit 500 Mitarbeitern betreibt in der Regel eine IT-Landschaft, die historisch gewachsen ist:

Das Grundproblem: Diese Systeme sind eng miteinander verkoppelt. Die Schadenbearbeitung greift direkt auf die Bestandsfuehrung zu. Die Tarifierung liest aus der gleichen Oracle-Datenbank. Aendert man ein System, brechen die anderen.

Warum Versicherungen nicht einfach neu bauen koennen

Ein Big-Bang-Austausch scheitert in der Praxis an drei Punkten: VAG und VAIT verlangen lueckenlose Dokumentation aller IT-Aenderungen (ein Komplettaustausch ist pruefungsrechtlich ein Alptraum), 30 Jahre Geschaeftslogik in COBOL zu verstehen und nachzubauen dauert Jahre, und ein kompletter Neubau kostet 5 bis 15 Mio. EUR. Deshalb funktioniert eine schrittweise Migration besser.

Das Strangler-Fig-Pattern: Legacy schrittweise ersetzen

Das Strangler-Fig-Pattern (benannt nach der Wuergfeige, die einen Wirtsbaum langsam umwaechst) ist die bewaehrteste Strategie fuer Legacy-Modernisierung. Der Kern: Neue Funktionen werden als Microservices auf Kubernetes gebaut, waehrend das Legacy-System weiterlaeuft. Schritt fuer Schritt werden Funktionen aus dem Monolithen herausgeloest.

Phase 1: API-Gateway als Fassade

Der erste Schritt ist ein API-Gateway, das vor dem Legacy-System steht. Alle Anfragen laufen durch dieses Gateway. Anfangs leitet es 100% der Requests an das alte System weiter. Spaeter koennen einzelne Routen auf neue Services umgeleitet werden.

# api-gateway-konfiguration.yaml
# Ingress-Routing: Neue Services auf Kubernetes, Legacy ueber Proxy
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: versicherung-api-gateway
  namespace: claims-modernization
  annotations:
    nginx.ingress.kubernetes.io/use-regex: "true"
spec:
  rules:
  - host: api.versicherung-intern.de
    http:
      paths:
      # Neue Schadenanlage laeuft bereits auf Kubernetes
      - path: /api/v2/claims
        pathType: Prefix
        backend:
          service:
            name: claims-service-v2
            port:
              number: 8080
      # Bestandsdaten kommen noch vom Legacy-System
      - path: /api/v1/policies
        pathType: Prefix
        backend:
          service:
            name: legacy-proxy
            port:
              number: 3000
      # Tarifierung: Hybrid -- neuer Rechenkern, alte Daten
      - path: /api/v2/tariff
        pathType: Prefix
        backend:
          service:
            name: tariff-engine-v2
            port:
              number: 8080

Phase 2: Erste Microservices extrahieren

Nicht alle Funktionen eignen sich gleichermassen fuer die Migration. Die besten Kandidaten haben klare Grenzen, eigene Daten und messbare Geschaeftswirkung.

Empfohlene Reihenfolge fuer Versicherungen:

Phase 3: Neuer Schaden-Service auf Kubernetes

Ein konkretes Beispiel: Der neue Schadenanlage-Service (First Notice of Loss) als Kubernetes Deployment.

# claims-fnol-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: claims-fnol-service
  namespace: claims-modernization
  labels:
    app: claims-fnol
    compliance: vait
    data-classification: confidential
spec:
  replicas: 3
  selector:
    matchLabels:
      app: claims-fnol
  template:
    metadata:
      labels:
        app: claims-fnol
        version: v2.1.0
    spec:
      serviceAccountName: claims-fnol-sa
      containers:
      - name: fnol
        image: registry.versicherung-intern.de/claims-fnol:2.1.0
        ports:
        - containerPort: 8080
        env:
        - name: LEGACY_BACKEND_URL
          value: "http://legacy-proxy:3000"
        - name: DB_HOST
          valueFrom:
            secretKeyRef:
              name: claims-db-credentials
              key: host
        resources:
          requests:
            cpu: "500m"
            memory: "512Mi"
          limits:
            cpu: "1000m"
            memory: "1Gi"
        livenessProbe:
          httpGet:
            path: /health/live
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /health/ready
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5
      # Sidecar fuer Audit-Logging (VAIT-Anforderung)
      - name: audit-logger
        image: registry.versicherung-intern.de/audit-sidecar:1.4.0
        env:
        - name: AUDIT_TARGET
          value: "elasticsearch"
        - name: RETENTION_DAYS
          value: "3650"
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"
          limits:
            cpu: "200m"
            memory: "256Mi"

Der Audit-Logger als Sidecar ist kein Nice-to-Have, sondern eine VAIT-Pflicht. Jeder Zugriff auf Kundendaten, jede Statusaenderung eines Schadenfalls muss protokolliert und 10 Jahre aufbewahrt werden.

VAG- und VAIT-Konformitaet auf Kubernetes

Die wichtigsten regulatorischen Anforderungen

Versicherungen unterliegen dem Versicherungsaufsichtsgesetz (VAG) und den Versicherungsaufsichtlichen Anforderungen an die IT (VAIT). Fuer Kubernetes-Infrastruktur sind folgende Punkte besonders relevant:

VAIT-Anforderung: Benutzerberechtigungsmanagement

# vait-rbac.yaml
# Funktionstrennung: Entwickler duerfen nicht in Produktion deployen
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: claims-developer
  namespace: claims-staging
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "create", "update", "patch"]
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]
---
# Produktion: Nur CI/CD-Pipeline darf deployen, kein manueller Zugriff
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: claims-production-deployer
  namespace: claims-production
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "update", "patch"]
# Kein "create" und kein "delete" -- bestehende Deployments werden aktualisiert

VAIT-Anforderung: Aenderungsmanagement

Jede Aenderung an der Produktionsumgebung muss dokumentiert und genehmigt sein. GitOps mit ArgoCD oder Flux erzwingt das automatisch: Kein Deployment ohne Commit, kein Commit ohne Pull-Request, kein Pull-Request ohne Review.

# argocd-application-claims.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: claims-fnol-production
  namespace: argocd
spec:
  project: claims-production
  source:
    repoURL: https://git.versicherung-intern.de/platform/claims-manifests.git
    targetRevision: main
    path: production/claims-fnol
  destination:
    server: https://kubernetes.default.svc
    namespace: claims-production
  syncPolicy:
    automated:
      prune: false
      selfHeal: true
    syncOptions:
    - CreateNamespace=false
    - PruneLast=true

Beachten Sie: prune: false ist bewusst gewaehlt. In einer Versicherungsumgebung sollen nicht mehr benoetigte Ressourcen manuell entfernt werden, nicht automatisch. Das verhindert versehentliches Loeschen durch fehlerhafte Commits.

Audit-Trail: 10 Jahre Aufbewahrungspflicht

VAIT verlangt lueckenlose Nachverfolgbarkeit. In Kubernetes laesst sich das mit dem Kubernetes Audit-Log und externem Log-Shipping umsetzen.

# audit-policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
# Alle Aenderungen an Claims-Namespaces vollstaendig protokollieren
- level: RequestResponse
  namespaces: ["claims-production", "claims-staging"]
  verbs: ["create", "update", "patch", "delete"]
  resources:
  - group: "apps"
    resources: ["deployments", "statefulsets"]
  - group: ""
    resources: ["secrets", "configmaps", "services"]
# Lesezugriffe auf Secrets protokollieren (Datenschutz)
- level: Metadata
  resources:
  - group: ""
    resources: ["secrets"]
  verbs: ["get", "list"]
# Alles andere: nur Metadata
- level: Metadata

Kostenvergleich: Legacy-Betrieb vs. Kubernetes-Modernisierung

Ist-Zustand: Was Legacy wirklich kostet

Viele Versicherer unterschaetzen die Kosten ihrer bestehenden Systeme, weil diese ueber Jahre hinweg als gegeben akzeptiert wurden.

Soll-Zustand: Kubernetes-basierte Modernisierung

Die Einsparung liegt bei 400.000 bis 1.000.000 EUR pro Jahr, je nach Ausgangslage. Aber der groessere Vorteil ist die Geschwindigkeit: Neue Tarife in Wochen statt Monaten, neue Schnittstellen in Tagen statt Quartalen.

Fuer eine detaillierte Aufschluesselung der Managed-Service-Kosten lesen Sie unseren Artikel Was 4.000 EUR/Monat Managed Kubernetes beinhaltet.

Migrationspfad: 9 Monate vom Start bis zum ersten Service in Produktion

Monat 1-2: Assessment und Architektur

• Bestandsaufnahme aller Legacy-Systeme und Abhaengigkeiten
• Definition der Zielarchitektur mit dem Strangler-Fig-Pattern
• Auswahl des ersten Migrationskandidaten (typischerweise Schadenanlage)
• Aufsetzen der Kubernetes-Infrastruktur durch den Managed-Service-Partner

Monat 3-5: Erster Microservice und API-Gateway

• Entwicklung des FNOL-Service auf Kubernetes
• Integration mit dem Legacy-System ueber das API-Gateway
• Aufbau der CI/CD-Pipeline mit GitOps
• VAIT-konforme Dokumentation und Audit-Trail

Monat 6-7: Parallelbetrieb und Tests

• Shadow-Traffic: Alle Anfragen gehen an beide Systeme, Ergebnisse werden verglichen
• Last- und Performance-Tests unter realistischen Bedingungen
• BaFin-konforme Testdokumentation
• Schulung der Fachabteilung

Monat 8-9: Go-Live und Rollback-Sicherheit

• Schrittweises Traffic-Shifting: 5%, 10%, 25%, 50%, 100%
• Automatisches Rollback bei erhoehter Fehlerrate
• Abschaltung des Legacy-Pfads nach 4 Wochen stabilem Betrieb

Einen allgemeinen Leitfaden zur Migration finden Sie in unserem Artikel Legacy auf Kubernetes migrieren.

Warum Versicherungen auf Managed Kubernetes setzen sollten

Versicherungen sind keine Technologie-Unternehmen. Der Kernprozess ist Risikouebernahme und Schadenregulierung, nicht der Betrieb von Container-Infrastruktur. Trotzdem versuchen manche Versicherer, Kubernetes intern zu betreiben. Die Erfahrung zeigt, warum das selten funktioniert:

Das Personal-Problem: Ein Kubernetes-Team braucht mindestens 3 Engineers fuer 24/7-Betrieb. Auf dem deutschen Arbeitsmarkt kosten Kubernetes-Experten 80.000 bis 120.000 EUR Bruttojahresgehalt. Drei Engineers plus Sozialabgaben, Weiterbildung und On-Call-Zulagen ergeben schnell 450.000 EUR pro Jahr -- fuer ein Team ohne Redundanz.

Das Kompetenz-Problem: Kubernetes entwickelt sich schnell. Alle 4 Monate gibt es ein neues Minor-Release. Wer nicht am Ball bleibt, hat nach einem Jahr veraltete Cluster mit bekannten Sicherheitsluecken. Das passt nicht zu den Pruefungsanforderungen der BaFin.

Das Risiko-Problem: Wenn der einzige Kubernetes-Engineer kuendigt, steht die Plattform ohne Betreuung da. Bei einem Managed Service ist das das Problem des Anbieters, nicht Ihres.

Ein Managed-Service-Partner bringt genau die Kompetenz mit, die eine Versicherung intern nicht wirtschaftlich aufbauen kann: 24/7-Betrieb, Patch-Management, Security-Monitoring und Compliance-Dokumentation. Und das fuer einen Bruchteil der Kosten eines eigenen Teams.

Warum Mittelstandsunternehmen gerade bei fehlenden internen Ressourcen auf externe Partner setzen, erklaeren wir in Kubernetes Skill-Gap im Mittelstand.

Haeufige Fragen von Versicherungs-IT-Leitern

Kann der Mainframe wirklich abgeschaltet werden?

Nicht sofort, aber schrittweise. Das Strangler-Fig-Pattern erlaubt es, den Mainframe weiterlaufen zu lassen, solange einzelne Funktionen noch dort laufen. In der Praxis planen Versicherer 3 bis 5 Jahre fuer die vollstaendige Abloesung.

Was passiert bei einem Ausfall waehrend der Migration?

Durch Parallelbetrieb und API-Gateway ist ein Rollback jederzeit moeglich. Der Traffic wird automatisch und innerhalb von Sekunden zurueck auf das Legacy-System geleitet.

Wie reagiert die BaFin auf Container-Infrastruktur?

Die BaFin hat keine spezifischen Vorgaben fuer oder gegen Container. Entscheidend ist, dass VAIT-Anforderungen erfuellt werden: dokumentierte Prozesse, Funktionstrennung, Audit-Trail und Risikomanagement. Eine gut dokumentierte Kubernetes-Infrastruktur erfuellt diese Anforderungen oft besser als ein historisch gewachsenes Legacy-Setup. Mehr zum Thema Datenschutz in unserem Artikel Cloud, DSGVO und Kubernetes-Compliance.

Checkliste: Ist Ihre Versicherung bereit fuer Kubernetes?

• Mindestens ein Legacy-System verursacht regelmaessig Beschwerden aus der Fachabteilung
• COBOL-Entwickler gehen in den naechsten 5 Jahren in Rente
• Neue Tarife oder Produkte dauern laenger als 3 Monate bis zum Go-Live
• Die BaFin hat bei der letzten Pruefung Maengel in der IT-Dokumentation festgestellt
• Das IT-Budget steht, aber es fehlen die Leute fuer den Betrieb
• Der Vorstand hat Digitalisierung als strategisches Ziel definiert

Wenn Sie drei oder mehr Punkte mit Ja beantworten, lohnt sich ein Gespraech ueber einen konkreten Modernisierungspfad.

Verwandte Artikel

• Kubernetes fuer Versicherungen: VAIT und Solvency II-konforme Container-Infrastruktur -- Technische Tiefe zu VAIT und Solvency II
• Legacy auf Kubernetes migrieren: Schritt-fuer-Schritt Anleitung -- Allgemeiner Migrationsleitfaden
• Was 4.000 EUR/Monat Managed Kubernetes beinhaltet -- Kostenaufschluesselung
• Kubernetes 24/7-Betrieb im Mittelstand -- Warum Rund-um-die-Uhr-Betrieb intern schwer umsetzbar ist
• Kubernetes Skill-Gap im Mittelstand -- Das Personal-Problem und wie man es loest

Sie modernisieren Ihre Versicherungs-IT und suchen einen Partner fuer den sicheren Kubernetes-Betrieb? Wir uebernehmen Aufbau, Betrieb und VAIT-konforme Dokumentation Ihrer Container-Plattform -- damit Ihr Team sich auf das Versicherungsgeschaeft konzentrieren kann. Jetzt unverbindlich Kontakt aufnehmen.