Einblicke

Versicherer in DACH stehen 2026 unter einem doppelten Druck: regulatorische Vorgaben aus IDD, DORA und dem EU AI Act verlangen nachweisbare Modernisierungspfade, und gleichzeitig erodieren COBOL-Mainframes und 20 Jahre alte Java-Monolithen die Marge durch Wartungskosten, die jährlich zweistellig wachsen. Die Versuchung, „noch ein Jahr" zu warten, war noch nie teurer.

Dieser Artikel ist der Praxisleitfaden, den wir bei Softescu bei jedem Versicherungs-Modernisierungsprojekt anwenden: warum es 2026 keinen weiteren Aufschub mehr gibt, welche drei Modernisierungspfade in der Praxis funktionieren, wie Datenmigration ohne Betriebsausfall läuft, wie Sie Underwriter und Endkunden parallel berücksichtigen, und welche vier Anti-Patterns wir aus echten Projekten kennen.

Warum Versicherer 2026 nicht mehr warten können

Drei Treiber zwingen die Entscheidung in dieses Jahr:

• Regulatorisch — DORA ist seit Januar 2025 in Kraft und verlangt nachweisbare ICT-Resilienz mit Test- und Reporting-Pflichten, die auf Legacy-Systemen nicht erfüllbar sind. Der EU AI Act bringt 2026 erste Hochrisiko-Klassifizierungen für Versicherungs-Underwriting. Beides verlangt API-Schnittstellen, Observability und Audit-Trails, die Mainframes nicht liefern.
• Wirtschaftlich — Wartungskosten für COBOL/RPG-Bestände wachsen jährlich um 12–18 %, weil Personal aus dem Markt ausscheidet. Versicherer, die wir betreuen, berichten, dass 40–60 % ihres IT-Budgets in reine Bestandspflege fließen.
• Kundenseitig — Endkunden vergleichen Versicherungs-Apps mit Banking-Apps. Eine Schadenmeldung, die per Telefon und PDF läuft, verliert Marktanteil an Insurtechs mit App-basierter Annahme in 90 Sekunden.

Die Konsequenz: Modernisierung ist 2026 keine technische Option mehr, sondern eine Geschäftsentscheidung mit harter regulatorischer und finanzieller Frist.

Die drei Modernisierungspfade — wann was passt

In der Versicherungsbranche haben sich drei Modernisierungsmuster bewährt. Die Wahl hängt vom Risikoprofil, der Datenkomplexität und der Lebenszeit des Legacy-Systems ab.

Pfad 1 — Strangler Fig. Das Strangler-Fig-Muster (nach Martin Fowler) ist die richtige Antwort, wenn das Legacy-System aktiv genutzt wird, das Geschäft nicht stillstehen darf und Risiko gestreut werden muss. Sie bauen neue Funktionalität in einer modernen Architektur — typischerweise eine Service-Plattform mit Drupal/Symfony oder .NET als Frontend-Layer und domänenspezifischen Microservices — und routen die alten Pfade schrittweise um. Passt, wenn das Legacy-System weitere 12–24 Monate parallel laufen kann, die Domäne in 8–15 Bounded Contexts zerlegbar ist und parallele Schreibvorgänge konsistent gehalten werden können.

Pfad 2 — Rewrite. Ein vollständiger Rewrite ist die richtige Wahl, wenn das Bestandssystem so technisch verschuldet ist, dass Strangler-Erweiterungen mehr Aufwand erzeugen als ein Neubau, die Geschäftsdomäne sich grundlegend ändert (Solvency II Review, neue Produktlinien), oder ein befristeter Stillstand akzeptabel ist (interne Systeme, Innovations-Bereiche). Anti-Pattern: Rewrite als Default zu wählen, weil „endlich aufgeräumt werden muss". Rewrites sind teuer, riskant und scheitern in der Versicherungsbranche regelmäßig nach 18–36 Monaten an Anforderungs-Drift.

Pfad 3 — Coexistence. Das Legacy-System bleibt dauerhaft als System of Record für regulatorisch sensible Daten (Verträge, Schäden, Buchhaltung) bestehen. Neue Funktionalität läuft in einem modernen Stack, der via API mit dem Legacy-System spricht. Häufig für Versicherer mit Kernsystemen wie SAP FS-CD, msg.PMQ oder COR&FJA, bei denen ein vollständiger Datenumzug regulatorisch und vertraglich nicht praktikabel ist. Anti-Pattern: Coexistence als Dauerlösung deklarieren, ohne Abschluss-Plan. Ohne Frist degeneriert das Muster zu zwei dauerhaft synchronisierten Systemen mit doppelten Wartungskosten.

Datenmigration mit Doppellauf und Rollback

Die Datenmigration ist der Punkt, an dem die meisten Versicherungsprojekte stolpern. Unsere Methodik:

1. Schema-Mapping mit dokumentierten Annahmen — jede Mapping-Regel hat eine Quelltabelle, eine Zieltabelle, eine Transformations-Funktion und einen explizit dokumentierten Edge-Case-Katalog (NULL-Behandlung, historische Datenformate, Sonderzeichen, Mehrfach-Mandanten-Felder).
2. Doppellauf-Phase (3–6 Monate) — beide Systeme schreiben parallel. Ein Consistency-Worker vergleicht 100 % der Schreibvorgänge in beiden Systemen und alarmiert bei Divergenz. Erst wenn die Divergenz-Rate unter 0,01 % liegt, wechselt der Lese-Pfad.
3. Rückfallplan mit Daten-Snapshot — vor dem Cutover wird ein vollständiger Snapshot des Legacy-Systems eingefroren. Bei kritischen Divergenzen in den ersten 30 Tagen Postcutover kann zurückgeschaltet werden, ohne Daten zu verlieren.
4. Geblendetes Cutover — der eigentliche Wechsel passiert nachts, mit einem Read-Only-Fenster von zwei Stunden für die letzte Synchronisation. Endkunden sehen „Wartungsfenster für zwei Stunden"; Underwriter haben einen Read-Only-Modus.

Diese Methodik haben wir bei einem regionalen Versicherer angewendet, dessen Kernsystem 14 Millionen Verträge enthielt. Cutover ohne Betriebsausfall, Divergenz-Rate nach 60 Tagen Doppellauf bei 0,003 %.

Digital Experience: Underwriter und Endkunde parallel

Die häufigste Fehlentscheidung in Versicherungs-Modernisierungen ist, die Endkunden-App zu priorisieren und die interne Underwriter-Oberfläche als „kommt später" zu behandeln. Das Ergebnis: schöne Kunden-App, aber Underwriter, die weiterhin in 1990er-Greenscreen-Terminals arbeiten und manuell zwischen Systemen wechseln müssen, um eine Police zu prüfen.

Unsere Reihenfolge:

1. Underwriter-Cockpit zuerst — eine moderne Web-Oberfläche, die alle relevanten Datenquellen (Police, Schaden, Risiko-Score, externe Daten) in einer einzigen Ansicht aggregiert. Das hebt sowohl Bearbeitungszeit als auch Datenqualität spürbar an.
2. Endkunden-App auf derselben Service-Schicht — die APIs, die das Underwriter-Cockpit verwendet, werden für die Endkunden-App wiederverwendet. Das verhindert das klassische Problem zweier paralleler Stacks mit unterschiedlichen Datenmodellen.
3. Vertriebs-Tooling als Konsequenz — sobald Underwriter und Endkunden auf demselben Datenmodell arbeiten, wird das Vertriebs-Tooling fast trivial: dieselben APIs, eine andere Oberfläche.

Bei einem unserer Versicherungs-Kunden haben wir diesen Pfad in 14 Monaten umgesetzt: Underwriter-Cockpit (Monat 1–6), Endkunden-App (Monat 7–11), Vertriebs-Portal (Monat 12–14). Die gemeinsame Service-Schicht hat die Entwicklungszeit der späteren Module um 40–50 % reduziert.

Vier Anti-Patterns aus echten Projekten

1. „Lift and shift" ohne Refactoring. Das Legacy-System wird 1:1 in die Cloud verschoben, ohne Modernisierung. Resultat: höhere Kosten als zuvor (Cloud-Compute ist teurer als gut ausgelastetes On-Prem), keine Architektur-Verbesserung, kein Business Value. Lift and shift macht nur Sinn als Zwischenschritt vor einem Strangler-Fig-Ansatz, nie als Endzustand.

2. Big-Bang-Cutover ohne Doppellauf. Das neue System geht an einem Stichtag live, das alte wird abgeschaltet. Wenn dann Divergenzen auftauchen — und sie tauchen immer auf — gibt es keine Rückfallebene. Wir haben Projekte übernommen, in denen das Big-Bang-Cutover zu wochenlangen Notbetrieben führte.

3. Microservices ohne Bounded Contexts. Die Domäne wird in 80 technische Microservices zerlegt, die alle gegen dieselben Datenbanken sprechen. Resultat: verteilter Monolith mit höherer Komplexität und gleicher Kopplung wie zuvor. Bounded Contexts müssen vor den Services kommen, nicht nach.

4. Modernisierung ohne Underwriter-Beteiligung. Die IT-Abteilung entscheidet die Roadmap, ohne mit Underwriter und Schadenbearbeitern zu sprechen. Die neue Oberfläche ist technisch sauber, aber für die tägliche Arbeit unbrauchbar. Wir reservieren in jedem Versicherungs-Engagement mindestens zwei Wochen Discovery vor Ort mit den tatsächlichen Anwendern.

Wie wir das bei Softescu angehen

Wir haben in den letzten zehn Jahren Modernisierungsprojekte in der Versicherungsbranche begleitet — vom regulatorisch getriebenen Solvency-II-Reporting über die Modernisierung von Schadenbearbeitungs-Plattformen bis zur Migration von Bestandsdaten aus 30-jährigen Mainframe-Beständen. Die gemeinsame Linie: Modernisierung in der Versicherungsbranche ist kein Tech-Projekt, sondern ein Geschäftsprojekt mit IT-Hebel. Die regulatorischen, organisatorischen und Datenfragen müssen vor den Architekturentscheidungen geklärt sein.

Wenn Ihr Team eine Versicherungs-Modernisierung plant — Discovery, Architektur-Reviews, eine dedizierte Liefer-Mannschaft oder ein vollständiges Enterprise-Web-Engagement — sprechen Sie uns an.