I think maintaining the integrity of the database is always going to be an issue with major code changes. Where I work, we have different environments for development, testing, and production, so code and database layout changes move together between environments. For production releases, we have the users stay off the system. If they stay on, it’s at their own risk of being booted or having data lost. Usually the database is pretty set in stone, so changes to the database are few and far between and most tables are unique to a single year. As for Glide, the Google sheet would always be considered as production data. I would probably consider duplicating any data columns that would have substantial changes, or duplicate individual sheets as needed. When working on a draft version of a glide app, components could be converted over to the new columns/sheets. When moving a draft app to production, there may be some minor data migration, or in the case on duplicated columns, they could both function in sync until you feel comfortable that all users have the updated version of the app. At that time you could start to delete the old columns. There’s a bit of pre-planning involved, but it would keep the process seamless to the user. I imagine Google and IOS apps are even worse to deal with, because there is no guarantee of when or if the user will update there version of the app. Of course, there’s probably a lot more API and JSON involved in installed apps, which makes it easier to maintain compatibility between different app versions.