Yeah, in simpler circumstances you can follow the approach of 1) Write code that works with current and new schema 2) Deploy that code 3) Run that version fo

Yeah, in simpler circumstances you can follow the approach of 1) Write code that works with current and new schema 2) Deploy that code 3) Run that version for long enough to know you will not roll it back 3) Run the migration, moving the db from current to new schema 4) Clean up code to only work with new schema 5) Deploy that code Where step 3 uses an appropriate tool for online schema changes for your database. Here a some writeups of that approach I found when trying to explain this to a friend who's a rails developer: * http://blog.honeybadger.io/zero-downtime-migrations-of-large-databases-using-rails-postgres-and-redis/ http://blog.honeybadger.io/zero-downtime-migrations-of-large... * https://pedro.herokuapp.com/past/2011/7/13/rails_migrations_with_no_downtime/ https://pedro.herokuapp.com/past/2011/7/13/rails_migrations_... * https://www.rainforestqa.com/blog/2014-06-27-zero-downtime-database-migrations/ https://www.rainforestqa.com/blog/2014-06-27-zero-downtime-d... * https://blog.engineyard.com/2011/zero-downtime-deploys-with-migrations https://blog.engineyard.com/2011/zero-downtime-deploys-with-...