Financial institutions have vast stores of data about their customers. As systems become outdated, needs evolve, and/or regulations change, banks often have to move this critical data from one system to another. In fact, data has to be migrated any time a bank installs a new server or software platform. To avoid losing critical data or hampering access to it, banks need to have a strategy and plan in place before starting the migration process.
Lessons learned from other FIs
Experience has taught us that online banking migrations should never be rushed; careful planning and a reasonable timeline are essential to success. In today’s rush-to-market culture, some financial institutions have made the mistake of setting end dates too early. The best approach is to stick to a rigid process while keeping delivery dates flexible.
Another lesson learned from past migration projects is that fully dedicated teams on both sides of the migration—the old system and the new—are crucial. Having two dedicated teams helps to ensure a positive experience.
Initial steps to take
As accounts and users are removed, obsolete or extraneous data such as payment templates, payees, and beneficiaries can accumulate in a customer database. One of the first essential steps in preparing for an online migration, then, is data clean-up—deleting or correcting stale, inactive, or “orphaned” data. This exercise prevents bad data from being loaded into the new platform.
Another step to take before migrating data is “data transformation”—the validation and transformation of data into the proper formats and values required by the new platform. The receiving platform’s vendor typically performs this task, which should be completed before creating the data-extraction files. That way, error handling is isolated to the receiving platform side.
Data must be validated, too, through repeated testing to ensure that moving the data to the new platform triggers the expected response. Data validation also identifies any corrupted data.
Things to consider
Banks have several questions to consider when planning their online banking migration. One decision to make is whether to migrate pending payments. Based on experience, Xtensifi usually recommends setting payments up fresh on the new platform. Since all templates, payees, and beneficiaries will be migrated, customers can best leverage the new platform’s power and flexibility by setting up their payments directly on the new system.
Banks must also decide whether to allow dual access, and even if that’s allowed under your contract with the existing provider—i.e., allowing customers to access both the new and old platforms for a period of time before and after the migration. Providing dual access requires careful planning and execution. In most cases, Xtensifi does not recommend allowing customers to view or modify their data on the old platform once it has been extracted. If dual access is permitted, some deltas may not be applied to the new platform; duplicate payments could be mistakenly generated from both platforms; and/or customers might resist learning how to use the new platform.
One more decision to make is whether to migrate customers all at once in a “big bang” or to migrate them in pre-determined phases. Either approach is valid; a phased approach enables the bank to fix any bugs that emerge before the next phase rolls out, while a big bang allows the bank to avoid having to maintain two platforms.
No small task
Customer data is one of the financial institutions’ most valuable assets, so migrating it should never be taken lightly. But with careful planning and decision-making, and flexible delivery dates, an online migration can be executed smoothly, without major challenges.