It's not about guessing if the db is right, it's about checking if it actually is. That applies both before running the script to test the existing environment, and after it ran, to make sure the right things happened. Semi-stupid example: There's an ordered set of possible responses to a question the user gets asked. Migrations inactivate some of them, rename some, and insert some, which are supposed to end up in specific places in the order. Whether you check when the script runs in production or not, at some point in building these migrations at least, you need to verify the end result. That might as well be part of the script, so it DOES run in the live case, and you know the live result is right.

Then build that into your migration

Even though the data in prod could be different from dev and staging, in spite of best efforts? You know what they say, everything you don't test doesn't work.

Dave you sound like a true DBA, cautious. It’s a good balance to devs who are more optimistic that if it worked once it will work again

The "migration" I'm doing at 6am tomorrow has to be run on two dbs, definitely different, but theoretically not in any of the respects the migration deals with. I've run all scripts on my dev db, staging, and the staging version of the site running the 2nd db, and everything went as expected. We should be ok. But I'd rather this were more automated (it's manually run SQL scripts now), and was thinking about CBMigrations as a possibility, but wondering about this aspect of it. I suppose I could customize it to add verifyPrerequisites() and verifyOutcome() methods. Not today 🙂 (@Jordan Clark, not a dba, just a cautious dev with mission critical apps.)