-1

We are migrating our legacy product to new product with database changes.

I have following questions :

  1. What process should we follow ?
  2. What are major risk factors?
  3. What if we found blocker or critical bugs after migration?
  4. Can we take Automation help in there? and if Yes then How?
  5. Is there any available software for migration testing ?

This question is not about how to test migration process. This is about how can we test application is working fine after complete migration process.Doing testing with Functional , Non functional etc.So we can compare old and new application both.

Some how this question feels to broad for some users. Please give me any related answer which are best of your knowledge so I can start working on that.

Sagar007
  • 1,330
  • 3
  • 9
  • 24
  • Possible duplicate of How to test data migration procedure? – dzieciou Mar 18 '16 at 02:15
  • That question is about how to test migration process. we have done it properly. After completing that process how can we sure about migrated product is working fine? And also if we want to roll back that product, which are the ways? – Sagar007 Mar 18 '16 at 05:33
  • Is behaviour of the applications after data migration expected to be different than before? – dzieciou Mar 18 '16 at 07:39
  • Yes. Most of things are change from UI side but some of things are changed from back end side – Sagar007 Mar 18 '16 at 07:43
  • Ok. So this is different from my question. Would be good if you clarify in your question the system is changed as well. You actually have 3 things to test: 1) system after change with fake data, 2) data migration process 3) two previous points together, i.e., system after change with migrated data. – dzieciou Mar 18 '16 at 07:56
  • I am really confused about 3 point. How can we achieve it with less time. – Sagar007 Mar 18 '16 at 08:19
  • I downvoted this because it was too broad. No. 3 is orthogonal to the others, and belongs in its own question. –  Mar 18 '16 at 11:16

1 Answers1

2

If you are doing some kind of ETL of legacy data into a new system, then there are two main things to worry about.

First that the ETL logic is wrong, you do not bring over all records you meant to or the transformations are not done correctly.

Second that there is some kind of problem that causes a data loss. For instance that the source DB cannot handle all of the requests being made against it which causes queries to time out.

If you want to test the ETL logic then you can model the states the data could be in that the logic triggers on, and then create that data and verify that it transforms as expected.

If you want to test how the system handles load, then you can create a lot of source test data and then compare the number of records in the new system to the expected number after the ETL has been run.

If you find a problem after the migration then you really only have two choices. Try to fix the problem in the destination side or fix the code and re-run the migration.

I have automated the ETL logic testing I described above, but I didn't use an existing tool or framework.

David Cain
  • 764
  • 4
  • 8