User loginNavigation |
Advice for testing a large migration projectI am a Test Manager and due to start a new job with an energy company in the next few weeks. This company are looking to migrate over 100 systems onto 1 new system. Unfortunately I have never worked on a migration before so have little knowledge on this, apart from what I have read on the net. Does anyone have a migration test strategy or some general pointers on this? Thanks
|
Top PagesRecent Blogs
|
Migration 100 into one
Immediate thoughts:
1. You will have no requirements specs - write them yourselves.
2. There will be order effects:
a. Look at the system topography to see what connects to what and thus what depends on what,
b. get a definition of how many people use each system,
c. identify the systems' priorities,
d. create a data model to try and partition the data (if possible),
e. look at a lot of Extract, Transfer and Load tools.
to see what can be moved when.
3. Don't assume that because you're using COTS stuff that it all works. It did when it was in the box, but now someone has installed it badly it won't.
4. You aren't testing the migrated systems so much as testing the scripts used in the ETL tool's ability to manipulate the data such that nothing is left to be manually loaded into the target system on the night. SO. Create a big test platform and copy over production data copies and test that they are migrated satisfactorily LOTS of times before you make the move.
5. If you can't trace what happens to every bit of data's life story, be sure you will have downstream problems.
6. Have a requirements manager. If no-one's appointed then it's you.
7. Have an environment manager. This is NEVER you.
8. Have a very solid performance test team to hand.
9. Split your project into phases. Do the simpler stuff first to get experience.