Platform Consolidation and Data
In one of most recent projects, SEMTEXX team was involved in consolidation of 2 core banking platforms onto single platform after merger of 2 banks. It might sound simple - extract data from one and import data into another. Still you really think it is easy?
Although one might think that you only have to extract information from one platform and import it into another, in reality it's not so straight forward. Why? First of all, systems are completely different although carry the same designation, so is their functionality. You have to take into account how scalable target system is and how much transactions, deals and contracts it is capable to process. Data - starting from different sets of data required by the system to create a customer, open an account for him and create a loan contract up to differences in classifiers AND... DATA QUALITY in a source system.
Sure, before data migration analysis needs to be carried out on what target system supports in terms of functionality and how it will affect customers being migrated. You need to think how to disrupt "business as usual" for customers as well in the process. Target system needs to be adapted in some cases to support some of the functionality from the source system as well, as sometimes this "functionality" is also reflected in customer contract with a bank and cannot be easily made void just because "we decided to move your accounts and contracts on to different platform". This is something customers won't tolerate and leave the bank. In most cases these will be high net worth customers or golden eggs of the bank. Yes, one can decide to provide only functionality of target platform and not to enhance it to support at least some of the functionality of the platform you are leaving behind, but in such case you also need to think on how much customers using source platform will tolerate in terms of service degradation. These are mostly business decisions to be made when planning core platform consolidation.
Another big topic here is data. Sure, one to one migration almost no one expects and it is normally clear that some of the data will need to be transformed in the process so that you can create customer in the target platform, clarify him correctly and open banking products he was using. How to do this? There are many ways to do it, but in my opinion most safe approach is to have transformation process in between extract and load processes thus having an opportunity to see data as it was extracted from the source system, have clear transformation rules and logs on what and how was transformed and this transformed data then loaded into target system without any changes here. In most cases I have seen when this approach was not followed, there have been issues with data and even bigger issues to find root cause of the issue, especially when someone decides to do his own data transformation in Excel as development of proper transformation will "take too long and cost too much" in addition to established extract - transform - load process. This is true not only for consolidation programmes of 2 or more banks, but also to core banking transformation programmes.
Data quality. You might think, that if your source systems works without any hiccups and reporting looks good, you do not have data quality issues. Think again. You have used your core banking platform for years if not for tens of years. You have opened and closed clients, their products opened, closed and again re-opened, linked them, unlinked them etc. Are you really sure everything is fine with data? Are you sure there are no places where references to some long time ago closed clients, their products etc. can be found in your system? Take a serious look at all your data and clean it up before you attempt migration. More you will clean up before data migration, easier and less painful will be data migration itself as well as less chance for some nasty surprises during migration night. Yes, these things would need to be uncovered and fixed during migration testing, but it is not always a case and in practice such things that do not crash something or give evident errors, slip through unnoticed.
What migration strategy to use? Big Bang? Waves? Per product? There is no one fits for all answer and it depends on volumes of data, type of your business and if you are ready to live with 2 parallel systems in the process. Sure you have to keep customer in mind and choose approach that affects him least. Careful analysis before choosing strategy needs to be carried out and risk and benefits of all possible approaches need to be assessed. I have seen all these approaches in life and each of them has its pros and cons and can be used in different situations. Approach I have liked most so far, was to have a small pilot data migration, normally on bank employees, and only then full scale migration affecting customers.
One last point I wanted to note... when planning migration, test well how capable your migration target system will be to handle new data volumes. Sometimes this can ruin all your plans and make your core consolidation a money pit.
