Pointing the new version of the WebAPI application at the existing (old) webAPI database should have auto-migrated all tables (including creation and drop) to the newer schema in v2.10. If there was manual changes made to the WebAPI database, then the migration scripts will not know how to handle that and the migration scripts will fail.
The error message you provided isn’t clear enough without context (such as which migration script led to the error, or if it was some other error on startup).
If you want to try to migrate from one WebAPI instance to another, you could look into using ROhdsiWebAPI to query the old WebAPI instance for the existing assets and then post them to the new webAPI instance for loading.
You could also look at a more ‘raw’ database migration where you export the data from the old tables and then bulk-insert them into the new tables, but this is a very technically complicated maneuver where if you don’t import the data in the right order and use the right database sequences you could make a mistake that will cause the application not to work.
It’s also not clear which version of DBMS you are running on so I don’t know if there’s any database-specific information I could give you.
Worst case scenario is you keep the old WebAPI running in 2.5, and have the new application running on 2.10, and you can export-import from one application to the other. A way you could do this is if you create a cohort characterization, add a bunch of cohort definitions to it, and then export the cohort characterization, you can import the characterization design into the new instance and it should not only import the characterization design, but all the cohort definitions that were included. There’s nothing that would do the work for concept sets, however. Your best bet (if you want to keep the 2 instances running) would go with the OhdsiRWebAPI R pacakge approach to export-import from old-to-new WebAPI instances.