Most legacy modernization programs in regulated financial institutions follow the same technical playbook. Most of them still struggle to deliver on time, on budget, and without a compliance incident along the way. The problem is rarely the technology. It is the assumption that having a good plan is the same as being prepared for the decisions the plan does not cover. This article covers five things that programs which actually work do differently — and why regulators across the world are paying close attention to all five.
The Pressure Is Coming From Both Sides
There has never been a worse time to be running a financial institution on 20-year-old technology. And there has never been a riskier time to modernize it badly.
From the business side, the ceiling is visible. A core banking system that cannot talk to modern payment rails cannot launch real-time products. A platform that was not built for APIs cannot connect to AI risk engines, open banking providers, or digital onboarding tools. Every new product becomes a custom engineering project. Every integration becomes a liability.
From the regulatory side, the bar is rising. Take the example of the EU's Digital Operational Resilience Act (DORA), which imposes specific requirements around resilience testing, third-party dependency management, and incident reporting — requirements that many legacy platforms were simply not built to meet. In the UK, the FCA's Consumer Duty places personal accountability for customer outcomes directly on boards, not just on compliance teams. In July 2026, the FCA published its landmark review of AI in financial services — the first of its kind initiated by a regulator globally — concluding that AI is now reshaping the entire sector and that firms on legacy infrastructure face compounding exposure, not just competitive disadvantage.
The question, then, is not whether to modernize. It is how to do it without breaking the things regulators require to keep working — while the business keeps running and the clock keeps moving.
That question does not have a simple answer. But there are things that programs which actually work do, consistently, that programs which stall do not.
The Playbook Is Not the Problem
Before getting into what works, it is worth being clear about what is not the problem.
The technical approach to legacy modernization in banking is well established. McKinsey has documented six principles drawn from more than fifty banking transformations. Deloitte and PwC have both written about how to frame and assess the transformation. The core approach — often called the Strangler Fig method, which means wrapping the old system in a modern layer and migrating one piece at a time while the original keeps running — is widely understood and, when followed properly, works.
Institutions that follow this approach make progress. Institutions that attempt large-scale, simultaneous replacement of core systems — sometimes called "rip and replace" — tend to create the kind of operational failures that make headlines and trigger regulatory notices.
So the playbook is not wrong. The problem is that any playbook describes what to do. It cannot tell you, for your specific institution with your specific regulatory obligations and your specific legacy architecture, when, in what order, and what to do when the standard answer does not fit your situation.
Those moments are where programs succeed or fail. And they arrive faster than most project plans anticipate.
Here are the five things that make the difference.
1. Know What Each Part of Your System Is Legally Required to Do — Before You Move It
The real issue: Your legacy system is not one thing. It is a collection of components — and some of them are carrying far more regulatory weight than others. Treating them as equivalent is the first and most expensive mistake a modernization program can make.
Think about it this way. A payments engine, a customer onboarding platform, a core banking ledger, and a reporting system all look like "technology" on a project plan. But they each carry different legal obligations. Disrupting a payments engine — even briefly — may trigger a regulatory incident under DORA. Disrupting a customer onboarding flow may violate Anti-Money Laundering requirements. Disrupting a reporting system may mean your regulator stops receiving data it is legally entitled to receive.
If you start moving things before you know what each part of the system is legally required to keep doing — uninterrupted — you are building your migration plan blind.
What this means in practice:
- Before anything is moved, sit down with your compliance, risk, and legal teams — not just your technology team — and map what each component is currently responsible for from a regulatory standpoint. This is not a technical exercise. It is a legal one.
- Use that map to decide what gets moved first, second, and last. The order should be driven by where regulatory exposure is lowest — not by what seems technically simpler.
- Build your migration timeline around regulatory review cycles, reporting deadlines, and supervisory examination schedules. Trying to run a complex cutover two weeks before your annual regulatory submission is a timing decision that will cause problems.
Why this matters beyond the technology team
Regulators across the world — the UK's FCA, the EU through DORA, the UAE's Central Bank (CBUAE), India's RBI, and others — are all moving toward holding boards directly accountable for the resilience and continuity of technology platforms, not just compliance teams. A gap created during a migration is not a technology failure. It is a governance failure. Understanding what each component must keep doing, legally, is what makes the program governable at the top.
2. Start With the Connections Between Systems — Not the Systems Themselves
The real issue: The natural instinct is to go straight for the most visible problem — the old core banking system sitting at the centre of everything. That is understandable. But it is almost always the wrong place to start.
Here is why. Legacy financial platforms are held together by connections — integrations between systems — that were built over decades, often by engineers who have long since left the organisation. Many of those connections were never properly documented. They exist. They work. But nobody can tell you exactly what they do or what breaks if you remove them.
When you try to modernize the core first, you pull on that thread without knowing where it leads. Things break in unexpected places. A system that appeared unrelated suddenly stops working. The migration stalls while the team spends weeks figuring out what it just disrupted.
Programs that start with the connections first — building a modern bridge between old and new before touching either — avoid most of these surprises. They surface the hidden dependencies in a controlled way. And they deliver something immediately useful: new products and third-party tools can connect to the modern bridge while the old core keeps running, untouched, underneath.
What this means in practice:
- Build the modern interface layer first. This sits in front of your legacy core and gives new products, AI tools, and third-party integrations a clean, modern connection point — without touching the legacy system itself.
- As you build that layer, you will discover the undocumented connections you did not know existed. That discovery process, done at the interface layer, is far cheaper and safer than discovering the same thing mid-way through a core migration.
- Set a target: within 10 to 12 weeks of starting this phase, something new should be working that was not working before — a new integration connected, a new product enabled, a new data feed live. That early proof of progress matters for the business and for the team.
Why this matters for the business side
The interface-first approach is not just a technical preference. It means the business starts seeing results in weeks, not years. New capabilities get unlocked while the riskier, longer migration work happens safely in the background. You do not have to choose between "keep the lights on" and "build for the future."
Evaluating whether a delivery partner has the depth of integration experience this phase requires is one of the harder assessments a technology leader faces. Our guide to choosing a fintech development partner covers exactly what to look for and the questions that reveal real capability versus claimed capability.
3. Decide What "Done" Looks Like Before You Start — And Put a Name on It
The real issue: The Strangler Fig approach runs old and new systems side by side during migration. Both process real transactions. An automated check compares the outputs of both. When the outputs match — consistently, over a defined period — you switch traffic to the new system and retire the old component.
In theory, this is the safest approach possible. In practice, two things go wrong, and both have nothing to do with technology.
The first: the side-by-side phase runs too long. Every extra week of running two systems costs more, creates more operational complexity, and produces awkward conversations with auditors who want to know why two active systems occasionally show different intermediate numbers — even when they agree at the end of the day.
The second — and this is where the real risk lives — is that nobody defined "done" precisely enough before the program started. When "the outputs match" is your only criterion, you will feel pressure to declare it matched before you genuinely know. Moving forward feels like progress. Staying in the side-by-side phase feels like delay. That pressure, in program after program, is what causes teams to move too early — and face a serious problem three months later.
What this means in practice:
- Before a single component is migrated, write down in plain language what "the new system is ready to take over" means. Not as a technical specification — as a statement a non-technical board member could read and understand. What level of matching, over how many days, with what exceptions allowed?
- Put a name on it. A specific person — with regulatory accountability, not just technical authority — should be the one who says "yes, we are ready." That person's name should be in the program governance document from the start.
- As KPMG has noted in its guidance on the Consumer Duty, boards are required to produce evidence of outcomes at every level of management. A cutover decision without a named accountable owner and a documented evidence trail is not a decision — it is an assumption.
Why this matters for the CFO
The cost of moving too early is not a line item on a project budget. It is remediation, potential regulatory enforcement, and the reputational cost of a public incident. The cost of being precise about what "done" means is a conversation and a document. That trade-off is never closer than it appears.
4. Design Compliance Reviews Around the Specific System — Not a Generic Checklist
The real issue: Every modernization program in a regulated institution includes compliance reviews. In practice, these reviews vary enormously in what they actually catch — and the difference between one that catches real issues and one that produces a clean sign-off on a problem that surfaces six months later is almost entirely about who runs it and what experience they bring.
Compliance reviews designed by teams without direct experience of regulatory supervision tend to test for the right words. They check that documentation exists, that frameworks are referenced, that boxes are ticked. What they miss is the operational reality: does this migration preserve every obligation the old component was carrying — as a regulator would test it in a supervisory review, not as an internal team would test it from a checklist?
This gap is becoming more important, not less. The FCA's July 2026 review made it explicit: as modernized systems become more interconnected and AI-driven, regulators are moving from reviewing individual firms to monitoring shared dependencies across the whole market. A migration that creates a new reliance on a third-party infrastructure provider — even temporarily — may be a change you are required to report under DORA's third-party risk rules. If your compliance review did not look for that, the sign-off has a gap in it.
What this means in practice:
- Each compliance review should be built around the specific component being migrated and its specific regulatory obligations — not applied from a standard template across the whole program.
- The question each review must answer is: would a regulatory supervisor, examining this component today, find that it meets every obligation the previous system was carrying? Can you show the evidence? Who, by name, stands behind that evidence?
- For components carrying material obligations — anything touching payments, customer data, or regulatory reporting — bring in external expertise for the review. Internal teams reviewing their own work have a blind spot that is structural, not personal.
Why this matters for the CEO
Regulatory problems in financial services do not stay in the technology department. They surface in board meetings, in correspondence from supervisors, and sometimes in the press. A compliance review designed to pass rather than to catch is the most common and most avoidable governance failure in modernization programs.
The questions to ask a prospective delivery partner about how they approach compliance reviews — and how to tell the difference between a team that has operated under regulatory supervision and one that has only designed for it — are in our fintech partner evaluation checklist.
5. Make Sure You Own Everything When It Is Over
The real issue: The most common long-term failure of a legacy modernization program is not a compliance incident or a cutover that went wrong. It is finishing the program and realising that you are just as dependent on outside help as you were before — because only the delivery team truly understands what was built.
This happens when knowledge transfer and documentation are treated as things to negotiate at the end of the program. By that point, the delivery team is moving on to the next client, the internal team has been observers rather than participants, and the new platform — however modern and capable — is opaque to the people who now have to run it.
The result is a new form of the same problem. You have replaced dependency on a 20-year-old system that nobody fully understood with dependency on a new system that your own team does not fully own. The technology has changed. The structural problem has not.
What this means in practice:
- Documentation is a delivery requirement at every phase — not something produced at the end. Every component that is migrated should produce, as part of that migration: clear documentation of how it works, how it connects to other systems, and what regulatory obligations it carries.
- Your internal team should be involved in the delivery of every phase, not just the review of it. By the time the program closes, your engineers should be able to explain every architectural decision. Your compliance team should be able to evidence every regulatory mapping. Your product team should be able to extend the platform without calling the delivery partner.
- Everything built for your program — every line of code, every design, every specification — belongs to your organisation. This needs to be stated unambiguously in the engagement terms from day one. It is not a detail. It is the difference between modernization and a new form of lock-in.
Why this matters for the board
The measure of a successful modernization program is not the go-live date. It is whether, twelve months after go-live, your organisation understands its technology better than it did before — and your reliance on any external party has decreased, not increased.
How to build IP ownership and knowledge transfer commitments into an engagement from the start — including the specific contract language to look for — is covered in our fintech partner evaluation guide.
The Regulatory Direction Is Clear
Regulators are not waiting. The FCA's Consumer Duty, DORA, the CBUAE's technology risk standards, and similar frameworks across regulated markets are all moving toward the same requirement: financial institutions must demonstrate — with evidence, at board level — that their technology platforms are resilient, compliant, and under control.
Legacy infrastructure that cannot meet those requirements is not just a business problem. It is a board accountability problem. And the longer a modernization program is deferred, the more complex the eventual migration becomes — more hidden dependencies to untangle, more undocumented integrations to map, more regulatory obligations to preserve through a migration that should have started earlier.
The five things in this article are not a new methodology. They are the governance decisions that sit underneath every methodology — the ones that determine whether a well-designed program actually delivers what it promises, or becomes another cautionary case study. The playbook has been published. What separates institutions that modernize successfully from those that stall is not access to the right framework. It is the quality of the decisions made at the points the framework does not reach.
Continue Your Evaluation
Further Reading
Regulatory sources:
- FCA: Landmark Review into the Impact of AI on Retail Financial Services (July 2026)
- EU Digital Operational Resilience Act (DORA) — Official Text
- KPMG: What Are the New Consumer Duty Requirements?
Industry research: