What Banks Should Prepare Before Replacing Legacy Core Infrastructure

Preparation starts before vendor selection

The work that decides whether your modernization succeeds happens inside your own walls, months before a single vendor demo. A bank that enters procurement without agreed outcomes and tested current-state facts hands control of the program to the platform it hasn't chosen yet, before it has named owners. That's how scope balloons and timelines slip.

The base rate here is sobering. IBM's 2026 Global Outlook for Banking and Financial Markets found that 94% of modernization projects exceed their original timelines, which the report frames as normal. When almost every program runs long, the overrun is the predictable cost of starting implementation before the institution understood its own complexity.

So the preparation you do now is the only lever you fully control. Frame the replacement as a transformation of how the bank runs its products and daily operations, including its controls, because that framing forces the right people into the room before design decisions get locked. Everything that follows in this article builds one readiness picture you can defend.

Audit the current core environment first

Start by building a reliable baseline of what you actually run and what it costs, including where it breaks, because you cannot design a future state on top of guesses. A current-state audit gives you the facts on scope and cost, including fragility, that every later decision depends on. The discipline that matters most is separating confirmed evidence from assumption and recording every place where documentation or the person who understood a system is already gone.

That missing-knowledge problem is real and getting worse. The average COBOL developer is now 55 to 58 years old, and roughly 10% retire each year. Undocumented business rules and architectural logic leave with them. When a supervisor of a critical batch job walks out the door, part of your current state leaves with them.

An audit is a knowledge-capture exercise with a deadline, because the window to interview people who remember why a system behaves a certain way closes a little more every quarter. Record what they know now while you still can, and mark every unverified fact as an open risk.

What systems and workloads exist?

Inventory every component of the core environment, then attach ownership and criticality to each one. A single-point-of-failure risk hides in plain sight when nobody has counted.

TFL Tech's modernization guidance warns that if fewer than five employees can maintain your core and any are within ten years of retirement, you carry a critical risk that appears on no balance sheet. So the inventory has to record more than the asset. Each entry needs ownership and a defined business purpose. It should also record its criticality and lifecycle status, along with known dependencies, which turns a list of technology into a map of exposure you can act on.

Where does the legacy core constrain growth?

Tie every constraint to a number. Document the costs and operational effects of the legacy core, then connect each to a relevant impact.

The cost picture is understated. A 2024 Deloitte banking survey found that institutions underestimate the true total cost of ownership of legacy systems by 70 to 80%, so a core the bank believes costs X costs closer to 3.4X once compliance overhead, developer inefficiency, and downtime are counted. That gap is your argument. When you translate a vague sense of drag into a documented figure per incident and per delayed launch, the case for replacement stops being a preference and becomes arithmetic that finance and the board can weigh.

Data readiness determines migration difficulty

Know your data before you plan its move, including where it lives and who owns it. Data readiness decides migration difficulty more than any platform choice, because no software corrects unclear ownership or unreliable source records for you.

The failure statistics point straight at this. Gartner's widely cited figure holds that 83% of data migrations fail or exceed their budgets and schedules, and the most common cause is poor source data quality discovered too late. Teams routinely find three to five times more data problems during migration than they expected going in.

Data discovery and cleansing, with associated archival decisions, belong early in the program. The inference the raw statistic doesn't spell out: the projects that fail didn't lack tools, they lacked a clean starting picture. Front-loading the messy work of understanding your own records is the single cheapest insurance you can buy against a stalled conversion.

Which data should actually move?

Classify records by their status before determining whether they belong in the new core. Moving less lowers cost and risk at the same time.

Experian's migration research found that 44% of US organizations reported data quality issues that delayed their projects, and a large share of that pain came from dragging unfit records into a system with stricter standards. Business and compliance owners should approve each record's migration disposition. That approval is a governance act, not a technical one, because deciding a record is obsolete carries legal weight only an owner can accept.

How will data accuracy be proven?

Define how correctness gets demonstrated before you write a migration plan and identify sign-off owners. The point is evidence.

Oracle's analysis of migration outcomes reports that cost overruns on these projects average 30% and time overruns 41%, driven largely by load failures that surface late when poor data hits the target system. With that in mind, decide now what proof a later migration plan must produce and who signs it. When accuracy has a named owner and a defined tolerance from the start, the late-stage surprises that inflate those overrun figures lose most of their power.

Map processes before preserving them

Document how your priority journeys actually run across the bank before anyone translates a requirement into a new system. Otherwise you rebuild decades of workarounds you never needed. The map has to separate genuine controls and differentiating capabilities from legacy patches that exist only because the old core forced them.

The Lab Consulting, which maps processes for banks and credit unions, describes end-to-end mapping as the jumping-off point that lets an institution see inefficiencies and automation opportunities before committing to a future state. The diagram forces a decision.

That decision is what most banks skip. When a workaround gets documented, someone has to say out loud whether it's a control the bank needs or a scar left by the old system, and that judgment turns a migration into a redesign. Preserve what protects the bank. Redesign what only protected the old software.

Which journeys deserve priority?

Rank critical journeys by customer impact and transaction volume, alongside risk and modernization value. The ranking reveals your plausible first migration wave.

That prioritization matters because attempting everything at once carries the risk profile that sank earlier programs. Commonwealth Bank of Australia spent over $1 billion across five years on its SAP core migration between 2008 and 2013, a scope few institutions could absorb today. Ranking journeys is how you avoid that concentration, because it lets you prove the platform on a contained, high-value slice before betting the whole bank on a single cutover.

Which controls cannot be disrupted?

Map the controls inside each critical process, and have control owners validate the map. An efficient future workflow still has to hold up under audit.

The cost of getting this wrong is documented. Bizzdesign's banking example breaks Know Your Customer (KYC) into six distinct control steps, from identity verification through ongoing monitoring, each of which a new workflow must preserve. So the control owner, not the process designer, holds the veto here. Financial integrity and compliance are theirs to protect, which means a redesigned journey ships only after the people accountable for those controls confirm nothing essential was streamlined out of existence.

Integration maps expose hidden scope

Identify everything wired to the core, directly or indirectly, before you estimate anything. That means every channel and connected internal or external system. Every one of these connections is scope that estimates ignore at their peril.

The scale of hidden interconnection is easy to underestimate. Industry analysis cited by Kaopiz found the average enterprise manages data across 14 different systems at once, and a bank's core sits at the center of far more than that. Each interface carries constraints on when and how you can change it.

The implication for your estimate is direct. Peripheral integration work is where core programs quietly double in size, so record each connection's volumes and timing dependencies, including contract limits, now to keep a later cost figure honest. An integration you forgot to map is an invoice you'll receive anyway.

Migration risk needs measurable guardrails

Convert broad fear of conversion into a risk register with owners and tolerances. Cover every material conversion risk, and give it a mitigation and evidence requirement, along with an escalation route and contingency before implementation planning starts.

TSB's 2018 migration shows what an unmanaged register costs. The bank was fined £48.65 million by the FCA and PRA for operational resilience failings, and although the data itself migrated, the platform failed on go-live and locked out a large share of its 5.2 million customers. TSB paid £32.7 million in customer redress on top of the fine.

The regulators were explicit that governance was the root cause. They found TSB had failed to plan the migration properly and to control its outsourcing risk. A risk register assigns a human owner to each way the conversion could harm a customer, which is the exact discipline TSB was penalized for lacking.

How will banking services remain available?

Define acceptable disruption and recovery outcomes now. Set the requirements that will govern cutover and recovery. You can set the targets before a platform exists even though the detailed cutover plan cannot.

TSB's disruption illustrates why the target matters. The bank did not return to business-as-usual until December 2018, roughly eight months after the April go-live, and around 80,000 customers switched away during the year. So decide in advance how much downtime the bank will tolerate and how fast it must restore service, because those numbers become the acceptance gate a vendor's cutover approach has to clear later.

When should regulators become involved?

Engage regulators early based on relevant jurisdictional and outsourcing considerations. Compliance and legal should map applicable obligations, then validate them with the relevant authority.

For EU institutions this is now concrete. Since January 2025 the Digital Operational Resilience Act (DORA) has applied without a phase-in period to over 21,000 financial entities, which imposes requirements for ICT third-party arrangements under Articles 28 to 44. That timing changes your sequence. Because the outsourcing and exit-strategy obligations attach the moment you sign with a platform provider, the compliance mapping must be complete before procurement.

Governance must precede procurement

Decide who owns the transformation and how decisions get made before any vendor joins the conversation. Put an executive sponsor and a cross-functional governance model in place with real authority over program decisions, and stand up a transformation office where the program's scale justifies one.

Governance is the strongest predictor of the outcome. McKinsey research on digital transformations found that only about 16% succeed at improving performance and sustaining the gains, and in regulated industries the rate falls to between 4% and 11% because of added compliance and audit complexity. Weak governance is a recurring cause across the failures.

Here's what that low rate implies for your sequence. Settling ownership and decision authority before vendors arrive is the single move that improves your odds the most, made at the only time it's still cheap to make.

Who has each decision right?

Build a decision matrix that assigns authority across leadership and relevant functions. The goal is to eliminate both ownerless decisions and ambiguous vetoes that stall the program later.

Engaged leadership pays off measurably. McKinsey's research shows organizations with strong leadership commitment achieve success rates 1.6 times higher than those with weak commitment. A decision matrix is how that commitment becomes operational, because it names the person who breaks a tie between risk and product before the tie ever forms, which keeps a multi-year program from freezing at its first hard tradeoff.

What outcomes justify replacement?

Define baseline measures and target outcomes for the modernization. Build the business case on total cost.

The stakes on maintenance are large. ThoughtWorks reported that nearly two-thirds, 64%, of retail banks' IT budgets go to system maintenance rather than improvement, so freeing even part of that spend is a quantifiable target. The case has to include all delivery and post-migration costs. Leaving those out is how a program looks affordable until the invoices for everything that isn't the license start arriving.

A phased rollout reduces concentrated risk

Form an initial migration hypothesis before procurement around a defined first wave. A phased approach spreads risk that a single big-bang cutover concentrates into one catastrophic moment.

The evidence favors containment. Softjourn's modernization guidance describes a sidecar approach that runs a modern core alongside the legacy system and first handles 1 to 5% of the customer base. This proves new capabilities on a contained subset before scaling. That contained slice is your hypothesis made real.

Define it before procurement because the shape of your first wave changes which platforms fit. A vendor built for a parallel digital business is a different choice than one built for a full-entity migration, so knowing your sequencing criteria and pilot boundaries in advance turns vendor conversations into a test of real constraints. Keep the hypothesis flexible enough to adjust against what platforms can actually deliver.

People readiness is operational readiness

Prepare the organization for changed roles and workflows, including controls and service models, before implementation begins. A core migration reshapes how people work, so it requires operational planning and early involvement from frontline and control teams.

The workforce dimension decides outcomes. McKinsey's transformation research found that people in key transformation roles who ensure their units collaborate with others make success up to 1.8 times more likely, a larger effect than most technical factors. So involve the people who run the controls and serve the customers while decisions are still open. A workflow designed without the tellers and reconciliation staff who live inside it ships with blind spots that only surface once real transactions start flowing.

Which capabilities are missing internally?

Assess your access to legacy experts and the modern skills needed for the program. The result should separate roles the bank must own permanently from expertise it can rent temporarily.

This gap is structural in banking. NIIT's analysis notes that legacy systems demand rare "bridge skills" spanning old and new technology, which hiring alone rarely closes because so few people hold both. That's the practical line to draw. Vendor management and architecture ownership, including risk acceptance, stay in-house because they define what the bank becomes, while specialized migration and testing muscle can come from outside for the duration of the program and leave when it ends.

What must future vendors receive?

Assemble a readiness brief that gives vendors a complete view of your actual complexity. This brief packages everything above so a vendor can respond specifically to your bank.

The brief matters because unclear requirements drive the failures already covered here. Kaopiz's research found that 72% of failed projects expanded beyond their original scope without adjusting timelines. A detailed brief is your defense against that, because when a vendor prices against your documented integration landscape and data condition, the scope surprises that inflate other programs have already been surfaced and owned.

Use a readiness gate before procurement

Proceed to procurement only when readiness is documented well enough to support a credible vendor conversation. This is the final internal test, and it's a decision the bank makes about itself before it makes any decision about a platform.

A gate demands honesty about what's incomplete. Given that the base rate for these programs runs to a 94% timeline overrun, an unresolved gap carried silently into procurement becomes a gap the vendor discovers at the worst possible moment.

So every accepted gap needs four things attached before you pass the gate:

• An owner accountable for closing it

• A remediation plan with concrete steps

• A budget implication the business case reflects

• A deadline that fits the program timeline

Modernization proceeds when gaps are acknowledged. Passing this gate with your gaps clearly documented is what turns a mandate to replace the core into a program you can actually control.

Discuss modernization readiness with Doocat

Once your readiness picture is built, the next step is a grounded conversation about how it maps to a real platform. Doocat is a modular digital banking platform for banking institutions. Its microservices architecture is available through SaaS or on-premises deployment.

That modular design fits the phased, contained approach this article argues for, because microservices support modernization in waves. The deployment choice matters too, since your data residency and outsourcing obligations shape whether SaaS or on-premises suits your regulatory position.

Bring your readiness findings to the table. Your readiness findings are the inputs that make an early conversation useful, so share them before moving into platform demonstrations or implementation planning. Contact Doocat to walk through your readiness picture and shape a roadmap grounded in your institution's real complexity.