Banking Modernization Cost & ROI

Part 6 described a method that runs two systems in parallel, proves every slice, and meters out risk — visibly more involved than flipping a switch. So the economic buyer’s question is fair and unavoidable: what does it cost, and is it worth it? This part answers it the way the rest of the series operates — honestly, which here means a specific discipline up front. This article does not, and cannot, quote a price, because the only honest cost figure for a specific core comes from understanding that core first. What it gives you is the framework to reason about the economics: what moves the cost, the total cost of ownership the platform bill hides, the cost of not acting, and how to make the investment predictable. The reasoning parallels the general modernization business case; this is the banking-specific version.

What drives the cost

A core banking modernization’s cost is moved by a handful of factors, most of which you cannot know precisely until discovery. Each one also has a lever that pulls it back down, which is what makes the number something you shape rather than simply receive.

Cost driver	What makes it expensive	What reduces it
Approach: replace vs. modernize incrementally	A big-bang core replacement carries a heavy risk premium of overruns and rework, the kind that produces the TSB-class outcome. It is the largest single swing in the number.	Incremental delivery converts that premium into smaller bounded increments, and lets you stop after any slice with working software already in production.
Size and entanglement	Products, batch, and payments sharing data and logic in undocumented ways make the core hard to slice safely. It is entanglement, not lines of code, that costs.	Evidence-based discovery maps the seams before you commit, so you estimate from what the core actually contains rather than from a guess.
Data migration and integrity	Moving ledger-grade data with absolute integrity, and proving it moved correctly, is a major line item. Reconciliation is real and routinely underestimated.	Migrate slice by slice, automate the reconciliation, and leave dormant data behind rather than paying to move and re-prove records nothing reads.
Batch and payments logic	The overnight batch and real-time payment paths carry dense, corridor-specific, time-constrained rules that are expensive to reproduce and validate.	Reproduce the behavior slice by slice under parity tests, rather than rebuilding the whole engine at once and validating it all at the end.
Integration perimeter	Every external system the core touches adds surface to rebuild and re-test.	A strangler facade isolates each integration, and retiring dead ones first shrinks the perimeter you pay to carry across.
Compliance and regulatory testing	Every regulatory outcome the core produces has to be re-proven to exam standards, not just the happy path. This is testing scope that consumer software never sees.	Turn regulatory outcomes into per-slice acceptance criteria, so proof accrues as you go instead of piling up into one audit at the end.
Parallel run	Running the legacy and new systems side by side during transition is a genuine ongoing carrying cost.	Decommission each legacy slice the moment its replacement is proven, so parallel run is measured in weeks per slice, not years across the program.
Skills scarcity	A retiring COBOL workforce raises contractor rates and the cost of recovering knowledge that lives only in people’s heads.	Capture the core’s real behavior in tests and documentation early, before the people who understand it leave.

Read the table two ways. The middle column is what a discovery phase exists to size, because most of these you cannot cost accurately until you have read the core. The right column is what you actually control, and the approach row at the top is the one that moves the number most.

The cost the platform bill hides

The cheapest-looking option is almost always “keep running it,” because the visible cost is just the platform bill — capacity, licensing, support. That framing systematically undercounts. The full total cost of ownership of a legacy core adds:

• Rising maintenance. Most of an IT budget already goes to keeping the lights on. Deloitte’s CIO surveys put the run-the-business share of IT spend at roughly 55–57% (Deloitte, Global CIO Survey) — meaning the majority of the budget maintains yesterday rather than building tomorrow, and on a legacy core that share tends to climb.
• Technical debt as a drag on everything. McKinsey has estimated that technical debt can amount to 20–40% of the value of an entire technology estate, and that addressing it can free up to 50% more engineering time (McKinsey & Company). On a legacy core, that drag shows up as every new product taking longer than it should.
• The skills risk premium. A workforce retiring at ~10% a year (Part 3) means rising contractor rates and rising risk, both of which are real costs even though neither appears on the platform invoice.
• Opportunity cost. A core that cannot support real-time payments or a new channel is a revenue ceiling, not just a maintenance expense.
• Regulatory and breach exposure. Exam findings, remediation under deadline, and the downside risk of an incident on an unsupported system are costs with real expected value, even when unrealized in a given year.

Measured as TCO over the horizon that matters — not this year’s invoice — “keep running it” usually loses, even before counting the upside.

The cost of delay

The most important number in this analysis is often the one with no invoice: the cost of waiting. It compounds through three mechanisms specific to banking. The skills clock removes ~10% of the people who understand the core each year, raising the eventual cost of recovering their knowledge. The risk clock raises breach and exam exposure every year an unsupported system stays in place. And the opportunity clock keeps the revenue ceiling in place for every quarter the core cannot support new products. Modeling the current run-cost is the first step in seeing this — the Legacy Cost Calculator exists to make the standing cost concrete — and the cost of delay sits on top of it.

How to reduce the cost

Predictability bounds the number. These levers lower it. None of them is a discount, each is a decision about where the money goes, and together they are how the same modernization costs less.

1. Sequence by cost and blockers, not by the org chart. Modernize the workloads with the highest run-cost, or the ones blocking new revenue, first. Early spend then buys the largest return and helps fund what follows. A program ordered by which team argues hardest spends the same money for less of it back.
2. Do not pay to move dead weight. Every retired product, dormant dataset, and unused integration removed before migration is scope you never build, move, or re-prove. This is one of discovery’s most direct payoffs: it finds what can simply be switched off instead of carried across.
3. Reuse the validation harness. The parity tests and reconciliation built to prove the first slice amortize across every slice after it. The second migration is meaningfully cheaper than the first once the proving machinery already exists.
4. End parallel run quickly. Two live systems is a real carrying cost, so the lever is to decommission each legacy slice the moment its replacement is proven rather than letting the old core linger. Parallel run kept short is the difference between a transition cost and a permanent tax.
5. Right-size each workload. The cheapest defensible answer for a given workload is sometimes off-the-shelf software, and sometimes leaving a stable, cheap-to-run system exactly where it is. Deciding buy, keep, or build workload by workload avoids paying to custom-build what you never needed to.

Notice that most of these are not about working cheaper, they are about not spending on the wrong thing. The single largest avoidable cost on a core program is rework, and every lever above is a way to spend less of the budget discovering, mid-build, that a slice was scoped wrong.

How to make the cost predictable

Predictability is not the same as a low number; it is the absence of nasty surprises. On a regulated core it comes from two things:

1. A fixed-scope discovery phase first. Before any large commitment, a bounded discovery produces an evidence-based estimate grounded in what the core actually contains — its size, entanglement, data, batch, and undocumented rules. This is where AI-accelerated discovery pays off directly: it makes a thorough read of the core fast enough to estimate from evidence rather than from a guess, compressing what was months of manual archaeology into weeks.
2. Incremental delivery that bounds each slice. Because the work ships slice by slice (Part 6), each increment is estimated as it is planned, and the program forecasts small validated steps rather than one giant upfront number computed blind. You also retain the option to stop after any slice with working software already in production — a real form of cost control a big-bang program cannot offer.

This is the structural reason incremental modernization is more predictable, not just safer: it replaces one large estimate made under maximum uncertainty with many small estimates made as uncertainty resolves.

What the return actually looks like

Two honest cautions on the money. First, modernization is not free money, and the ROI is not instant. Running two systems in parallel during transition is a genuine cost, and the return arrives as risk reduced, maintenance avoided, and products enabled over the horizon — not as a line item next quarter. Anyone promising fast, guaranteed savings on a core migration is selling. Second, and consistent with every other part: sometimes the cheapest defensible answer is to not modernize a given workload yet. If a workload is stable, supported, cheap to run, and blocking nothing, its honest TCO may favor leaving it in place. The business case has to be built workload by workload on real numbers, which is exactly why it starts with discovery rather than a quote.

Where this leads

Once the case is made and the budget is plausible, the decision turns operational: who does the work, and onto what? The market is full of platforms and vendors, and the selection criteria that matter for a regulated core are not the ones a glossy RFP response emphasizes. Part 8, Core Banking Modernization Vendors, is an honest guide to evaluating platforms and the partner who migrates you onto them — what to ask, what to discount, and how to tell a real method from a confident promise.