iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A later-merged database migration can fail to run in production when its version number sorts before a migration that has already been applied. Flyway orders versioned migrations by version—not by merge time—and, by default, does not apply a lower-version migration after a higher one. That can leave production without a schema change the application expects, even when a rebuilt staging database succeeds.
What happened in the reported incident
In an incident account by Sergey Shinder, two developers on a billing team created migrations during the same week. One added an invoice-language column as V41; another added an index as V42. V42 was merged and deployed first. V41 followed, but a customer later received an error when choosing an invoice language because production lacked the column.
Shinder attributed the omission to a Flyway setting that allowed the older migration to be ignored after the later version had been applied. The account says staging was rebuilt nightly, so that environment applied both migrations in version order and did not reproduce production’s state. These are details from the author’s incident narrative, not an independently audited postmortem.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →How Flyway’s version ordering explains the risk
Flyway runs versioned migrations in version order. If a database has already applied V42, a newly introduced V41 is lower than the latest applied version. Flyway’s getting-started documentation says lower-version migrations are ignored by default once the database has advanced. See Flyway’s getting-started guide.
#1 Best Overall
The mechanism matters because Git merge order and migration order are separate. A file can be merged later while carrying an earlier migration version. On a long-lived database, the earlier file may therefore arrive after a later one has already been recorded as applied.
Do not confuse outOfOrder with ignoreMigrationPatterns
The current Flyway documentation identifies outOfOrder as the setting that controls whether a lower-version migration can run after a higher version. Its documented default is false. When enabled, Flyway can apply the lower version later; that changes migration execution behavior and should be an intentional policy choice. See the outOfOrder setting reference.
Rank #2
ignoreMigrationPatterns is a different setting: its documented scope is migration statuses considered by validate and repair, not permission to execute a lower-version migration after a higher one. See the ignoreMigrationPatterns reference.
| Setting | Operation affected | Documented default | Purpose |
|---|---|---|---|
outOfOrder |
Whether a lower-version migration may run after a higher version has been applied | false |
Controls out-of-order execution |
ignoreMigrationPatterns |
validate and repair |
Not stated here | Controls which migration statuses validation or repair disregards |
Shinder’s account does not identify the exact property or Flyway version involved. Its explanation of an older migration being “ignored” does not map cleanly to the current documentation for these two settings, so the documented behavior clarifies the risk but does not establish which property caused that incident.
Why staging can pass while production fails
A newly rebuilt staging database and a long-lived production database can encounter migration files in different effective states. If staging starts empty, it can apply V41 and then V42 in order. Production may already have V42 recorded before V41 is introduced, leaving it with a different schema if that earlier migration is not applied.
Flyway’s documentation says environments in a deployment pipeline are expected to receive the same versioned and repeatable migrations in the same order. A fresh staging rebuild is useful, but it does not by itself prove that a persistent production database has the same migration history. See Flyway’s guidance on conditionally executing migrations.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Controls that prevent or expose ordering mismatches
Coordinate version assignment across concurrent work
Make it difficult for two branches to introduce conflicting migration order. Teams can assign versions through a coordinated process or enforce a repository rule that rejects a new migration older than the latest migration on the target branch. Shinder reports that his team added a merge-queue check of this kind. He also reports moving to versions based on file creation timestamps; that was the team’s chosen remedy, not a universal Flyway recommendation.
Validate before changing the database
Run migration validation as part of deployment and treat checksum or ordering mismatches as a reason to stop before rollout. Redgate’s fleet tutorial describes running info, validate, and migrate together. These are vendor deployment instructions, not proof that the sequence is suitable or tested for every system. See the Flyway fleet rollout tutorial.
Compare repository state with applied history afterward
After deployment, compare the migrations present in the codebase with those recorded as applied in each target database. Shinder reports that his team added a post-production-deploy comparison and that its first reconciliation found an older skipped migration. This check can reveal drift that a successful application deployment alone would not show.
Choose a rollout pattern that limits exposure
| Approach | Blast radius | Problem detection | Ability to halt |
|---|---|---|---|
| Single-step deployment | A problem can affect all targets included in the deployment at once. | There is less opportunity to observe behavior between target groups. | Once the rollout has completed, stopping further deployment offers no protection to targets already changed. |
| Canary followed by waves | Initially limits exposure to the canary, then expands in stages. | Allows monitoring between waves before expanding. | Deployment can be paused before additional waves if validation or monitoring signals a problem. |
Redgate’s tutorial documents a canary-and-wave pattern with monitoring and migration-status checks after rollout. A staged rollout can reduce the scope of an early failure, but it does not replace correct migration ordering or validation, and the right rollout depends on the system’s deployment constraints.
Quick Recap
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.
Recommended Free Tools
