Some years ago, I took part in a project that was introduced to me as a heart transplant for a bank. Another memorable comparison was calling it a Cadillac. I’m not particularly knowledgeable about cars, but a Cadillac makes me think of something impressive, something I’d definitely want to be part of. As a closing remark, I was told that it would be the most challenging project of my career.
The project in question involved replacing a bank’s entire core banking system with a new one. The scope of the replacement covered practically all subsystems, such as lending and deposit systems, client information, payment systems, collateral systems, and online banking. Over the course of my career, I’ve had the chance to join several challenging projects, and in my experience, system replacements are among the most difficult things a bank has to undertake as an organization.
The difficulty doesn’t stem only from the technical nature of the project, but also from the system replacement directly affecting all of a bank’s day-to-day operations regardless of business area, from processes to ways of working together. It is therefore a systemic and technical business problem where technology, people, the organization, and the business are tightly woven together.
Because system replacements are broad and complex by nature, I will narrow my focus to the area I know best, the migration project. Migration refers to transferring an organization’s information systems, data or applications from one environment to another. In my experience, it often involves data and application transfers, adapting users and processes to the new environment, and functional specification work.
So far, I have participated in four different migration projects in which my role has been technical. My responsibilities have included data transfer, data migration, and testing these transfers between the old and the new systems. Next, I will walk through the stages of core banking system testing, my experiences from these projects, and the lessons learned along the way.
Migration’s role and impact in an operational system replacement project
In my experience, migration is often seen as a late-stage task in a system replacement project. Typically, functional changes to systems and business processes are defined first, followed by integration testing in the new system using test data. Finally, the migration project is set into motion with the goal of deploying the new system into production.
In practice, however, the different phases contain many interdependencies that make progress much more complex than it first appears. A plan that looks linear on paper can quickly become nonlinear when functional gaps surface during migration, which based on analysis must be resolved on the functional side of the system.
Migration therefore plays a central role, as it forms the concrete link between the old and new system environments through the data being transferred. The success of the migration directly affects how smoothly the new systems can be deployed and how the business continues after go live. For this reason, migration-related risks and findings can significantly alter the trajectory and schedule of the entire project.
Migration testing
Migration testing is an essential part of a migration project and based on my experience, testing can take place at least on the following levels:
- User interface testing
- Reconciliation with accounting
- General migration testing
- Data validation
User interface testing
Every project I’ve been part of has included user interface testing. This phase is often performed manually by a bank’s experts during the project, because it is an intuitive way to become familiar with the new system. By exploring the user interfaces, the migration project quickly learns about existing and potentially changing business processes as well as operational data flows. It’s therefore natural to verify that information in the new interface is accurate and placed logically.
However, user interface testing has limitations, and its main challenge is usually its narrow scope. It’s not possible to go through the entire dataset, so testing usually focuses on a few simple cases and some of the most challenging ones. These test cases can certainly be generalized, which increases coverage beyond the number of tests. This makes it quick and easy to confirm that something works or to identify any issues or logical inconsistencies.
That said, this should not be the only way to verify data accuracy. This brings us to the next level of testing.
Reconciliation with accounting
Anyone working in the field has likely heard these rules:
- Accounting is always correct.
- If accounting appears to be incorrect, return to rule 1.
It’s therefore natural that every project checks what the results look like from an accounting perspective. When done correctly, accounting checks can reveal conceptual or definitional differences in calculated fields, such as accrued interest. Although accounting is an extremely important part of reporting for companies, and in this case for banks, it is still relatively narrow. For example, it doesn’t address links between contracts or ownership structures. The amount of data needed for accounting is also fairly small. Therefore, reconciliation with accounting is a useful acceptance criterion for a migration project, but it’s not enough on its own.
General migration testing
By this I mean the reporting usually produced by the party responsible for the migration, which in my experience is typically the provider of the new core banking system. Testing performed by the vendor is generally technical in nature and doesn’t dive into business level questions, because the vendor doesn’t have the time to fully familiarize themselves with the specifics of the current system.
As a result, this testing often focuses on the number of rows in the source and target systems. For example, it verifies that the correct number of contracts or customers has been transferred. It rarely examines the content of individual fields, nor does it typically verify whether links between different areas are correct. For this reason, general migration testing is only the starting point for more detailed validations, which are needed to confirm data accuracy and ensure that business processes will function correctly.
Toward broader data validation
Up to this point, I have covered the most common methods to test data during migrations. These methods form the absolute minimum level of testing in any system change. They are also common enough that extensive material exists about them from many sources. In my experience, data validation is a less commonly used method in the industry, and it is not an automatic practice in banking system replacements.
The topic is complex enough that describing it in the way I’d like would expand this article too much. I’ll cover it in a separate article, where I’ll explain the concept in more detail.
Q&A summary
What is a core banking system migration?
A core banking system migration refers to transferring an organization’s information systems, data, or applications from one environment to another. It often also involves adapting users and processes to the new environment as well as functional specification work.
What makes a core banking system replacement challenging?
Replacing a core banking system directly affects a bank’s day‑to‑day operations across business areas. The change is not only technical but also impacts processes, collaboration, and ways of working. It is a systemic and technical transformation in which technology, people, the organization, and the business are tightly woven together.
What role does migration play in a system replacement project?
Migration forms a concrete link between the old and new system environments through the data being transferred. Its success determines how smoothly the new system can be deployed and how the business continues after go live.
How is migration tested?
Migration can be tested in several ways, the most common being user interface testing, reconciliation with accounting, general migration testing, and data validation.
