However, for larger updates, the time when the front end code is out-of-step with the database can cause end-user problems.
You should try very hard to structure your database migrations so that instead of going directly from uniquely valid state to another uniquely valid state you instead transition to a dual-ly valid state (i.e., don't break the old way of doing things while adding the pieces to make the new way of doing things work) and then separately remove the old valid state components once you know all of the software upgrades have been deployed.
Add New Stuff, Leave Old Stuff Alone
Remove Old Stuff
Triggers can be installed during the transition period to facilitate the duplication of data that will result.
This should be considerably easier for non-data impacting updates as you can just choose different names for the new stuff then remove the old stuff separately.
