Data Migration Component 2: Managing Your Data Chains

Continuing with my series of posts on various aspects of Data Migration, this week’s blog will focus on Managing the Data Chain.

For our purposes, a ‘Data Chain’ is defined as all the pieces of data that are linked together in a business process. (i.e. Purchase Order > Goods Receipt > Invoice Receipt > Payment) It is tremendously important to consider Data Chains during any Data Migration exercise, as failing to consider how you will manage all the ‘links’ in a particular chain could have disastrous impacts on your project. Furthermore, what begins as a simple choice can become very complicated very quickly.

To clarify, let’s continue with the example of ‘Purchase Order > Goods Receipt > Invoice Receipt > Payment’. You may have made the seemingly logical decision to move all your Open Invoices to your new system.  However, this will then beg answers to several more questions:

1. If you move the Open Invoices, do you also move the Goods Receipts associated with those Invoices?
2. If you move the Goods Receipts and Invoices, do you also move the associated POs?
3. Regarding the POs, do you only move the Open POs, or do you migrate all the POs, including those that have been fully received? (Keep in mind that just because the PO has been fully received doesn’t mean that all the components of the data chain have been concluded. (i.e. the invoice may not have been received and/or paid.)

Each data chain that you consider will have a similar set of questions to be answered, which means there is quite a bit of investigation and planning required before you start the actual hands-on work.

ALTERNATIVES TO MIGRATION

It may be that you decide that you do not want to migrate all the data associated with a particular data chain to your new system. In this case, there are two fairly common alternatives to migrating all the elements in the chain:

1. Operate in Two Environments: You may decide it’s easier/less risky to conclude the open transactions in your ‘legacy’ system. To continue with the example above, let’s assume you have a situation where you have fully received all the lines on a PO. The remaining links in that data chain would be to receive and pay the invoice. If you went down the ‘two environments’ path, you would complete these operations in your legacy system. Therefore, you would create only ‘new’ POs in your new system and would not have to migrate any of the legacy data in that data chain.
   1. Obviously, this approach will add a level of organizational complexity, in that you have to manage two systems for a perhaps indeterminate period of time. This will not only place more stress on your human resources but will also push out the time it will take to realize savings from demising your legacy system.
2. Deliberately Break the Chain: You may make a decision that the most effective way to manage your Data Migration is to deliberately ‘break’ one or more of your data chains. This would mean that some of the ‘links’ in the chain would remain in the legacy system, and some of the data would be moved to your new system. (i.e. you leave the POs and associated Goods Receipts in your legacy system, and you move all the associated Invoices to your new system. In the case where the Invoices have not yet been received, you would create them ‘manually’ in your new system once they are received.)
   1. The complication with this approach is that you would need to find a way to manually create a link between the documents in your legacy system and the related documents in the new system. For instance, to continue with our example of the PO data chain, if you have left the POs behind, and wanted to create the Goods Receipts manually in your new system, you could designate a field in your Goods Receipt document to house the legacy PO number. This would allow the PO to be cross-referenced (and manually updated) as the various transactions which affected it took place.
   2. Obviously, this approach brings with it some organizational overhead, as the data entry person would need to enter the document in the new system, and then move to the legacy system to perform updates on any of the related documents.

SUMMARY

Regardless of how you choose to deal with your ‘Data Chains’, it’s critical that you take the time to identify them, and decide how you will manage them well in advance of the actual execution. This is NOT the kind of thing you want to deal with ‘on the fly’!