One of the big problems with data migration projects is that, to the outside sponsor, they appear very much like a black box.

You may be told that lots of activities and hustle are taking place, but there isn’t a great deal to show for it until the final make-or-break migration execution when the data finally moves across to the target environment.

The problem is made worse to an extent by the fact that, as data migration practitioners, we openly demand that data migration initiatives are delivered as a separate team, budget and working environment. This often cuts us off slightly from the main system implementation project.

Sponsors need to see tangible results, particularly on large-scale migrations that can take many months or even years. They need to report to their peers and seniors about the state of the migration and how it will (or won’t) be dovetailing into the target implementation.

So how can you show progress when you can’t physically migrate the data until the final go-live migration date?

One way is to change the actual strategy of your migration and opt for a more agile, iterative approach. Instead of migrating data across in one single 365-day drop, create multiple drops of, say, 90 days where you are moving tangible portions of data. This could be by region, data subject area, customer type – anything that is relevant to the migration. Another tactic I’ve used in the past is to just migrate the "backbone of the data," the primary and foreign keys, for example. The reason for this is that if you hit problems with these, then you find out much earlier in the lifecycle.

In past migrations I have migrated these limited datasets early to test target functionality and iron out any transformation or load issues.

Another way to show demonstrable results is through data quality improvement and, in particular, data visualisation of progress.

In one project we first discovered the data quality rules, measured the data for defects and then colour coded all the hotspots on a huge tile chart, which was split by different dimensions (e.g. data quality dimension, business unit, customer type, etc.). We had a large monitor in the migration "command center" and gave sponsors access via a dashboard, too. They were able to see the progress over time as each tile switched from red to green.

You can use the same process for completing mappings, subject areas or any set of activities that gradually get whittled away during the migration.

In short, you can never communicate too much progress on your migration, and your sponsors will be eternally grateful as their anxiety levels come down. What’s more, you’ll create a more structured and successful project.

What do you think? How do you communicate on a data migration project? Do you have examples to share? Please share your views in the comments below.