ARTICLE 2 OF 3:  DIGITAL TRANSFORMATION SERIES

By Wirason Kongprasonk

Modernising Financial Technology Without Disrupting Daily Operations

The meeting where this decision usually gets made follows a recognisable shape. Someone has flagged that a system is outdated, vendor support is narrowing, a new regulatory requirement may have exposed a gap, the current platform may still work, but it’s only because teams are using manual workarounds that were never meant to be permanent. At some point, someone from technology or operations, has put a slide in front of leadership that says, in diplomatic language, where the infrastructure is no longer fit for purpose.

What happens next is where financial institutions diverge sharply, some move many defer and a meaningful share of those that do move run into problems they did not expect — not because the technology they chose was wrong, but because the transition was treated as a technology project when it was really an operations project wearing a technology label.

Choosing the right platform is straightforward compared to getting from the old system to the new one without breaking what currently works.

Why Reliable Systems Stay Past Their Useful Life

The standard story about legacy technology in financial services frames it as a failure — evidence of neglect, poor decisions, or accumulated debt. That framing misses something important. Many of the oldest systems still running inside banks and brokers are still running precisely because they work. A settlement system that has processed millions of transactions without a material incident is not a failure. It did exactly what it was built to do.

The problem is not unreliability. The problem is that the requirements around these systems have changed in ways they were not designed to handle real-time reporting, granular regulatory data, integration with digital client channels. None of that was part of the original specification, and retrofitting it is expensive. It is often more expensive than building from scratch would have been, had anyone started earlier.

What typically happens instead is a series of workarounds of middleware layers, manual compensating processes. Patches that extend the system’s life while adding complexity around it. This is rational in the short-term. Over a decade, it can make the eventual replacement significantly harder than it expected to be.

The Cost that Never Makes it into the Business Case

Modernisation business cases in financial services cover licensing, implementation, migration, and training. These are the visible costs. What is often underestimated is the disruption that happens during the transition. This disruption can decide whether the programme is seen as a success or a struggle.

Some of this is expected. Teams may take months to feel confident using a new platform. Processes may need to be redesigned, not just taught again. Integrations may also need to be rebuilt from scratch.

The harder part to plan for is the knowledge that is not written down anywhere. It often sits with people who understand how things work day-to-day. When the system changes, it either gets formally captured — which requires deliberate effort before the change, not during it — or it quietly disappears, and the problems that it was solving start reappearing in the new environment.

The operational knowledge embedded in workarounds is invisible in a modernisation business case. It becomes very visible the moment it is gone.

Three Things a Phased Approach Actually Requires

Phased modernisation has become the default recommendation for legacy replacement, and in principle it is the right call. In practice, it requires considerably more discipline than most programmes apply, starting well before any technology decision is made.

The first thing it requires is a genuinely honest inventory of current dependencies. Not the architecture diagram showing how systems are supposed to connect — the actual map of how they do connect, including every informal workflow built around a system gap and every manual step supplementing an automated process. This inventory is almost always more complicated than anyone expects. It is also the foundation everything else depends on.

The second is a prioritisation driven by operational cost and risk, not by what would look impressive in a programme update or align neatly with vendor capabilities. The processes that currently generate the most manual effort or create the most operational risk are where modernisation will deliver the fastest and most optimized return. That is where to start.

The third is willingness to run old and new systems in parallel during the transition, even though it is expensive. The threshold for switching fully to the new system should be demonstrated performance and operation risk awareness, not project schedule. If the replacement has not yet shown equivalent reliability on the process it is taking over, the answer is usually to keep the old one running until it has.

Frequently Asked Questions

How to modernise legacy systems without disrupting daily operations?

The safest approach is to modernise in phases, not all at once.

Start by understanding how current systems work, including the manual steps teams use to keep things moving. Then, identify the areas that create the most delays or errors and improve those first. During the transition, run the old and new systems side by side. Do not switch fully to the new system only because a date has been set. Move over when the new system has shown that it is reliable. The goal is to build confidence in the new setup before removing the old one.

Why do financial technology modernisation programmes so often fail?

They usually do not fail because the wrong platform was chosen. They often fail because the project is treated only as a technology change. The actual challenging work is about people, processes, and daily operations. Teams need to capture knowledge that is not written down, align teams across operations, compliance, risk, and finance, and manage the transition carefully. The goal should be to keep the business running smoothly, not just to implement the new system quickly.

What is phased modernisation in banking and how does it work?

Phased modernisation means replacing or upgrading technology in sequenced stages rather than all at once. In practice this usually means starting with the integration and workflow layer — the connections between systems — before touching core processing platforms. Each phase should demonstrate operational stability before the next begins, and the sequencing should be driven by where operational risk is highest, not by technical elegance.

How long does a core banking system replacement typically take?

For a mid-sized institution, a full core replacement typically runs between two and five years when managed well. Institutions that have moved faster have generally done so by limiting scope in each phase and maintaining parallel operation throughout. Programmes that try to accelerate by compressing the transition period tend to encounter the operational disruption costs that shorter timelines do not leave room to manage.

What should be in a financial technology modernisation business case?

Beyond the visible costs — licensing, implementation, migration, training — a robust business case should quantify the operational disruption during transition, including temporary efficiency loss and the cost of knowledge capture before cutover. It should also set specific operational success metrics eighteen months post go-live: straight-through processing rates, manual touchpoints per workflow, exception volumes. Without those benchmarks defined in advance, it is very difficult to evaluate whether the modernisation actually achieved what it was supposed to.

Sources: Gartner “IT Modernisation Strategies for Financial Services”; World Economic Forum Financial Services Technology Report; Retail Banking Core Banking Systems — North American Community Bank Edition (September 2024): https://www.celent.com/en/insights/614190165; Core Banking Systems — International Edition: https://www.celent.com/en/insights/989243254;