Last week, I started a series on the data conversion cycle.  This week, I’ll explain what you should consider in defining the scope of data conversion, when replacing a production transaction processing system with a new one.

The first step is to identify all sources of data to be loaded.  I know this seems obvious, but on one project last year, we incorporated data from two different systems, moved to production at different points in time.  What made the situation even more complicated was that the second system was “owned” by an external service provider, whose services were to be eliminated.  And the records in the two systems were out of synch, because there was no automated interface; all entries were manual.  Consequently, we had to help the users to identify the differences between the two systems of record so they could make correcting entries before we could begin conversion.  Yes, it was a change in scope, and we documented it as such.

Next, you need to determine what records are in scope for loading into the new system.  It is a leading practice to only load “current” records into a new system, with “historical” records stored off-line.  However, the definition of “current” records needs to be made clear.  On more than one occasion, I’ve seen a project start in one calendar year and go into production in the following year.  In such circumstances, we typically say that records effective in the year in which the new system goes live are “current,” even if we conducted our tests with records from the prior year.  You also need to ensure that it’s clear whether disposition of the records not being converted are the responsibility of the project, and whether decommissioning the legacy system is in scope.

Finally, ensure you have agreement on the number of conversion cycles.  Let’s say you are using an iterative prototyping methodology.  You might plan your conversions like this:

• Straw Man – minimal number of record types and records converted, just enough to facilitate design conversations.  Be specific on record types and the criteria for selecting what records will be provided.
• Wooden Man – 80% of data record types converted (specified in a detailed list), to support unit testing and validate the design.  Record types not converted will be created manually, if needed.  If not all current records are required, specify selection criteria.
• Iron Man – all current records of all record types converted, to support end to end / system testing and acceptance testing.
• Move to production – 100% of current production records, extracted at a single point in time just before the move.

Of course, your methodology might be more or less complicated than this, but the basics will apply for all projects with conversion in scope.  However, if you have seen some additional wrinkles, please leave a comment below.  Next week, I’ll address mapping the legacy system data records to the replacement system.