Key takeaways
The stall follows a script, so it's fixable.
Large IT projects run 45% over budget and deliver 56% less value.
The causes are management, never the technology.
The restart takes weeks: five steps, no re-bid.
The six-month script: how a migration stalls
Months 1 and 2: the progress is real, and misleading. The migration opens strong because everyone sequenced it to open strong. The standalone, low-dependency apps move first and the dashboard turns green. What the early wins actually consumed was the easy fraction of the portfolio. The percent-complete metric is now lying, politely.
Months 3 to 5: the middle gets heavy. The next tranche touches the real estate: shared databases, undocumented integrations, systems whose builders left years ago. Each app that "just needs re-platforming" feeds three other systems nobody wrote down. The double-run has begun, paying for on-prem and cloud at once. Velocity halves. The plan doesn't.
Month 6: the wall. Most of the budget is gone, spent at easy-app efficiency on hard-app work. What remains is precisely the applications deferred for being difficult. The borrowed internal experts are back on operations. And the vendor, paid on hours, responds with the only move its contract rewards: a change order. Nothing has technically failed. Everything has slowed to the point where finishing on the original terms is impossible.
Why does a migration stall? Four causes, none of them technical
Easy-first sequencing. Ordering the portfolio by difficulty instead of by dependency makes month 2 look great and guarantees month 6.
No dependency map. The estimate was built on an application count, not on how the applications are wired together. A pre-migration assessment closes this gap, and mid-flight is a legitimate time to close it.
A part-time team. Internal experts who also run production staffed the migration. Operations wins every tie, and by month 5 the migration gets no hours at all.
A vendor with no stake in the finish. An hours-based contract converts every surprise into revenue. Nobody on the sell side is paid more when the migration ends sooner, and that shows.
How do you restart a stalled migration? Five steps, in order
The instinct at the wall is to push harder, or to re-bid the program and lose two quarters. The restart is a third option, and it runs in weeks.
Stop and re-baseline
Freeze new starts for two weeks and assess what actually remains: which applications, wired to what, at what real cost to move. The stall happened because the plan was built on assumptions; the restart can't be.
Re-sequence by dependency, not difficulty
Order the portfolio by what unblocks what. Interdependent clusters move together or not at all.
Re-triage the stragglers
Give each deferred application the full menu: keep, re-platform, replace, or retire. Every retirement is instant, free progress. The full framework is in the lift-and-shift trap.
Cap the double-run with hard cutover dates
The on-prem-plus-cloud overlap is the most common source of budget overrun, and open-ended overlap is a decision. Set a decommission date per cluster and treat every slip as a budget event needing an owner's signature.
Put one name on the outcome
The restart holds only if a single owner is accountable for the finish: an executive sponsor inside, and a delivery partner whose terms depend on completion rather than hours.
The contrast: pushing through vs. restarting properly
Keep the plan, demand more velocity
Two-week re-baseline of what actually remains
Sequence stays easy-first by inertia
Re-sequenced by dependency
Every remaining app still gets moved
Stragglers re-triaged; some retire, some get replaced
Double-run open-ended
Cutover dates per cluster, slips escalated
More hours from the same contract
An owner whose terms depend on the finish
What we see in the field
The stalled migrations that come to us share a silhouette: over half the budget consumed, under half the portfolio moved, and a status deck that has said "at risk" in the same yellow for four months. The re-baseline is where the mood changes, because it replaces an argument about effort with facts about scope. Repeatedly, a slice of the remaining applications should never have been in scope at all, and retiring them shrinks the mountain on day one.
Our own migration record, 300+ applications with unplanned downtime down 60% and infrastructure cost down 35%, was built on the mechanics the restart installs: dependency-ordered sequencing, per-application decisions, hard cutover dates.
What this means for you
The restart costs you two weeks. The stall costs you open-ended months, because stalled programs don't hold at "slow," they decay toward cancellation.
The double-run is compounding while your program idles, and an hours-based vendor meets every delay with a change order. Capped cutovers and completion terms stop the meter.
A migration that dies at 60% spent is the worst outcome on your board slide: the money is gone, the datacenter remains, and the write-up has your name on it.
Your program stalled for management reasons. It restarts the same way: measure what's left, and put someone on the hook for the finish.
Frequently asked questions
Why do cloud migrations stall midway?
Four repeating causes: easy-first sequencing, undocumented dependencies surfacing in testing, internal teams pulled back to operations, and hours-based vendor contracts that reward delay.
How do you restart a stalled migration?
Freeze and re-baseline the remaining scope for two weeks, re-sequence by dependency, re-triage every remaining application (keep, re-platform, replace, retire), set hard per-cluster cutover dates, and put a single owner on the outcome with completion-based terms.
What are the warning signs a migration is about to stall?
Velocity dropping while the plan date holds, dependency surprises appearing in testing, migration staff pulled to operations, and a growing gap between budget consumed and portfolio moved. Any two of those by month 4 is the wall casting its shadow.
Get an outside read before month 9
A 30-minute stalled-initiative review gets you an outside read on the remaining scope, which restart step matters most, and what a completion-owned finish would look like. No obligation.
AI made migration fast. NorthStar makes it accountable.
A re-baselined plan, dependency-ordered delivery, and a vetted, dedicated pod that owns the finish inside your legacy systems, without the Big-4 bill or the offshore babysitting.
Sources
McKinsey and University of Oxford, "Delivering large-scale IT projects on time, on budget, and on value" (5,400+ projects): 45% over budget, 56% less value than predicted; 17% overrun above 200% and threaten the company's existence. mckinsey.com
"Give us upfront clarity on timeline and budget, not surprises in month 6": recurring buyer language from enterprise software review analyses (G2, Gartner Peer Insights, TrustRadius), compiled June 2026.
Double-run costs as the most common source of migration budget overruns: practitioner and industry consensus from cloud-migration cost analyses. Directional.