A migration can be merged after another and still never run in production if its version number is lower than one already applied. That appears to be what happened in a billing-team incident described by developer Sergey Shinder: an invoice-language column was missing in production even though its migration had been merged. The account is the author’s report, not an independently audited postmortem.
How the migrations reached production out of order
Shinder’s account describes two developers writing migrations during the same week. One added an invoice-language column as V41; the other added an index as V42. V42 was merged and deployed first, followed by V41. A customer later encountered an error when selecting an invoice language because production did not have the column.
As an Amazon Associate I earn from qualifying purchases.
The report attributes the missing column to a Flyway setting that allowed the older migration to be ignored after the newer version had already been applied. It does not identify the exact setting or Flyway version. The explanation should therefore be treated as the author’s account of the incident, not as a confirmed configuration diagnosis.
The reported staging behavior helps explain why the problem escaped notice: staging was rebuilt nightly and, according to the author, applied both migrations in order. A freshly rebuilt database can therefore have a different migration history from a long-lived production database. Redgate’s Flyway documentation says environments in a deployment pipeline are expected to receive the same versioned and repeatable migrations in the same order (Conditionally executing migrations).
#1 Best Overall
What Flyway’s documented settings actually do
Flyway orders versioned migrations by version number. Its getting-started documentation says that once a database has advanced, lower-version migrations are ignored by default (Getting started with Flyway). That default behavior makes version assignment important when developers work concurrently.
| Setting | Operation affected | Documented behavior | Intended distinction |
|---|---|---|---|
outOfOrder |
Whether a lower-version migration can be applied after a higher-version migration has already run | Defaults to false; enabling it permits out-of-order migrations |
Controls whether a late, lower-numbered migration is allowed to run (Flyway Out Of Order Setting) |
ignoreMigrationPatterns |
Migration status handling during validate and repair |
Applies to validation and repair behavior; it is not the documented control for applying lower versions | Controls which migration statuses are disregarded during those operations (Flyway Ignore Migration Patterns Setting) |
The incident report’s description of an older migration being “ignored” does not map cleanly to the current documentation for these settings. The documented role of outOfOrder is distinct from ignoreMigrationPatterns. Without the exact configuration and Flyway version from the incident, the documented behavior cannot establish which property, if any, caused the reported outcome.
Why a clean staging database can miss a production problem
A nightly rebuild starts with a different history from a database that has been incrementally updated over time. If the rebuilt environment sees V41 before V42, it can end up with both the column and the index, while production that already applied V42 may treat V41 differently. A successful test on a clean database does not by itself prove that the same migrations will behave identically against every existing environment.
Free tools Windows power users keep installed
One-click scans. No signup required.
This is why migration checks need to account for sequence and state, not just whether the latest code builds or a fresh database can be created. Teams should verify that deployment environments apply the same migration set in a consistent order and inspect the actual migration history of long-lived targets.
Rank #3
Controls the team reported adding
Shinder says the team removed the permissive setting, changed to migration versions based on file-creation timestamps, added a merge-queue check that rejected a new migration older than the latest migration on main, and added a post-production-deployment comparison of applied migration history with the codebase. The author reports that the first reconciliation found an older skipped migration.
Those are remedies chosen by that team, not universal Flyway requirements. Timestamp-based versions can help coordinate concurrent authors, but a timestamp alone does not prevent collisions, incorrect ordering, or a mismatch between repository files and a target database. The important control is to make version assignment coordinated and make discrepancies visible before and after deployment.
Rank #4
Make migration problems visible before widening a release
Redgate’s fleet rollout tutorial describes a deployment pattern that runs info, validate, and migrate together, begins with a canary, proceeds in waves after monitoring, and checks migration status across targets after rollout (Tutorial – Fleet rollout with migrations-based deployment). The tutorial says validation should halt a deployment when checksum or ordering mismatches are found. This is vendor guidance; suitability depends on the system and rollout design.
Recommended Free Tools
| Rollout approach | Blast radius | Problem detection | Ability to halt |
|---|---|---|---|
| Single-step deployment | Changes reach the deployment target together; a migration issue can affect the full target before it is noticed. | Detection depends on checks and monitoring around that deployment; no standard detection time is specified. | There is no intermediate wave in which to stop before proceeding to more targets. |
| Canary followed by waves | Starts with a limited canary target, then expands in stages. | Monitoring between waves can reveal a problem before rollout continues. | Teams can pause before the next wave; the tutorial recommends checking migration status across targets after rollout. |
A staged rollout does not repair an incorrect migration order by itself. It gives a team an opportunity to detect a problem and limit how far a deployment proceeds, while validation and post-deployment history checks address whether the expected migrations actually ran.
Quick Recap
Best Value
A practical migration-order checklist
- Assign versions through a coordinated process so concurrent changes cannot silently introduce a lower version after a higher one has reached a deployment target.
- Run migration validation before changing production, and make validation failures block the deployment rather than treating them as informational output.
- Test against the relevant existing database state, not only a freshly rebuilt environment.
- After deployment, compare the migrations recorded as applied with the migration files expected in the deployed codebase.
- For multi-target releases, consider a canary and staged waves with monitoring and a status check before rollout expands.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
