Why legacy migrations fail: the failure modes nobody budgets for

Migration plans usually budget for the risks that are easy to name: the new system might have bugs, the timeline might slip, the team might need more training. Those risks get planned for, and they rarely sink a migration. The ones that do are quieter.

Data that looks migrated but isn’t

The most common failure mode isn’t data loss — it’s data that moved but changed meaning in the process. A field that meant one thing in the old schema and something subtly different in the new one, a default value that fills in silently where the old system required an explicit choice, a timezone assumption that was implicit in the old code and wrong in the new one. None of these throw an error. They just make the new system quietly incorrect.

Cutover as a single point of failure

Treating cutover as one irreversible event means the entire migration’s risk is concentrated into a single afternoon. If anything is wrong — even something unrelated to the migration itself, like an unrelated traffic spike — there’s no way to separate “is this the migration” from “is this something else,” because everything happened at once.

Scope creep disguised as improvement

“While we’re migrating it, let’s also fix…” is how a bounded, verifiable migration turns into an unbounded rewrite with no clear definition of done. Every additional change introduced during the migration is another variable in the diff between old and new behavior, and another thing that has to be verified before cutover.

What actually budgets for these

The fix for all three is the same discipline: migrate the system as it is, verify the data continuously instead of once, and make cutover reversible instead of final. That’s a process decision, not a technology one — which is why it has to be planned for explicitly rather than assumed. See designing a cutover you can safely roll back for how that last piece is actually built.