The question I have is where to start? There has been a lot on the web recently about testing Data Migration projects. How do you test to know, not just that the migration will work in a technical sense, but that after it has run, the data we put in front of our business colleagues will not break the business?
As those of you who follow this blog regularly will be aware, I have highlighted a number of migrations in the past that appeared to work technically but which, once the back slapping of the cutover day plus one has ended, gradually (or not so gradually) dragged the company downwards. On the other hand I have also reported on a number of Data Migrations that have been a success. The data has moved over smoothly and with a controlled and predicted size of fallout within the threshold for success followed by a rapid ramp up to full benefits realisation. (Have a look at the first blog of this year for an example).
So what makes for success and what makes for failure? How much is testing to blame and, if all migrations are tested why do they still frequently fail? Are we getting our testing right and what could we improve?
On the other hand I could have a look at Data Migration governance - what should you have in place from the very start of your migration that means you will have a controlled flight path to a successful conclusion? Why do some migration projects spiral out of control whilst others run to time and budget?
Or again, we could look at our relationships with third parties. Most Data Migrations these days have at least one and often more than one third party involved. There is the software supplier and the systems integrator. There are hardware vendors, there may be specialist Data Migration consultants (like me) and data quality consultants. How do we structure relationships so that we are all winners? How are these relationships best represented in the contracts we sign? What are the contractual pitfalls we should be aware of?
Perhaps you would prefer something more technical? A briefing on the best practice use of profiling tools maybe or how to tune a Data Migration to optimise throughput perhaps?
Whatever you would prefer, please use the comments box or, for the more discrete, please use the email contact details below to let me know. Next week I will be introducing you to more of the sponsors and speakers for Data Migration Matters 5.
About the author
John Morris has over 20 years experience in IT as a programmer, business analyst, project manager and data architect. He has spent the last 10 years working exclusively on data migration and system integration projects. John is the author of Practical Data Migration.