Not the OP, but the way I handle this to to ensure that all migrations are backwards compatible - the current and new versions of the app/API/service must be ab

Not the OP, but the way I handle this to to ensure that all migrations are backwards compatible - the current and new versions of the app/API/service must be able to run with the old and new database. This requires a little discipline, but if you follow a few simple rules it's not really that arduous: - when adding a new column, it must have a default value set, or be nullable - don't drop any columns - don't rename any columns Now, for those last 2, what I really mean is "don't do it in a single release" - if you want to make destructive changes, do it over the course of 2 releases. - release 1: remove dependencies on the column from the app/API/service - release 2: performs the database migration with destructive changes It probably sounds more difficult than it actually is :) In reality, I don't make destructive changes that often though.