Actually this is not impossible for Wappler if a few new features were added in a new version of Wappler.
I guess the problem is that Wappler would have to know that the “finished” table that Wappler reads correctly in your local project must now be OVERWRITTEN on Migration. Since you’ve been generating table changes locally those multiple queries have not been executed on the remote target.
Wappler would have to have a setting that says on Migration UPDATE Table x or Tables Y, reservations, guests (example) with specific types of UPDATE queries.
And /or then the Migration process would, for instance, rename affected tables (“guests_21_07_05”) you specify and then completely recreate a Copy of the tables you changed on your local project with the same table name.
I imagine this could even be a Wappler extension that runs ahead of the current Migration operation giving you extra choices on what happens in a Migration.
I have ways of doing that separately from Wappler but I assume you’d have to run your development LIVE to your remote target, instead of locally, so that your development queries get transmitted to your remote tables.
One way is to do a sql file export of the affected database table after you are ready to upload the Wappler files and have made all table changes in Wappler.
Then run this Update in the database manager at your remote target. Simplest is to rename the existing table and then do an Import of your sql file as a Make table and populate it with a query to add the same table name back into your remote databse with all the matching schema changes your Wappler code expects.