I am working on an app that will soon have two backend databases. A new group is leveraging our GUI application. They are building a new database and web services. It is supposed to be built identical to the current one. We wrote about 400 test cases for the current database. Am I going overboard by saying those 400 test cases need to be run against the new database or should I be reducing that number to a sample?
I think you can do some analysis, how many bugs were valid rom your 400 test cases. I mean how many were good enough to uncover the bugs from your old run. I think it makes sense to give them as high priority then you can take second test cases.
Instead of executing the same think against new DB
I would look at the current test cases and weed out any duplications, and add anything that was missed. Also, when a development group, internal or external, has done previous work I look at the types of defects found in their previous work. I have found error tend to be repeated even amongst apparently separate teams within the same vendor. Ensure that there are Test Cases that will discover these.