Search
Close this search box.

Enterprise Migration Risks: Core Banking Application

One of the hardest moments for a Managing Director of a Bank is overseeing the migration from one Core Banking Application (CBA) to another. Take an example of Centenary Bank that months bank migrated from ‘Profits’ to ‘Oracle Flexcube’. Apart from Flexcube, Finacle is one of the popular CBAs.

Yet, a migration from one CBA to another is never smooth. The biggest mishap during these migrations is data loss and inability to perform functions in a new CBA. CBA migrations can bring banking operations to a standstill.

Imagine waking up and the bank is unable to process loans? Imagine coming to a standstill with card issuance? Yet, although many would wish to avoid migrations, often, it’s a must-do. As technology advances, most financial institutions find that to be competitive, they must move from legacy systems to new systems. Some banks have in-house enterprise software developments and soon realize that it’s best to outsource to more reliable partners rather than having the CBA development and maintenance in-house.

But why should one migrate their system?

First, it’s about support. The old system could be lacking support. Victor Asemota talks about Support Latency. “The simple answer is latency. Support latency. Too many ad-hoc modifications and the simple age of the underlying tech may also cause technology latency and technical debt. A lot of their people leave, and they likely move to a platform that has more local support and vendor experience with our regulatory peculiarities.

The other rationale for moving is simply because the new system is better and advanced and plugs all the different holes that were experienced with the old system. Migration always boils down to better functionality, scalability and cost advantages. Basically banks look to get more for less.

However, this movement is never smooth.

First, because systems are always coded in different programming languages. Data formats in systems are always different. This is the biggest process as one cleans and processes data into the format of the new system. Employees are also generally resistant to change. Sometimes banks will run parallel systems for a given period to enable employees shift to the new system. But often, as long as the old system exists, employees will just ignore the new system, thus the need for pulling the plug on the old system. And keeping two parallel systems would mean paying costs for two systems, thus an undesirable scenario.

But in the end, a smooth migration comes down to having a skilled team that’s experienced. When things go wrong, it’s often because of inexperience. Not knowing about the need to properly map the data, deal with differences in the data. An experienced and skilled team won’t take the database integration challenge for granted, it will anticipate and plan ahead.