Legacy Systems in Banking: The Real Cost and How to Modernize

Nine of the UK’s largest banks and building societies logged at least 803 hours of unplanned outages across just over two years. That is more than 33 days with customers locked out of their own money, spread across at least 158 separate incidents.

Most of that downtime traces back to systems nobody can safely change. Legacy systems in banking are core, payments, or customer applications a bank still runs on but can no longer modify at reasonable cost or risk. They have outlived vendor support, cannot expose modern APIs, or depend on a language and platform that fewer engineers understand every year.

The outage figures come from the UK Treasury Committee, published 6 March 2025, covering January 2023 to February 2025. The Committee attributed the failures to third-party supplier problems, disruptions from system changes, and internal software malfunctions.

The question facing most banks is not whether the core is a liability. It is which parts to modernize first, whether the core must be replaced at all, and what regulators now expect you to prove.

What are Legacy Systems in Banking?

A legacy system in banking is a core, payments, lending or customer-facing application that still processes live business but can no longer be updated, integrated, or scaled at acceptable cost and risk. Age is not the test. Loss of vendor support, absence of API access, batch-only processing, and a shrinking pool of engineers who understand the code are the tests.

The practical answer to what legacy systems in banking are turns on changeability, not install date. A fifteen-year-old core with an active vendor roadmap, documented APIs, and a team that ships changes every quarter is not a modernization candidate. A six-year-old in-house lending application with no test suite, one contractor who knows it, and an overnight batch window that cannot be shortened is one.

The legacy core banking systems most often flagged for modernization are mainframe deposit and loan platforms, batch-driven general ledgers, payment engines built around fixed-format messaging, card management systems, branch and teller applications, and the middleware layer stitching them together. In many banks, the middleware is older and less documented than anything it connects.

How Common are Legacy Core Banking Systems?

No clean census exists, and much of what circulates as prevalence data is vendor marketing rather than measurement. What does exist is failure data, and it is specific.

The Treasury Committee figures above cover nine named institutions and a defined 26-month window. At least 158 incidents. At least 803 hours. The Committee published the data precisely because the pattern was consistent across firms rather than isolated to one bad platform.

That pattern shows up in the causes as much as the totals. When a regulator-facing inquiry lists “disruption caused by a change in systems” among the leading reasons for failure, it is describing an estate where routine change carries operational risk. That is the working definition of a legacy problem, and it does not require a prevalence percentage to act on.

The talent side is easier to observe directly. COBOL, PL/I, and assembler skills still underpin a large share of deposit and payments processing, and the engineers who hold them are retiring faster than they are being replaced. Our own analysis of cybersecurity in banking notes that many established banks still run decades-old COBOL-based systems with no native support for modern encryption or real-time monitoring.

What Legacy Banking Systems Cost Every Year

The license and the mainframe MIPS bill are visible. Almost nothing else on this list is.

Table: Eight cost categories behind legacy system spend at a bank. Only the first typically appears as an identifiable line item.

The last row is the one that has become measurable. When a single institution’s outage locks customers out for days, the costs land across customer redress, regulatory engagement and remediation programs at once, and none of them sit in the IT budget where the original underinvestment happened.

Where Legacy Banking Systems Fail

Five failure modes account for most of what goes wrong in banking legacy systems.

1. Change is the hazard

The Treasury Committee named system changes as a leading cause of outages. In a well-instrumented estate, deploying a change is routine. In a legacy estate, it is the single riskiest thing the bank does in any given quarter, pushing teams toward fewer, larger releases and making each one more dangerous than the last.

2. Batch windows that cannot shrink

Overnight processing was a reasonable design when branches closed at five. It becomes a structural constraint the moment customers expect instant payments, real-time balances, and 24/7 service, and you can’t engineer it away without touching the core.

3. Fixed-format messaging

Payment engines built around rigid message formats cannot carry richer structured data. That limitation is now a compliance problem as well as a product one, for reasons covered in the next section.

4. No clean API surface

When the core cannot expose data through modern interfaces, every fintech partnership, mobile feature, and analytics project starts with another bespoke extract. Each extract is another thing to maintain and another copy of customer data to secure.

5. Concentrated, retiring knowledge

Documentation for systems of this age is usually partial. Reliable documentation rests with a small number of people, and their retirement dates are a real operational risk that most risk registers understate.

Regulations Now Shaping Core Banking Modernization

Three regulatory tracks have converted core modernization from a strategy discussion into a dated compliance obligation. Two of their first deadlines have already passed.

ISO 20022. The coexistence period for cross-border payments ended on 22 November 2025, according to SWIFT’s implementation guidance. Institutions still sending legacy MT messages fall back on conversion processing, and from 1 January 2026 that contingency processing and in-flow translation became chargeable services. Swift’s guidance points institutions that have not fully migrated toward planning their move during 2026, with further CBPR+ changes for non-instruction messages arriving in November 2026. A payment engine that cannot natively handle the richer format is now generating cost on every message.

DORA. Regulation (EU) 2022/2554 entered into application on 17 January 2025 and covers 20 types of financial entities and their ICT third-party providers. It sets requirements for ICT risk management frameworks, incident reporting, third-party risk monitoring, and both basic and advanced resilience testing, including threat-led penetration testing. Systems that cannot be tested, patched, or instrumented are difficult to evidence under that framework.

UK operational resilience. Under FCA policy statement PS21/3, firms had until 31 March 2025 to be able to operate their important business services within defined impact tolerances, having performed mapping and testing beforehand. The FCA frames the obligation as making the necessary investment to stay within tolerance, not merely identifying where you fall outside it. A core that cannot recover inside the tolerance a firm has set is a remediation commitment with a supervisor attached.

None of these rules name legacy technology as the target. All three make an untestable, unchangeable core progressively harder to defend.

Should You Maintain or Modernize a Legacy Banking System?

Not every legacy system needs modernizing, and modernizing rarely means replacing the whole core. The test is whether the system is stable and bounded, or brittle and load-bearing.

Table: A seven-signal triage for legacy banking systems. Two or more signals in the right column usually justify a modernization business case.

Key Considerations Before You Modernize

Five questions decide whether a program for how to modernize legacy systems in banking is actually ready to begin.

Do you know what depends on the core? Most banks underestimate this. The surprises are rarely the flagship channels; they are the reporting extracts, the reconciliation jobs and the regulatory returns that quietly read from the core overnight.

Who owns the product decisions? Modernization changes how products behave and how they run. Without a named business sponsor able to decide on edge cases, the program defaults to replicating current behavior exactly, which removes most of the benefit.

What is your evidence obligation? Under operational resilience and DORA-style regimes, you will need to show the supervisor what you tested and what you recovered. Building that evidence into the program costs far less than reconstructing it afterward.

Where does the data have to live? Some historical records migrate to the new platform. Some will not, and retention obligations do not lapse because the system holding them was retired. Decide this at design time.

Can you sustain funding across cycles? Core programs outlast budget years and sometimes sponsors. Sequencing the highest-risk components first means a pause leaves the bank safer than it started rather than stranded mid-migration.

Six Approaches to Core Banking Modernization

These six routes differ in cost, timeline, risk, and how much of the original system survives the process.

Table: Six modernization routes and where each fits a banking estate. Most programs run three or four of these across different components rather than picking one.

Wrapping the core behind an API layer and replacing capability by capability has become the default for a reason. It lets the bank ship customer-visible change while the core is still in place, and it keeps every step reversible. Full core replacement remains the right answer for some institutions, but it is a decision about the whole bank rather than about technology.

Also Read: How Digital Transformation in Banking Drives Innovation and Growth

How to Modernize Legacy Systems in Banking

1. Map every dependency on the core, including the quiet ones

Record a named owner, a support status, and a data classification for each system, interface, extract, and batch job. The reporting and regulatory feeds are the ones most often missed.

2. Score each component on operational risk and business value

Risk covers change hazard, recoverability, and failure impact. Value covers how much product work is blocked behind it.

3. Choose an approach per component

Use the table above. Applying one strategy across the whole estate is the most common planning error.

4. Put the API and integration layer in first

It gives every later migration a stable place to connect and stops the estate from acquiring more point-to-point interfaces while you work.

5.  Profile the data before designing the migration

Find dormant accounts, historical products no longer sold, customer records merged in from past acquisitions, and fields whose meaning changed at some point nobody documented.

6. Migrate by domain in waves, each with a rollback path

Run old and new in parallel through at least one full reconciliation and one full reporting cycle before cutting over.

7. Test the business process, not the component

Onboarding through payment through posting through statement through regulatory return. A passing unit test suite will not catch a broken end-of-day.

8. Rehearse the failure as well as the launch

Resilience regimes expect evidence that you can recover inside your stated tolerance. Generate that evidence during the program.

9. Decommission deliberately

Covered below, because this is where core programs most often lose control of both timeline and budget.

Legacy Banking System Modernization Cost

Legacy banking system modernization cost is driven by the approach, the number of interfaces, and the evidence burden, not by the size of the balance sheet. Rehosting a bounded workload is the cheapest route available. Replacing a core is the most expensive thing most banks ever do to their technology estate, because development is a minority of the bill.

For scale on the build side, our fintech app development cost analysis puts overall fintech builds between $45,000 and $350,000, with banking applications at the top of that range and clear regional variation:

Table: SparxIT published fintech application development costs by type and delivery region. These cover the application layer. Core replacement sits well above this range; rehosting and API wrapping sit below it.

Five factors move a modernization quote inside those bands:

• Interface count: Every system that reads from or writes to the core requires its own build, test, and cutover.
• Data condition: Clean, well-structured records migrate cheaply. Decades of merged customer files, retired product codes and undocumented fields do not.
• Regulatory evidence: Resilience testing, traceability and supervisory reporting are program costs, not afterthoughts.
• Parallel running: Operating two systems through full reconciliation cycles is a real, sustained line item and the one most often omitted from business cases.
• Decommissioning and archiving: Retiring the old platform properly costs money once. Not retiring costs money every year.

Also Read: How Legacy Application Modernization is Driving Business Agility?

Common Challenges During Core Banking Modernization

1. Change itself is the risk

With system changes among the leading causes of UK banking outages, a modernization program asks a bank to do far more of the thing that already breaks it. That argues for smaller, reversible increments rather than fewer, larger ones.

2. Data nobody can fully explain

Core systems accumulate decades of merged customer records, retired products, and fields whose meaning drifted. Profiling this before design is considerably cheaper than discovering it during migration weekend.

3. Evidence debt

Firms operating under resilience obligations need to demonstrate recovery within tolerance. Legacy components often cannot produce that evidence, turning a technical migration into a supervisory commitment with dates attached.

4. Vendor and third-party dependencies

The Treasury Committee listed third-party supplier problems among the leading causes of outages. Modernization usually increases the number of third parties before it reduces them, and DORA-style regimes now make that dependency a monitored risk in its own right.

5. Funding across sponsor changes

Core programs routinely outlast the executive who approved them. Delivering visible customer or regulatory value in each wave is what keeps funding intact through a leadership change.

6. The parallel-running tail

Running old and new systems in parallel is safe and expensive. Without a defined exit criterion per wave, parallel running quietly becomes permanent.

How to Build the ROI Case

When banks modernize legacy core banking systems, the business case rarely wins on architecture arguments. It wins when you measure the cost and risk of the current state as rigorously as the cost of the program.

Start with a baseline across the eight cost categories above for the specific components in scope. The license and infrastructure lines come out of finance records quickly. The change-friction, manual-reconciliation and blocked-product lines take longer and are usually where the real number sits.

Then quantify the benefit side in terms a CFO and a CRO both recognize:

Table: Five benefit categories for a core banking modernization business case, with the internal data source for each.

Two disciplines keep the case credible. Measure the baseline before the program starts, because a benefit with no evidenced “before” gets discounted in review. Reassesses after each wave, not only at the end, so a multi-year program generates proof early enough to defend its next tranche of funding.

Also Read: How Artificial Intelligence is Transforming the Financial Services Industry

How to Decommission a Legacy Banking System, and the Records You Must Keep

Switching off a legacy banking system is a records-and-controls decision before it is a technical one, and most modernization plans treat it as a footnote.

Financial records carry retention obligations arising from multiple legal, regulatory and organizational sources, and those obligations survive the platform that created them. Records under litigation hold or regulatory investigation cannot be destroyed while the hold stands. So the retired system’s data has to remain retrievable, intact, and auditable for years after the application stops processing.

That leaves three routes. Migrate the history into the new platform, which is cleanest but rarely possible in full, because a modern data model will not accept every legacy field. Extract it into a read-only archive that staff and auditors can query without the original application. Or leave the old system running purely as a viewer, which is the most expensive option and the one banks drift into by default when nobody decides otherwise.

Decide which route applies to which data set before migration begins. A retained read-only legacy platform carries license, infrastructure, security, and audit costs indefinitely, and it is usually the single largest avoidable expense in a core banking modernization program.

Choosing Support for Legacy Banking Modernization

Banks without in-house capacity for dependency mapping, data profiling or resilience testing often bring in external support for parts of a core program. The earlier sections suggest what to look for. A good partner chooses an approach per component instead of applying one strategy to the whole estate. It puts the API and integration layer in first and migrates in waves with a rollback path at each stage. It also generates resilience and recovery evidence during the program rather than reconstructing it afterward, and plans decommissioning and records retention from the start. Because supervisors and auditors will ask, it’s also worth confirming which standards a partner works to, such as ISO/IEC 27001, PCI DSS, SOX, GDPR and Basel II.

The work usually spans several disciplines. Legacy software modernization services typically include application modernization consulting, software re-engineering, code refactoring, data modernization, API upgrades, cloud modernization and cybersecurity enhancements. A BFSI software development practice adds banking-specific capability, including custom banking solutions, legacy migration, payments and billing, fraud detection, and compliance and risk management systems.

Some banks start with the customer-facing layer before touching the core, which makes an app development practice the more relevant starting point. Once core data becomes reachable, AI in banking and digital transformation in banking become practical next steps. For the cross-industry view of the same problem, see the legacy application modernization guide.