A tool that migrates data from database A to B has been developed. The tool will be used to migrate all production data from version 1.0 of our app (operating on A) to version 2.0, currently being developed (operating on B). The schema may differ between each other. How are you going to make sure the application is working after migration? Provide your test strategy and sample test cases.

  • 2
    A complete answer? I attach my bank account number as well, ok? ;) Jan 30, 2014 at 13:00
  • 2
    StackExchange is not for demanding homework / interview answers.
    – user6873
    Jan 30, 2014 at 13:02
  • 4
    Welcome to SQA, nakul garg. If this is a homework/interview question, you should provide some evidence that you tried to work out the question on your own. If it is not a homework question, please provide specific details such as the database vendor and the framework that the tool is built on top of.
    – user246
    Jan 30, 2014 at 14:36
  • 3
    -1 because you copied it directly from my answer, without even citing me: sqa.stackexchange.com/a/7463/1933
    – dzieciou
    Jan 30, 2014 at 19:52

1 Answer 1


I would suggest that the most risk would be in the areas that change schema.

As a first step ask for a data migration plan. That is, a mapping from the current schema to the new schema. You can then verify that the database was migrated as expected from a data point of view.

In order to test this aspect properly you will need business domain knowledge of how the application works and which functions access this particular data. You should focus your testing around the application functions that access this data.

For the data that has not changed schema, I would suggest that a comparison/diff of the data from the original to the migrated database be done to verify that no data has been inadvertently changed. This should include both the data and the data model/schema.

You labeled this manual-testing. However, for such a change it would be nice to have an automated set of regression test cases for added confidence that the application can still read/write to/from the new database.

This is of course a simplified answer of a simplified question without much detail. In the real world, you would be worried about stored procedures, triggers, etc. and again the functionality that hinges from it.

Not the answer you're looking for? Browse other questions tagged or ask your own question.