The 0.1% Success Rate: Why Core System Migrations Fail

When banks want to merge two core systems, the boardroom sees results and simplicity. The IT department sees a nightmare. The goal is always to move everything, including loans, deposits, and customer history, into a single "target" system. Yet, these projects are notoriously expensive, high-stress, and prone to catastrophic delays.

If we want to understand why these migrations fail, we have to look past the technical glitches and examine the flawed theory of change that most banks are still following.

‍

The Problem: The "Big Bang" Fallacy and the Complexity Trap

The traditional approach to a merger migration is the "Big Bang". The plan is to map every data field from Core System A to Core System B and switch everything over during a single long weekend.

And then repeat that for each and every core.

This fails for three primary reasons:

1. The Aging Architecture

Universal banks typically operate on systems that have been in place for decades. When you attempt to migrate data out of a thirty year old system, you aren't just moving numbers; you are moving decades of "spaghetti" code, hard-coded workarounds, and undocumented logic. And this logic is different in every bank.

2. The Data Integrity Gap

Data in Core A never perfectly matches Core B. A loan in one system has different metadata, interest calculation methods, and rules than a loan in another. Mapping these differences is a monumental task. When you try to force-fit millions of complex records into a new core all at once, the sheer volume of "exceptions" breaks the migration engine.

3. The Push for Business Agility

While the IT team is drowning in data mapping, the business side cannot stop. They need to launch new products to keep the merged entity competitive. This creates a "moving target" problem. You are trying to migrate a system that is simultaneously being modified to meet market demands. The result is a cycle of testing that never ends because the baseline is constantly shifting.

The Solution: Slicing the Elephant

After a decade of watching these projects fail or succeed only through "heroic" overtime, I realized we need a different theory. We cannot keep treating a merger as a single, massive data event. We have to slice the replacement into multiple pieces.

The solution is Progressive Decoupling. Instead of moving the entire core at once, we must identify the business functions that are the most complex or the most vital for day-to-day agility and decouple them first. We create a layer that sits above both the legacy system and the target system.

‍

How It Works: Reducing the "Push for Change"

To make a migration successful, you must stabilize the environment. Here is the framework for a decoupled migration strategy:

Phase 1: Carve Out the Agility Layers

Identify the things that change most often, such as pricing rules, and decouple them from the legacy core through microservices. These microservices need to be able to talk to both core systems at once: there needs to be clear parameterization of data, and flexibility in naming conventions for this to work.

Phase 2: Parallel Connectivity

A decoupled architecture allows the bank to run both systems in parallel without the customer noticing. The new microservices pull data from the old system and the new system simultaneously. This removes the "all-or-nothing" risk of the long-weekend switchover. You can migrate customers in batches, perhaps starting with savings accounts before moving to complex corporate loans, without breaking the bank’s ability to operate.

Phase 3: Extending the Life of the Legacy

One of the hidden benefits of this approach is that it reduces the push for change on the existing legacy system. Because new products and bundles are being created in the decoupled layer, there is no longer any need to add additional complexity to core systems through custom development. This both lowers the risk of a system crash during the most sensitive phases of the merger and allows the core to focus on what it does best: working as a ledger.

‍

The Future of the Universal Bank

The era of the monolithic core banking system is ending. It is simply too risky and too slow for the modern world. Universal banks will eventually become an ecosystem of microservices, where the core acts as a ledger and decoupled microservices handle the complex operations, rules, and calculations.

We need an architecture that allows for failure, allows for testing in production, and, most importantly, allows the business to keep moving while the IT team does its work.

A successful migration isn't one where everything moves at once. It’s one where the move is so gradual and so well-architected that the business hardly realizes it’s happening. That is the only way to escape the complexity trap.