Core Banking Migrations: Why Preparation Matters More Than Execution

Roman Eloshvili is the Founder and CEO of XData Group, a B2B software development company with a focus on the European banking sector.

getty​When people talk about core banking migrations, they usually focus on the cutover period itself, when the organization switches between old and new software systems. But in my experience, that’s looking at the wrong part.​

A lot, if not most, failed migrations fail not because something goes wrong during the “go-live” moment, but months before that. By the time the technical migration begins, many of the decisions that determine its success or failure have already been made.​

The biggest misconception about the whole thing is that replacing a core banking system is primarily an IT task. In reality, a core migration changes far more than just the technical side of things. It affects how a bank operates in general, all the way from products and business processes to data ownership and integrations. Operations across the entire organization get affected by this transition.

And that’s precisely why banks should approach this as a business transformation more so than a simple tech replacement. Without this mindset, problems start accumulating from day one.​

The first stage of any migration is discovery—understanding how the bank actually operates before anything is redesigned or moved. Unfortunately, this is also where many projects tend to develop blind spots.​

When banks build inventories of applications, APIs and interfaces, they typically focus on analyzing standard customer journeys: opening an account, making a payment or calculating interest, etc.​

The more difficult scenarios, however, receive much less attention, even though they should receive more. Reversals, overdue loans, account freezes, manual adjustments, operational exceptions, etc.—these are the various edge cases that only appear under specific circumstances. These scenarios are, ironically enough, often the hardest parts of the migration.​

Without understanding complete end-to-end business processes and the full scope of a bank’s operations, it becomes almost impossible to define what the new core should actually own and what should remain in surrounding systems such as CRM, AML or reporting platforms.​

Another problem is that banks frequently assume that their legacy systems are well documented, while in reality, the knowledge behind certain products, calculations or exceptions often exists only in the minds of a handful of specialists who directly worked on them.​

So when those same people are expected to participate in the migration process while also continuing to support the bank’s daily operations at the same time, bottlenecks emerge very quickly. This is precisely why the necessary space to work on the migration needs to be included in the plan from the start to free up people and resources.​

When executives review architecture diagrams on paper, they see dozens or even hundreds of integrations between systems. But the number is much less important than what each of those integrations represents.​

A payment interface, for example, deals with more than just individual payment requests. Behind them are countless other processes, like authorization, reservation of funds, clearing, settlement, reversals, reconciliations and who knows how many possible exceptions. And the goal is to make sure this entire chain of events can continue functioning seamlessly after the migration is complete.​

The same is true for compliance systems. KYC, AML and sanctions platforms are often viewed as separate tools, not directly connected to the core, but these checks affect whether accounts can be opened, who can use which products and whether transactions get approved or if customer accounts get frozen for some reason. If different systems maintain different versions of customer status, inconsistencies quickly spread across the entire banking system.​

Some risks are even harder to identify because they never appear in technical documentation at all. The plain truth is that many banks practice manual reconciliations, workarounds or informal processes that happen simply because experienced employees know how things are supposed to work.​

These “invisible” integrations rarely show up in architecture documentation, but they also have to be accounted for during migration to avoid breakdowns later on. This is why they need to be documented and included in the overall scope of the transition.​

There still exists a very common assumption that data migration is ultimately just copying information from one database into another. Yet, that’s almost never what actually happens.​

Customer information is typically spread across multiple systems, not contained in the legacy core alone. CRM platforms, payment processors, loan management systems, document repositories and sometimes even manually maintained spreadsheets all hold different scraps of this data. So before banks can move any of it, they need to decide which system serves as the source of truth for each type of information.​

Even then, another challenge remains: Individual data fields often make sense only because of legacy calculation rules or undocumented operational logic. Migrating the field without migrating the underlying business logic can fundamentally change how a financial product behaves.​

For such a transition to be considered successful, it’s not enough for the number of records in the new system to match the old one. Customer balances, financial records and products all have to continue working exactly as they did before the migration.​

Successful core banking migrations are defined by how much preparation organizations put in beforehand. Banks that proceed to migrate without first clearly comprehending the scope of their business processes and hidden dependencies greatly increase the risk of many issues surfacing later on and requiring to be fixed.​

The technical migration is just the finish line. Whether you cross it successfully or stumble at the last step is decided long before you get there.​

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?