Staging Config in Production Caused Silent Data Split After Column Rename Deploy

A backend team deployed a database column rename on a Sunday night, expecting a smooth migration, but the migration never ran because production was using a staging configuration file. The file had two dangerous settings: one that disabled Flyway migrations and another that let Hibernate auto-update the schema instead. Hibernate silently added the new column while leaving the old one intact, resulting in a table with two columns where data was split between them. The issue went undetected for eleven minutes since no exceptions were thrown, and it was only flagged when a downstream team noticed customer status fields appearing empty. The incident highlighted the risk of copying staging config files into production without auditing inherited settings, and was resolved by re-enabling Flyway and switching Hibernate to validate mode.