The migrations that fail rarely fail with a dramatic outage. They fail quietly, through drift — small delays and skipped steps that compound until the budget and timeline are already gone by the time anyone notices. After enough of these reviews, the same five drift patterns show up again and again. None of them look dangerous in isolation. Together, they're the clearest early warning we know of.
1. The Dependency Map Was Never Finished
Every migration starts with a dependency-mapping exercise, and almost every team runs out of patience for it about 80% of the way through. The remaining 20% is usually where the surprises live — the batch job nobody remembered, the reporting service only one legacy system calls twice a year, the integration documented once in a wiki nobody's opened since. If your dependency map has stalled for more than a sprint, that's not a scheduling inconvenience. Treat it as a signal.
2. The Pilot Migration Keeps Getting Rescheduled
A pilot exists to surface problems while the stakes are still low — a small, representative workload moved first, deliberately, so the team learns what breaks before it matters. When a pilot slips repeatedly — a resourcing conflict here, "let's wait for the next sprint" there — it's rarely the calendar that's actually the problem. More often, it's a sign the team doesn't yet trust the plan enough to test it, and nobody wants to find that out yet.
3. The Rollback Plan Exists Only on Paper
A rollback plan that has never been executed isn't a rollback plan. It's a hypothesis. If nobody has actually run the rollback procedure end to end, in a non-production environment, you don't know how long it takes, what it breaks on the way back, or whether it works at all. The teams that get burned aren't the ones without a rollback plan — they're the ones who assumed the plan they wrote down would work exactly as written, under pressure, at 2 a.m.
4. No Workload Has a Single, Named Owner
When responsibility for a workload is shared across a team instead of assigned to one person, small issues sit unresolved longer, because everyone reasonably assumes someone else is already watching it. A missing named owner rarely causes a migration to fail on its own. But it's reliably present, in hindsight, in the ones that did.
5. There's No Cutover Rehearsal on the Calendar
Cutover day should be the least eventful part of the entire project, because everything in it should already have been rehearsed. If the cutover sequence, the communication plan, and the rollback trigger haven't been walked through together as a full team before go-live week, go-live week is exactly when you'll discover what's missing — with far less room to fix it.
What to Do If You Recognize Two or More of These
None of these signs guarantees a failed migration on its own. But if two or more are true right now, the right move isn't to push harder toward the existing go-live date — it's to pause, name the gap honestly, and close it before that date arrives, not after. A short, focused remediation sprint at this stage is dramatically cheaper than a rollback during cutover week.
FAQ
How do I know if my migration is actually behind schedule, or just going through normal friction? Normal friction resolves within a sprint or two. Drift is when the same gap — an unfinished dependency map, a slipping pilot — persists across multiple planning cycles without anyone naming it out loud as a risk.
Do we need to redo the whole rollback plan if it's never been tested? Not redo — rehearse. Run the existing plan end to end in a non-production environment and time it. Most rollback plans don't need a rewrite; they need to be executed once before anyone trusts them under pressure.
What's the single highest-risk sign on this list? An untested rollback plan, because it's the one that determines how bad your worst-case scenario actually is. The other four affect your odds of needing it. This one determines what happens if you do.