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.