In my last post, we touched on the importance of data migration in an overall data strategy. The reason I wanted to do this is because so many organizations see the migration of data as a technical challenge that can be outsourced and largely ignored by their internal teams. I contend that organizations have witnessed huge failures with data migration projects in the past, largely because they devolve responsibility and ignore the need for a robust approach.
The last article ended with a promise to examine how a typical data migration can feed into your data strategy. I believe there are several critical areas where data migration supports data strategy.
Data lineage discovery and management
Data migration projects are driven by data lineage. You need to understand fully where your data was created, who created it and what actions are taken – before you can migrate. Once the target system is fully populated and made live, that historical flow of data is so important. And, of course, there are those legacy feeds and data flows that still need to be maintained and monitored.
By adopting a data lineage methodology and associated metadata, you can source your data strategy with highly accurate information on how and where data is being used in your organization.
Data quality rules management
Data migration is predominantly an exercise in data quality discovery, improvement and control. You can’t afford any unplanned defects at run-time. Adopting a comprehensive data quality strategy across the entire project life cycle is critical. For many companies, this is the first time they’ve implemented a correct data quality framework – and, of course, this can feed straight into your data strategy.
Accountability and ownership
In one data migration, I implemented an amnesty on data sources. I allowed all data owners to submit their data sources so we could identify any data sets that were not on the core legacy system. We were suddenly inundated with previously unknown spreadsheets, paper records and Access databases that held far more accurate and complete records than the material master in the core system!
Data migration is an excellent project for uncovering these hidden pockets of ownership that need to be coordinated once the target system goes live. But the plan also demands that you understand the entire data ecosystem and ownership framework of data sources that feed into and out of your legacy and target environments. As a result, it helps you gain a clear understanding of how data should be managed in the future state, adding further value to your data strategy.
Business function and data modeling
A best-practice approach to data migration depends on modeling the as-is and to-be functions and data models.
This modeling exercise is critical because it helps you spot glaring issues right from the outset – just by modeling how the business currently executes tasks and stores information. But the benefits don’t end there. Once your different environments are modeled, you can feed this information directly into your data strategy. At this point, you will have a much clearer view – not only of what the business leadership thinks its strategy is, but how well that strategy is being executed on the ground.
For example, in one telecommunications firm, the data strategy was to support the very latest transmission equipment. But it was clear from our data quality assessment during the migration that this simply wasn’t happening. The data strategy was then updated to ensure that much tighter accountability, ownership and data quality monitoring were in place.
These are just some of the ways data migration can support your data strategy, and I hope they gave you food for thought. If you have any questions, please post in the comments below.
