Why does my schema migration run before checking if deployed services survive it?

When you push a schema change to a production database, the migration executes before any tool verifies that the service versions currently running can read and write the new shape. A dropped column or renamed field reaches the database before old pods finish draining, and rollback restores the schema but not data written by the new version in the meantime. ORM tools generate SQL from diffs but model nothing about deployment topology, concurrent service versions, or live read-write patterns. Teams compensate with expand-contract rituals documented in wikis and tribal knowledge, not enforced by tooling. A single misordered step triggered multi-service cascading failures and a documented $4.5 million incident in the last year alone.