Insights

Insurers in 2026 are caught between two pressures: regulation from IDD, DORA, and the EU AI Act demands demonstrable modernisation paths, while COBOL mainframes and twenty-year-old Java monoliths erode margin through maintenance costs that grow double digits every year. The temptation to wait "one more year" has never been more expensive.

This article is the playbook we apply at Softescu on every insurance modernisation engagement: why 2026 leaves no further room for delay, which three modernisation paths actually work in practice, how data migration runs without operational downtime, how to keep underwriters and policyholders in parallel, and the four anti-patterns we keep seeing on real projects.

Why insurers can no longer wait

Three drivers force the decision into this year:

• Regulatory — DORA has been in force since January 2025 and requires demonstrable ICT resilience with testing and reporting obligations that legacy systems cannot meet. The EU AI Act brings the first high-risk classifications for insurance underwriting in 2026. Both demand API surfaces, observability, and audit trails that mainframes do not provide.
• Economic — maintenance costs on COBOL/RPG estates grow 12–18% per year as the skill base leaves the market. The insurers we work with report 40–60% of their IT budget going to pure maintenance.
• Customer-side — end customers compare insurance apps with banking apps. A claim filed by phone and PDF loses market share to insurtechs with app-based intake in 90 seconds.

Consequence: modernisation in 2026 is no longer a technical option. It is a business decision with a hard regulatory and financial deadline.

The three modernisation paths — when each one fits

Three modernisation patterns have proven themselves in insurance. The choice depends on the risk profile, data complexity, and remaining life of the legacy system.

Path 1 — Strangler Fig. Martin Fowler's pattern is the right answer when the legacy system is actively used, the business cannot pause, and risk must be spread. You build new functionality in a modern architecture — typically a service platform with Drupal/Symfony or .NET as the frontend layer and domain-specific microservices — and route the old paths over gradually. Fits when the legacy system can run in parallel for another 12–24 months, the domain decomposes into 8–15 bounded contexts, and parallel writes can be kept consistent.

Path 2 — Rewrite. A full rewrite is the right call when the legacy is so technically indebted that Strangler extensions cost more than greenfield, when the business domain is fundamentally changing (Solvency II Review, new product lines), or when a bounded outage is acceptable (internal systems, innovation areas). Anti-pattern: picking rewrite as the default because "we finally need to clean up". Rewrites are expensive, risky, and routinely fail in insurance after 18–36 months on requirements drift.

Path 3 — Coexistence. The legacy system stays permanently as the system of record for regulatorily sensitive data (policies, claims, accounting). New functionality runs in a modern stack that speaks to the legacy via API. Common for insurers running SAP FS-CD, msg.PMQ, or COR&FJA, where a full data move is not practical regulatorily or contractually. Anti-pattern: declaring coexistence as a permanent answer without an exit plan. Without a deadline, the pattern degenerates into two permanently synchronised systems with double maintenance.

Data migration with parallel run and rollback

Data migration is where most insurance projects stumble. Our method:

1. Schema mapping with documented assumptions — every mapping rule has a source table, a target table, a transformation function, and an explicit edge-case catalogue (NULL handling, historical date formats, special characters, multi-tenant fields).
2. Parallel-run phase (3–6 months) — both systems write in parallel. A consistency worker compares 100% of writes across both systems and alerts on divergence. The read path switches only when divergence drops below 0.01%.
3. Rollback plan with data snapshot — before cutover, a complete snapshot of the legacy is frozen. If critical divergences appear in the first 30 days post-cutover, you can switch back without losing data.
4. Blended cutover — the actual switch happens overnight with a two-hour read-only window for final sync. End customers see "maintenance window, two hours"; underwriters have a read-only mode.

We applied this method at a regional insurer whose core system held 14 million policies. Cutover with no operational downtime, divergence rate at 0.003% after 60 days of parallel run.

Digital experience: underwriter and policyholder in parallel

The most common bad call in insurance modernisation is prioritising the customer-facing app and treating the internal underwriter UI as "comes later". The result: a pretty customer app, and underwriters still working in 1990s green-screen terminals, manually switching between systems to check one policy.

Our sequence:

1. Underwriter cockpit first — a modern web UI that aggregates all relevant data sources (policy, claim, risk score, external data) in a single view. This visibly lifts both processing time and data quality.
2. Customer app on the same service layer — the APIs the underwriter cockpit uses get reused for the customer app. This avoids the classic problem of two parallel stacks with different data models.
3. Sales tooling as a consequence — once underwriters and customers work against the same data model, the sales tooling becomes nearly trivial: same APIs, different UI.

On one of our insurance engagements, this sequence ran 14 months end to end: underwriter cockpit (months 1–6), customer app (months 7–11), sales portal (months 12–14). The shared service layer cut the development time of the later modules by 40–50%.

Four anti-patterns from real projects

1. "Lift and shift" without refactoring. The legacy is moved one-to-one to the cloud, no modernisation. Result: higher costs than before (cloud compute is more expensive than well-utilised on-prem), no architectural improvement, no business value. Lift and shift only makes sense as a stepping stone before a Strangler Fig approach, never as an end state.

2. Big-bang cutover without parallel run. The new system goes live on a target date, the old system is switched off. When divergences appear — and they always do — there is no fallback. We have taken over projects where the big-bang cutover led to weeks of crisis operations.

3. Microservices without bounded contexts. The domain is split into 80 technical microservices that all hit the same databases. Result: a distributed monolith with more complexity and the same coupling as before. Bounded contexts have to come before the services, not after.

4. Modernisation without underwriter involvement. The IT department decides the roadmap without speaking to underwriters and claims handlers. The new UI is technically clean but useless for daily work. We reserve at least two weeks of on-site discovery with the actual users on every insurance engagement.

How we approach this at Softescu

Over the past decade, we have worked on insurance modernisation projects across the spectrum — from regulator-driven Solvency II reporting through claims-platform modernisation to migrating policy data out of 30-year-old mainframe estates. The common thread: insurance modernisation is not a tech project, it is a business project with an IT lever. The regulatory, organisational, and data questions have to be settled before the architecture decisions.

If your team is planning an insurance modernisation — discovery, architecture reviews, a dedicated delivery team, or a full enterprise web engagement — get in touch.