Shouldn't you do DB updates in production in a way that N backend always works at least with N+1 schema? So you just rollback the backend...
Doing as you say requires two deployment for each change with a pause in between, and likely two separate merges (does it?). This reduces the deployment velocity. I might have to do as you describe when I start scaling out - there is no hope of updating many servers in sync so might as well embrace multi-version.
For example, this could mean that you don't delete any column that were still in use in the previous backend version.
This would have the advantage of letting you rollback your backend alone if anything wrong happens.