Skip to content

Data Migrations - To Migrate Or Not to Migrate, That is the Question

Eoghan Kelly, Technical Consultant, FINEOS

Recently I was asked for my opinion on Data Migration or better known on projects as ‘Data Conversion’. Having worked on migrations for approximately twelve years, I will try and share the best kept secrets to a successful migration. The goal is to keep the following information on data migration generic, as you’ll see I’ve broken this into 4 parts. This is to allow migrators of all types to follow along, This should not only be used on FINEOS implementations, but any implementation that involves a data migration.

 

Part 1 – Materials:

Two artifacts jump out as being important documents on any data migration.

  • A Requirements Traceability Matrix (RTM) that is shared with your client. This provides a data mapping of legacy data requirements to the target data structure.
  • Having a specific written and agreed set of success criteria gives great clarity to any data migration. What is the migration strategy? What is the absolutely critical data that is needed for migration? What is the exit criteria?

Part 2 – What to do:

The FINEOS strategy is to provide data model support to the client, while the client uses their enterprise tool such as Informatica, DataStage, etc.. to perform the migration. The following steps should then be taken.

  • Access the FINEOS Documentation website provides valuable information to people needing to learn the FINEOS data model.
  • Secure a sandpit or test environment to input data and see where it persists in the data model. This is something I would strongly emphasize.
    • The sandpit allows the client migration team to begin to understand and learn the application and what they will be migrating into. This will greatly help the overall data migration project.
  • Be aware of possible changes that could be made to the target data model, as the project moves through different base product or custom versions. Make sure your RTM is updated to reflect the changes.
    • This will help keep the vendor and the client all singing from the same hymn-sheet. Repeat after me kum-bah – yah!!
  • Ensure that complex data migration scenarios are collated. Otherwise a lot of valuable time can be lost.

Part 3 – What not to do:

  • Go on solo runs with complex business scenarios.
  • Not reaching out to business experts with questions and to test your understanding.
  • Ensure you don’t run your migration on less than optimally tuned servers. If not valuable time could be spent trying to optimize code (aka migration routines) that don’t need to be optimized.
  • Don’t underestimate the effort of your data migration!

Part 4 – Desired strategies:

  • Conduct regular migration workshops in order to roll out the migration piece by piece.
  • I would suggest always having at least a second person from the vendor at every workshop possible. They helps with capturing questions, taking notes and detailing assumptions.
  • Have people who understand the source database that you are migrating from present in the workshops. They are the real brains behind the data being migrating, not the techies.

Now after reading this blog, what’s holding you back from your next successful data migration project!