A migration that's stalled — behind schedule, over budget, or simply not moving — triggers an understandable instinct to restart from scratch with a cleaner plan. That instinct is usually wrong. Most stalled migrations don't need a restart; they need an honest diagnosis of exactly which decision is blocked and who has the authority to unblock it.
The common underlying causes are consistent across most stalled projects: complexity increased faster than the team's capacity to adapt, dependencies were underestimated at the planning stage, requirements shifted mid-programme without the plan being formally re-scoped, or the project simply needed specialised expertise the internal team didn't have and never brought in.
The recovery process starts with a decision audit rather than a technical review: for each blocked workstream, identify specifically what decision is stuck, who has the authority to make it, and why it hasn't been made yet. Frequently the technical work isn't actually blocked — a business decision about acceptable downtime, or a budget approval for a dependency nobody scoped, is the real bottleneck wearing a technical disguise.
Resequencing matters as much as unblocking. Work that doesn't depend on the stuck decision should proceed in parallel rather than waiting for it, which is often not what's happening in a stalled project — everything tends to wait on the same blocker even when it doesn't strictly need to.
Bringing in outside expertise makes sense specifically when the internal team is overloaded, execution has slowed significantly, or the stall is rooted in specialised knowledge the team doesn't have — not as a first resort, but as a recognition that momentum, once genuinely lost, is difficult to regain from inside the same constraints that caused the stall.
All technical perspectives