Not sure if this is the right forum for this, but I am looking for input into the development of an SAP Data Migration Test strategy. Essentially we are indentifying existing data in a "source" legacy ERP system (Microsoft Dynamics), and are migrating this data to a new SAP instance. Some data will go over directly, some will be mapped to different types of data, and some will be transformed based on the expected data format rules in the target system.
I am looking for input on a Data Migration test strategy on how to help validate the success of our data migration. I normally would focus on some automation (Using QTP), but also may need to rely on alot of manual verifications. Unfortunately, I've never done this before and am looking for input and insight into how best to approach this. Even if someone could point me to an example document/approach this would be helpful. There is a lot of stuff out there on Google, etc., but I'd rather have input from someone who has DONE it and can point me in the right direction - rather than grabbing strategies off the cuff.
If you abstract the question away from ERP/SAP and consider data migrations without concern for the underlying technologies, there are a number of threads on SQAForums where data migrations/conversions have been discussed.
And to repeat two umbrella issues to consider:
1. Has the data been converted/migrated correctly? This will address validating the conversion itself. Think about things like counts and states. If you have 10 records on the legacy system, you should have 10 on the new...that is, unless there are rules that exclude a subset of the data for whatever reason. Similarly, if you have 5 active and 5 inactive records on the legacy system, do you have the same counts broken down by state on the new?
2. Is the data usable? Think CRUD.
C - Can you create records in the new system?
R - Can you read/access records in the new system?
U - Can you update records in the new system?
D - Can you 'delete' records in the new system? (From an application standpoint, you might 'delete' a record...but what you're really doing is changing its state. To me, this would fall under 'U'. Rather, is there a means/need to DELETE data? If so, you'll want to explore that as well.)
"The single biggest problem in communication is the illusion that it has taken place."
-George Bernard Shaw, Irish playwright and Nobel Prize winner, 1856-1950