Data Migration Success: Are you and your supplier on the same page?

For many, the conventional wisdom is that if the data has successfully moved from a legacy environment to the target system without failure then the migration is a success.

A lot of suppliers will word their contracts to that effect. They will basically state that their role is to move the data and any defects within the data that were not caused by their transformation process falls under ‘buyer beware’ and it’s the responsibility of the customer to fix.

The problem of course is that the customer is not equipped to fix the data. That is why they asked for supplier support in the first place! Because the customer lacks maturity in data quality and data governance they also have no idea of the scale of poor quality in the legacy data.

I have spoken before of the confusion that occurs when customers discover they have poor quality data in their legacy environment despite the fact their business operations are seemingly unimpaired. The reason for this is often due to a subtle change of use for the data. New pressure is being applied on the data to perform those sexy new functions in the target system.

Data issues are often found during run-time. The need for a pre-migration impact assessment has typically been ignored and perhaps landscape analysis has been skipped through too, just for good measure.

Another problem is that an effective data migration testing strategy has not been employed so the full spectrum of tests has not been employed on all the data, causing even more issues to slip through the net.

The net result is that we end up with a perfect storm.

A lack of direction and rigour from the customer meets head-on with the desire of the supplier who wish only to comply with their contract and side-step the riskier data quality work (unless it’s covered by a clause that leads to unexpected data cleansing at professional day-rates).

How can you prevent this situation from happening?

How can you get customers and suppliers on the same page?

First of all, you need to become a better client. You need to accept that you have duties and responsibilities. You can’t simply shunt all the risk onto the supplier and expect them to clean up your messy data. It’s your mess dear client, so I’m afraid you will also have to deal with it. Get independent expert help to identify and measure the extent of data quality issues. Don’t wait for data quality to magically happen, take steps of your own, before the migration even commences if possible.

Secondly, create a win-win contract. Don’t let critical activities like data quality slip between the cracks into some kind of no-man’s land that no-one wants to own. Don’t assume that the supplier can perform things like testing all on their own. Provide maximum support (and pressure) to get the business fully engaged with that process contractually. I know some suppliers will stress the benefits of their ‘no business required’ approach but that’s a flawed concept, you need plenty of skin in this game.

Finally, create a methodology or framework for the project that clearly outlines everyone’s responsibility. Make sure everyone is aware of the deliverables they are creating on both sides of the fence and the joint accountabilities and resources required to deliver them. Obviously a methodology such as PDMv2 has this built in so make sure your project methodology goes to the same depth.

Most migrations fail because customers and supplier relationships fall apart. Don’t be another statistic, make sure you’re on the same page right from the outset and structure your contract, methodology and deliverables to give that relationship a fighting chance.