Data migration can be a key component of data integration, and so, it's among the topics I watch. To be honest, most of what I find focuses on technical issues that are better left to the data warehousing team.
But every now and then, I find a piece that IT and business leaders would benefit from reading, such as a recent article published on Data Migration Pro titled, "How to Implement an Effective Data Migration Testing Strategy."
I know-it does sound technical, and to a certain extent, it is about tactical issues of testing. But it also includes a more strategical discussion of the business risks associated with data and content migrations, and how IT-by working with business users-can mitigate those risks.
The piece is written by David Katzoff, managing director of Valiance Partners, which provides services for data migration, as well as selling a data-migration technology. So, to some extent, the piece is promoting the use of automatic migration testing. But, as the article points out, Valiance has tested hundreds of data and content migrations, most in FDA-regulated industries, and so, despite the subtle sales pitch, Katzoff brings a lot of experience to the discussion.
He suggests companies design a migration testing strategy, and to begin, you should evaluate the risks of the migration and the likelihood that they will happen. He points out that, when it comes to implementations of information systems, most businesses are adept at evaluating the risk and compliance issues-and yet, oddly, companies neglect this step when it comes to migrating the data or content held in these systems:
... many of these information systems will be populated with legacy data, and the compliance and business risks associated with data and content migrations are not necessarily understood. In this context, risks associated with data migration are a direct result of migration error. Further, industry testing strategies to mitigate such risk, or more specifically data migration error, lack consistency and are far from deterministic.
Evaluating the risk is the first step in identifying what you need to test. Even though most organizations use only sampling to test the migration, Katzoff points out there are other tests you can conduct before the migration, during the formal design review and after the migration. He suggests you include users and management even during the formal design review step.
He also recommends user acceptance testing and testing during production-which, he argues, is where automated tools really come in handy.
At the end of the article, he offers a 10-step checklist for designing a data-migration strategy. If you do nothing else, you can scan the list and get a quick idea of how and why data-migration testing should be on your radar, rather than just a technical to-do.
You'll also find a list of related resources at the end of the article, including a data-migration checklist template and six tips for "selling" a best-practice data migration.
If Katzoff's piece piques your interest, you might also want to check out this oldie, but goodie, post by IT Business Edge's Arthur Cole, "Walking Through a Data Migration."