Insurance Legacy Modernisation: Should You Refactor or Rebuild?

When the pressure to modernise grows, the wrong choice might cost you. Here’s how to decide.

Most insurance CTOs and development team leads don’t need convincing that their legacy systems are a problem. They already know. They’ve lived with the slow deployments, the fragile integrations, the compliance scrambles, the same routine every time a new regulation lands.

But what are product leaders supposed to do about it?

Refactoring and rebuilding are fundamentally different strategies with different costs, timelines, risk profiles and long-term implications for regulatory compliance.

Choose the wrong path and you can spend years and significant budget arriving at the same dead end you were trying to escape.

Our view, having worked through this decision with insurance teams across Europe: start with a structured refactor, rebuild only the components where the architecture itself is the blocker, and treat a full system rewrite as the last resort rather than the default response to technical pain.

Legacy insurance systems still running on architectures built decades ago are expensive to maintain and increasingly difficult to evolve. Maintenance costs compound as the systems age. Developers who understand the codebase retire. Patches accumulate. Integration with modern APIs becomes progressively harder. And while insurers are managing all of this, agile InsurTech competitors are launching new products in weeks using cloud-native infrastructure built for speed.

There’s an organisational cost too. Managing a system that everyone knows is broken but nobody has sanctioned fixing creates drag that doesn’t show up in a budget line, with slow decisions and workarounds that become permanent, and the unfortunate side effect of engineering talent quietly moving on.

Regulatory pressure adds another layer of complication. European frameworks including GDPR, DORA and the EU’s Financial Data Access regulation (FiDA) place real demands on how insurance data is stored, accessed and protected. Patching compliance onto a fundamentally non-compliant architecture has limits, and those limits have a way of becoming urgent at the worst possible time.

Legacy system refactoring means improving the existing codebase without changing what the system fundamentally does. You’re cleaning up technical debt, restructuring modules, improving performance and making the system easier to maintain and extend, but the core architecture stays in place. The system keeps running throughout.

Rebuilding means replacing the system entirely. You’re starting with a clean architecture, modern technology choices and a blank slate on technical debt. The old system typically continues to operate in parallel until the new one is ready to take over.

A third path, the phased or hybrid approach, combines elements of both. Stable modules are refactored while legacy components that block growth are rebuilt incrementally. This is the most realistic route for most insurers.

Here are a few common scenarios we’ve seen where refactoring is usually the best choice:

The architecture is sound but the code is struggling

If the fundamental design of your system is still valid (the data model is sensible, the core workflows reflect how the business actually operates, the system handles volume reliably) but the codebase has grown messy, slow or brittle over time, legacy application modernisation through refactoring is likely the right intervention. 

Common indicators of this situation are mounting technical debt without architectural rot, slow deployment cycles caused by test coverage gaps rather than fundamental design issues, and performance problems traceable to specific code inefficiencies rather than systemic structural limits.

Refactoring should always map to a tangible business goal. Cleaner code is not a goal. Faster claims processing or meeting a specific compliance requirement, those are goals. Refactoring without a clear business rationale tends to stall, losing management support and leaving teams worse off than if they hadn’t started. Before committing, make sure the plan is written down, shared and aligned with stakeholders, and that there’s genuine budget and appetite to see it through.

Compliance updates are driving the change

If the primary driver is regulatory compliance (adapting to DORA, meeting GDPR standards for data access and portability, or aligning with FiDA obligations) refactoring is usually sufficient. Compliance changes typically affect specific components, how data is stored, how it’s accessed and how audit trails are maintained. These are addressable through targeted refactoring without dismantling the entire system. 

This is relevant for European insurers operating across multiple jurisdictions, where the regulatory surface area is broad but the required changes tend to be well-defined.

Budget and timeline constraints are real

Rebuilding takes time, typically two to five years for a full core system replacement. For insurers who need to move faster or who can’t absorb the upfront cost of a full rebuild, refactoring delivers incremental value more quickly, with each phase paying for itself before the next begins.

Alternatively, there are times when a full rebuild is the decision that teams should make. Here are some common scenarios:

The system can’t support where the business is going

If your growth strategy depends on capabilities your current architecture simply cannot support (real-time claims processing, usage-based products, AI-powered underwriting, seamless third-party integrations), refactoring will only take you so far. A monolithic policy administration system built on batch-processing logic isn’t going to become a real-time platform through code cleanup. When every new capability requires workarounds and integrations break more often than they hold, the foundation needs replacing rather than repairing.

Integration debt has become unmanageable

Legacy systems built before APIs were standard typically rely on point-to-point integrations, custom connectors and workarounds that accumulate into what’s sometimes called integration debt, a tightly coupled web that makes every change expensive and every new connection risky. When adding a new partner or service takes months rather than weeks, and touching one integration reliably breaks others, refactoring the application code won’t solve the problem. The integration architecture needs to be rebuilt from the ground up, typically around modern API-first design and microservices.

Security vulnerabilities run deep

Older insurance systems were built before modern cybersecurity frameworks existed. They may lack encrypted APIs, modern access controls or the infrastructure hardening now expected by regulators and insurers’ own risk teams. When security gaps are architectural, that is, baked into the design of the system rather than addressable by patching, refactoring is unlikely to be sufficient. 

For insurers handling sensitive policyholder data across European markets, GDPR and DORA impose obligations that are difficult to meet on infrastructure that wasn’t built with those standards in mind. A security-first rebuild from the architecture level might be your only credible path to genuine compliance.

A note of caution on rebuilds generally: a full system replacement should only be attempted when your team understands the existing system well enough to clearly define what it does, what the edge cases are and how you’ll validate that the new system handles them correctly. Rebuilding a system you don’t fully understand is one of the quickest ways to reproduce the same problems in a newer codebase.

Before committing to either path, work through the following questions. No single answer is definitive, what matters is the pattern of your answers. A consistent lean toward the rebuild column is a signal worth taking seriously, but it should prompt deeper investigation rather than an immediate decision. Most teams that think they need a full rebuild discover on closer inspection that the architecture is sounder than the codebase suggests.

If most of your responses fall in the ‘rebuild’ column, incremental refactoring is likely to result in diminishing returns. If the picture is mixed, a phased approach is probably the right starting point.

The rebuild vs. refactor decision is not a binary one. Most insurance modernisation projects land somewhere in between: stable, well-designed components are refactored while legacy modules that actively block growth (a monolithic claims engine, a rigid policy administration system, a fragile integration layer) are rebuilt incrementally alongside the existing system. This reduces the risk of a single large deployment and allows the business to see value at each stage rather than waiting years for a big-bang release.

The key discipline is sequencing. Start with the components causing the most pain or blocking the most value, not the ones that are easiest to replace. In insurance, that typically means prioritising the claims engine or integration layer, where issues like processing delays and fraud exposure are most acute. Only then should you turn to the policy administration system.

Build new components around modern API-first design so they integrate cleanly with whatever remains of the legacy system during the transition. And define clear criteria for what ‘done’ looks like at each phase, so the project doesn’t drift.

Insurance systems are heavily regulated and business-critical. A modernisation programme that stalls, overruns or destabilises production is worse than the status quo it was meant to replace.

A strong modernisation partner should bring three things to the table: 

First, the technical depth to assess your current architecture honestly, mapping dependencies, quantifying technical debt and giving you a clear picture of what refactoring can and cannot achieve. 

Second, structured discovery before any development begins, with a discovery workshop process that maps your system’s architecture, identifying the components causing the most pain and aligning the technical roadmap with business priorities. 

Third, a security-first approach built into the architecture from the bottom up. In insurance, security and compliance aren’t features that should be added later. Working with a partner that holds ISO 27001 certification and builds to European regulatory standards by default significantly reduces the compliance risk that comes with any modernisation programme.

At DO OK, we work with insurance teams across Europe to make exactly this kind of decision. We begin with discovery, understanding your system, your roadmap and your constraints before recommending a path. No matter where your insurance tech modernisation journey takes you, we help you make the case internally and execute with the rigour that insurance-grade systems require.

Contact us today to speak with our team about your modernisation options.