In our previous migration blogs here and here, we looked at the different factors to consider when initiating a DM9 migration plan.
Whether running automated or manual procedures, and regardless of whatever form the migration approach might be in e.g. Big bang, Phased etc; it is vital to have excellent management on migration controls, approaches to execution, testing and reconciliation.
In this blog, we will delve into some additional factors to look out for when beginning a migration phase as well as some valuable lessons that Arum have learned from our experiences with DM9 migration projects.
- What kind of data is being migrated? Most data entities fall under the categories of customer/account data like collection/recovery status and related information (e.g. active third parties assigned) and security, plans, transactions, diary/historic events. Therefore, it is beneficial to think about structuring the data mapping design for each entity iteratively. This will provide more concentrated time on certain aspects of the migration process which may have been rushed when trying to arrange the mapping all in one.
- What tools are available to construct the desired migration on DM9? Most migration structures we have supported utilise configuration such as reference tables and UDPs. The reference tables can be customised to present the migrated data and how it should be mapped into DM9, whether through UDP fields or core customer/account data. It provides a very convenient method to display the information being transferred and enables easier modifications.
On the other hand, since a recent upgrade to DM9 there has been the introduction of a new functionality known as CDL/BDL (configuration/bulk data loader), which transfers constructed data from one DM9 source environment into another target environment (e.g. from a design – testing or testing – production phase). The CDL provides the opportunity to send over configuration iteratively and on any scale, meaning large project lifecycles can focus on one element of their migration process at a time. For instance, migration of customer data can be designed, mapped and tested separately before account data (though consideration needs to be given where data items from different entities can affect each other e.g. an account data item affecting a value in a customer data item).
- What is your testing approach? Having a clear understanding of the testing approach ensures system errors can be identified early, and provides higher confidence levels for producing an efficient migration. It is important to know the components that are affected by migration during testing. Running the migration tool to ensure it performs correctly or verifying the correct values are appearing in the fields as expected are obvious checks to execute, but you should also consider other external factors that might have been impacted and so running a few normal BAU batches alongside the migration suite will prove beneficial.
- What are some of the common migration issues which increase time and complexity of a project that you need to be prepared for?
- Documentation that is not up-to-date, is inaccurate or poorly managed – if a centralised and maintained area for documenting all configuration mapping is established from day one, this will help other parts of the project run smoothly.
- Non-standard legacy system usage for example; a process or strategy (maybe even an action note in terms of DM6) that will not be required for DM9 (non-standard), but figuring out what we do in migration for accounts in those positions.
- Optimising strategies during migration (rather than at the outset of the project).
- Lack of migration and migration control planning – housekeeping (data validation / cleansing).
- Operational readiness – knowledge and understanding of the implications of the migration execution should be distributed to business operations. If this is not addressed, this can lead to longer timeframes to ensure all participants are prepared for the crucial phases of the migration process.
- State to State (S2S) – not just mapping old system status or position to new. Consideration needs to be given to setting any other relevant data items so that the customer / account looks as if it has always been in the new system and has the right settings to successfully continue on the correct path.
Our involvement in migration projects has seen many clients successfully improve their performance in CnR whether reducing costs in operations, increasing customer satisfaction or complying with regulations, so if you’d like our help please get in touch.
Ola Akanni & Jake McCracken – Senior Analysts