In part 1 we covered some overall observations with regards to Migration approaches to DM9 and then looked at some particular points with regards to an automated approach.
Part 2 will look at some of the considerations to bear in mind with a more manual approach to migration.
As Part 1 observed, migrations come in all shapes and sizes. A manual migration could simply be the creation of the entire Customer and Account structure along with all required data items and history manually on DM9. However this is unlikely to be a common occurrence and may really only be applicable for small volumes in the recovery space where DM9 is the system of record.
A slightly more likely scenario is where the Customer and Account structure is created on DM9 using the existing inbound interfaces and the required CnR specific data items and history manually layered on top. In some respects this is a hybrid approach. As the design of the inbound interface itself would have a bearing on the viability of this option, this is a situation where the migration approach might have a bearing. However as migrations tend to be a one off/single use event, it should not necessarily dictate the design of the inbound interface.
There are a couple of further observations to keep in mind with manual migrations.
The first is the need to understand the data structure of the legacy CnR system(s) being migrated from. Do they work at the Customer or the Account level and how does this compare with the DM9 design? If there is an incompatibility, then some analysis is required with regards the data items and history to be manually migrated. An example may help to illustrate this point. Let’s say the DM9 design was Customer centric but the legacy CnR system was Account and that Customers might have more than one Account. If these Accounts each had a payment plan but on DM9 they can only have one (at the Customer level), then some sort of amalgamation might be required and potentially customer contact (It is worth also noting that this could apply with automated migrations).
The second observation is with regards DM9 itself. Not all DM9 screen fields are editable. With version 9.5.1, this was specifically the case with Tag Assignment dates and Date into DM9. In these instances, it is possible to devise a solution which works off of specific UDP fields which are read by a regularly executed script which reads the specific UDP fields and populates the relevant data items accordingly. Should any client require a solution for this scenario, they should in the first instance start a conversation with FICO.
An additional point to note for migrations whether manual or automatic is with regards to the State to State mapping which was touched upon in Part 1. When looking to ensure that Customers and/or Accounts migrate to the similar strategy point, one further consideration to take into account is that any regulatory, compliance or policy requirements continue to be seamlessly met between leaving the old world and arriving in the new.
This and the previous related piece merely offer some thoughts on what can be a complicated and challenging subject. Bringing experience into a CnR project with a migration dimension can reap significant rewards.
Michael Haskell, Lead Consultant