It really depends on the task but the general pattern is to split it up into separate steps, each of which is either low risk and/or easily reversible. Lets sa

It really depends on the task but the general pattern is to split it up into separate steps, each of which is either low risk and/or easily reversible. Lets say you want to add a new non nullable column with foreign keys, to replace an old non nullable column of foreign keys to a different table that’s obsolete and needs to be deleted. 1) update the code to be ok with a new nullable column. Rollback: deploy previous version of code. 2) create the new column in DB with it’s desired constraint, but make it nullable. Roll back: delete the column. 3) have the code start populating the new column as well as the old. Rollback: deploy previous version of code. 4) start backfilling historical entries with the new column. Rollback: you can’t roll this back! 5) make new column non nullable. Rollback: make it nullable. 6) update code to read from new column, continuing to write to both. Rollback: deploy previous version of code. 7) make old column nullable. Rollback: you can’t roll this back! 8) stop writing to old column. Rollback: deploy previous version of code. 9) once you’re satisfied the old column is no longer used and the version of code from the previous step will never be deployed again, drop the old column. Rollback: you can’t roll this back! 10) rename the obsoleted table and see if anything breaks. Rollback: rename it back to its original name. 11) delete the obsoleted renamed table. Rollback: you can’t roll this back!