It is easy to consider data migration as a movement problem. After all, we need to get our data from A to B with as little effort and cost as possible. With this viewpoint, many practitioners commence mapping and linking the source and target systems together to form an elaborate web of information chains.
This "movement focus" approach to data migration has prevailed for many years but often at the cost of poor quality of data that is unfit for the purpose of both migration and subsequent target functionality.
Many people will say they are "doing data quality" because they’ve got some data profiling, cleansing and testing phases clearly marked on their project plan. However, their overall migration strategy is still "movement oriented." Profiling and cleansing are secondary tasks that are bit-part players to the main mapping exercise.
I contest that data migration is not just a process of movement, but in fact a lesson in understanding.
You need to understand:
- How are we really using data in our legacy landscape?
- What business functions does our data serve and how will these functions change in the target?
- What quality of data do we have in our legacy data?
- How will our legacy data quality impact our target functions?
- What are the gaps between source and target data requirements/functionality requirements and how will this impact the migration?
This list barely scratches the surface of what we need to understand in a migration. It is no surprise that my favourite toolkit for a data migration includes a capable data quality management suite and a data discovery tool. Read More