Data Migration Testing Project - The Key Things to Consider

The exact type of testing and how the testing is performed will depend on your particular project and environment, but generally you need to make sure the following is done.

1. Data Quality Testing/Checking

This is where the records on the target system are checked for accuracy against the legacy data. There are various methods of doing this. On a recent project we created checklists for the testers to follow. These were in the form of spreadsheets which had sample data inserted from the old system on the main worksheet. On additional worksheets there were mapping tables so that the tester could identify any old values that had been mapped to new values. The testers simply ran through each record using the target system and updated the spreadsheets if and when differences were seen. Any differences were then forwarded to the migration consultants and once confirmed were entered onto an issue logging system so that these could be tracked until resolved.

Don't forget that not all fields will have been migrated from the legacy system, some will have been defaulted by the migration routines.

Theres a couple of things to bear in mind at this stage. Don't leave it entirely up to the testers to choose which records to check. This must be driven at least in some part by the migration consultants as they will know which subsets of records are likely to have potential issues. Also you'll have to decide how many records you're going to check in this way. This will probably vary within the same project. For example you may have 20000 customer records and it may be feasible to check between 5 and 10 percent of these. The same migration may have 300000 claim or order records attached to customers, you'll probably struggle to check 10 percent of these, so you'll probably need to go to more like 1% (which is still 3000).

So don't underestimate the time this is going to take.

2) Testing the Target systems functionality with migrated data

Does the target system perform as it should with migrated data. Your data may have migrated well and look accurate, but usually its the data you can't see on the screen (such as flags, control records and counts etc) which cause problems here and cause the target system to either error or do unexpected things. This is where you will need to write testscripts for the testers to perform day to day tasks on the target system. The testscripts should be written by using business knowledge, but again you may need some input from the migration team as to which records to check for the same reasons as in step one.

Each part of the system should be checked to ensure that it is performing as it should. For instance can you add a new customer, can you add a order record to a migrated customer, what about an accounts record, do the amend routines work correctly, do the month end accounts routines all work as expected, do any extracts to other systems take the records as expected. These are just some of the areas you'll need to cover.

Again there's a lot to consider and care should be taken to ensure that nothing is left to chance.