Legacy systems in banking and insurance: modernise or replace?

Modernise. A full replacement of a core banking or policy administration system is justified in roughly one case in ten: when the vendor has ended support, when the platform cannot meet a regulatory deadline, or when the business model itself has changed. Everything else is better served by incremental modernisation around a system that keeps running.

That answer needs a test behind it. This article gives you the four realistic paths, the conditions under which each is correct, what the reconciliation and cutover work actually involves in a regulated firm, and where AI attaches without waiting for the rest of the estate to catch up.

Why the rewrite keeps being proposed, and keeps failing

Core systems in banking and insurance accumulate two decades of rules that nobody wrote down: interest accrual on the day a holiday falls, the handling of a policy endorsed mid-term, the branch that still posts a reversal differently. A rewrite promises to shed that. In practice the rules are the product, and rediscovering them under a go-live deadline is how a two-year programme becomes a four-year one.

There is a second, quieter reason. A replacement freezes change. For the duration of the programme, nothing else ships: no new product, no regulatory feature, no customer-facing improvement, because every change has to be made twice. Competitors ship for two years while you catch up to where you already were. That opportunity cost rarely appears in the business case, and it is usually larger than the licence saving that justified the programme.

Banking and insurance add a constraint that general modernisation advice tends to skip: dual running is not optional. Balances, accruals, policy values and regulatory reports have to reconcile across the old and new paths for at least one full cycle before anyone signs off. That work is a substantial share of the programme in its own right. A replacement multiplies it across every module at once, whereas incremental modernisation spreads it out and lets the team get good at it on a small module first.

Incremental modernisation accepts the old system and reduces its surface deliberately. Martin Fowler's description of the strangler fig application is the canonical write-up: new functionality grows around the edges of the legacy system until the old code can be removed piece by piece. The pattern works precisely because the business never stops.

The four paths, and when each is right

Most firms think they are choosing between two options. There are four, and they can be combined by module.

The honest general comparison sits in application modernization versus a rewrite. In banking and insurance the wrap path is underused: it is the cheapest way to make a twenty-year-old core reachable by anything modern, and it is reversible.

How to decide in your own estate

Run these six checks against each major system rather than against the estate as a whole. Different modules usually deserve different answers.

• Support status. Is the platform, the database and the runtime still vendor-supported and patchable? An unsupported core is a security finding, not an architecture preference.
• Change lead time. Measure how long a small regulatory change takes from request to production today. Under four weeks, the core is not your bottleneck.
• Knowledge concentration. If two people understand the batch schedule, you have a staffing risk that a rewrite makes worse before it makes better.
• Data quality. Reconciliation failures, duplicate customer records and unexplained suspense balances predict migration cost more reliably than lines of code.
• Interface surface. Count the downstream systems reading the core directly. Each direct reader is a migration dependency and a candidate for an API layer.
• Regulatory pressure. A dated obligation, on reporting or data localisation, is the one condition that legitimately forces a timetable.

Where the verdict is strangle or wrap, characterisation tests come first: they pin current behaviour, including the behaviour nobody intended, so you can tell a regression from a fix.

Where AI attaches in phase one

The argument for incremental modernisation gets easier when you notice that most AI value in banking and insurance sits beside the core, not inside it. Document intelligence over KYC files, statement analysis for credit decisions, claims file assembly, collections conversations and internal knowledge retrieval all read from the core and write back through a narrow interface. None requires the core to be replaced first.

That is why we sequence the API layer over the legacy monolith as the first deliverable in almost every programme. Once a clean read interface exists with an anti-corruption layer translating legacy field names into a modern domain model, AI work and mobile work can proceed in parallel with the slower structural change. The approach is set out in embedding AI into legacy systems without a rewrite, and the lending-specific version in modernizing a core lending system without a rewrite.

What does incremental modernisation cost?

A Legacy-to-AI Modernization Programme starts at $31,500 or ₹22,40,000 and runs to $105,000 or more for a large estate. An Enterprise Platform Implementation, the path you take when a packaged system is being configured and integrated, starts at $28,000 or ₹18,40,000 and reaches $140,000 or ₹1 crore. If the scope is a clean interface rather than a programme, API development and integrations starts at $7,000 or ₹4,40,000, which is usually the cheapest useful thing a bank can buy in a first quarter.

Before any of that, a ten-day Sprint Zero at $3,250 or ₹2,00,000 produces the system-by-system verdict, the dependency map and the sequencing plan, credited against the build. After go-live, a Care Plan carries the estate: Essential at $1,000 or ₹68,000 a month, Standard at $2,500 or ₹1,60,000, Enterprise at $5,250 or ₹3,40,000 with one-hour response and a named engineer. Published figures sit on the pricing page.

Cutover, parallel running and reconciliation

Run both, and compare

In a regulated firm, the new path runs alongside the old for at least one full accounting cycle. Both produce output; a reconciliation job compares them line by line and every difference is explained before anything is switched. Unexplained differences are not rounding, they are undiscovered rules.

Cut over by cohort, not by date

Move one product, one branch or one policy class first. Keep the routing layer able to send traffic back to the old path within minutes. A rollback you have rehearsed is worth more than a go-live weekend everybody dreads.

Freeze the data model, not the business

Agree the target domain model early and keep the anti-corruption layer as the only place legacy field names appear. When the old system finally retires, you delete a translation layer rather than rewriting every consumer.

When replacement really is the answer

Three conditions justify a replacement, and they are checkable. The vendor has withdrawn support and no patch path exists. A regulator has set a dated obligation the platform cannot meet at any reasonable cost. Or the business has changed shape so completely, moving from branch lending to embedded finance, say, that the old model no longer describes the product. If none of those holds, a replacement is usually a preference dressed as a necessity.

Incremental work has its own failure mode, and it is worth naming. If nobody owns a retirement plan, the strangler layer becomes permanent and you now run two systems instead of one. Every increment must name what it decommissions, with a date, or the programme quietly becomes a maintenance contract.

A worked example

A university ran a fifteen-year-old ERP that held student records, fee collection and payroll, with the same characteristics a mid-size insurer's policy administration system has: undocumented rules, a fixed annual cycle and no tolerance for downtime. Rather than replace it, we put an interface layer in front, moved functions out in order of pain, and kept the old system authoritative until each function had run in parallel. The programme is described in the legacy ERP modernisation case study.

The transferable lessons were unglamorous. The dependency map took longer than anyone budgeted because three downstream systems read the database directly and nobody had documented it. Reconciliation caught two rules that existed only in code, not in any specification. And the sequencing decision that mattered most was moving the least risky module first, so the team learned the cutover mechanics on something that could be rolled back without a regulatory conversation.

Before you commission anything

• Score every major system on support status, change lead time and data quality
• Write down the three conditions that would justify replacement, and test them honestly
• Fund the API and anti-corruption layer as deliverable one
• Insist that every increment names what it retires and when
• Budget a full accounting cycle of parallel running with automated reconciliation
• Rehearse rollback before the first cohort moves

Related reading

The strangler pattern explains the routing mechanics in detail, and our fintech and BFSI page describes the core systems we work against. If you want the system-by-system verdict for your own estate, talk to us.

Replace when support, regulation or the business model forces it; otherwise shrink the legacy system deliberately and let AI attach to the interface you build on the way.