This post was extensively updated and incorporated into my new book, The Data Conversion Cycle: A guide to migrating transactions and other records for system implementation teams. Now available on Amazon.com in both Kindle format for $4.49 and paperback for $6.99.
Continuing the series on the data conversion cycle. I’ve been describing a generalized methodology for migrating data records from a legacy system to some new system of record. However, this methodology needs to mesh with the rest of the project. In this installment, I’ll identify considerations for both managing the iterative conversion process and integrating the data conversion plan into the larger implementation project plan.
First, it is important to clearly identify the number of iterations of the data conversion cycle that will be required for the project, based on use cases. Typically, one or more environments are built for development; there may also be a limited-scope environment built to support a design workshop. You will also need one or more environments built for testing. Of course, you’ll need to convert one final time, in order to move to production. Each of these use cases will require delivery on a particular date, so you’ll need to plan your way back from delivery of the build to the extraction of data from the source system. Note all dependencies and entry and exit criteria for each iteration of the cycle, and incorporate these links into the larger project plan.
Next, consider the needs of each user group. Will they require a full data load? Or will a sub-set be good enough? There’s no point in loading records that won’t be used. Also, especially in the first one or two cycles, you may not have all of the design and scope decisions in place, so have metrics for completeness and quality that can communicate what will be delivered. In our Workday implementation projects, we typically expect to load 80% of the record types in the first full prototype, and over 95% in the second prototype. But for the integrations developers, we usually just provide enough transactions to facilitate development and unit testing. Know what records are actually needed, so you don’t spend more time on a build than you really need. And know what quality level is required, so you don’t waste time “in pursuit of an unappreciated perfection.”
Finally, consider the availability of resources. Few projects have enough of the right people assigned to do every task in exactly the right time frame. If you have people working on conversion as well as other related project tasks, consider making adjustments to the schedule to keep conversion in synch with the other activities. There’s no point in delivering a build and then waiting two weeks for the team to catch up. And if you’re going to need additional folks at some point, know about it in advance.
Each iteration of the data conversion cycle should both improve the quality of the data in the build and reduce the time required in order to complete the build. As part of your conversion plan, establish metrics and procedures for collecting them. Your goal should be to have the conversion process completely known and predictable by the time you are ready to make the final build for the move to production. Next week, I’ll outline a risk taxonomy for data conversion, to help you identify risks specific to your conversion.