Key takeaways
The stall is predictable, which means it is preventable and, mid-flight, fixable. The pattern below repeats across industries almost beat for beat.
The numbers behind the feeling: large IT projects run 45% over budget and deliver 56% less value than planned, and 17% overrun so badly they threaten the company (McKinsey and Oxford, 5,400+ projects).
The pattern holds at government scale, too: a July 2025 GAO audit found federal agencies had fully documented modernization plans for only 3 of 11 critical legacy systems flagged as most in need of an upgrade, the exact undocumented-plan gap GAO says drives cost overruns, schedule delays, and outright project failure (GAO-25-107795).
The stall is rarely about the technology. It is sequencing, undocumented dependencies, a part-time team, and a vendor paid for hours rather than the outcome.
The restart takes weeks, not a re-bid: stop and re-baseline, re-sequence by dependency, re-triage the stragglers, cap the double-run, and put one name on the outcome.
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, well-documented, low-dependency applications move first, the dashboard turns green, and the steering committee relaxes. What the early wins actually consumed was the easy fraction of the portfolio, while the burn rate was calibrated to it. The percent-complete metric is now lying, politely.
Months 3 to 5: the middle gets heavy
The next tranche of applications touches the real estate: shared databases, undocumented integrations, systems whose original builders left years ago. Each app that "just needs re-platforming" turns out to feed three other systems nobody wrote down. Failed migration projects routinely trace to unanticipated dependency conflicts surfacing in testing (Uptime Institute figures are widely cited at 38%; directional). Meanwhile the double-run has begun, paying for on-prem and cloud at once, and the overlap keeps getting longer. Velocity halves. The plan does not.
Month 6: the wall
The arithmetic arrives all at once. Most of the budget is gone, spent at easy-app efficiency on hard-app work. The remaining portfolio is precisely the applications that were deferred for being difficult. The borrowed internal experts have been pulled back to operations, because operational priorities always win. And the vendor, paid on hours, responds to the complexity 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 no longer possible, and everyone in the room knows it before anyone says it.
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. The hard applications were always the project; they were just scheduled to be someone's problem later.
No dependency map. The estimate was built on an application count, not on how the applications are wired together. Every undocumented integration discovered in testing is schedule that was never in the plan. This is the gap a pre-migration assessment exists to close, and mid-flight is a legitimate time to close it.
A part-time team. The migration was staffed with internal experts who also run production. Under pressure, operations wins every tie, and the migration gets the hours left over, which by month 5 is none.
A vendor with no stake in the finish. An hours-based contract converts every surprise into revenue, so every discovered complexity becomes a change order rather than a flag raised early. 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 on the existing plan, or to re-bid the whole program and lose two quarters. The restart is a third option, and it runs in weeks.
Stop and re-baseline
Freeze new migration starts for two weeks and assess what actually remains: which applications, wired to what, in what condition, at what real cost to move. The stall happened because the original plan was built on assumptions; the restart cannot be. This is the same discovery that should have opened the program, run now on the remaining scope, where it is smaller, cheaper, and impossible to argue with.
Re-sequence by dependency, not difficulty
Order the remaining portfolio by what unblocks what. Clusters of interdependent applications move together or not at all. The green-dashboard comfort of easy wins is gone anyway, which removes the last reason to sequence for optics.
Re-triage the stragglers
The deferred applications were deferred because the plan had one answer, move it, and they resisted. Give each one the full menu: keep, re-platform, replace, or retire. Mid-flight portfolios reliably carry applications that should exit the scope entirely, and every retirement is instant, free progress. The full decision framework is in the companion guide on 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, not a fact of nature. Set a decommission date per application cluster, tie it to the new sequence, and treat every slipped cutover as a budget event that needs an owner's signature, because it is one.
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 commercial terms depend on completion rather than on hours. Rescue is where the difference between the two contract shapes stops being philosophy and becomes the monthly burn.
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, "until we are done"
Cutover dates per cluster, slips escalated
More hours from the same contract
An owner whose terms depend on the finish
Month 9 looks like month 6
Visible movement inside the first six weeks
What we see in the field
The stalled migrations that come to us share a silhouette: well over half the budget consumed, well 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. In the pattern we see repeatedly, a meaningful slice of the remaining applications should never have been in scope at all, and retiring or replacing them shrinks the mountain on day one, before a single additional app moves.
Our own migration record, 300+ applications with unplanned downtime down 60% and infrastructure cost down 35%, was built on the same mechanics the restart installs: dependency-ordered sequencing, per-application decisions, and hard cutover dates. Rescue work is those mechanics applied late, which is harder than applying them early, and still far cheaper than month 9 of the stall.
Executive takeaway
Run the decision through the three things you translate everything into.
The restart costs two weeks of re-baselining plus a re-sequence. The stall, left alone, costs open-ended months, and stalled programs do not hold at "slow," they decay toward cancellation.
The double-run is compounding while the program idles, and an hours-based vendor meets every delay with a change order. Capped cutovers and completion-based terms are what stop the meter.
A migration that dies at 60% spent is the worst outcome on the board: the money is gone, the datacenter remains, and the write-up has a sponsor's name on it. McKinsey's 17% figure, projects that overrun so badly they threaten the business, is this scenario left uncorrected. The restart exists so the initiative you backed finishes as the one you promised.
AI made migration tooling fast. Programs stall for management reasons, and they restart the same way: when the remaining scope gets measured and someone owns the finish.
Frequently asked questions
Why do cloud migrations stall midway?
Four repeating causes: easy-first sequencing that spends the budget before the hard applications start, undocumented dependencies surfacing in testing, internal teams pulled back to operations, and hours-based vendor contracts that reward delay. The stall is a management pattern, not a technology failure.
How do you restart a stalled migration?
Five steps: freeze and re-baseline the remaining scope for two weeks, re-sequence by dependency rather than difficulty, re-triage every remaining application (keep, re-platform, replace, retire), set hard per-cluster cutover dates to cap double-run costs, and put a single owner on the outcome with completion-based commercial terms.
Should a stalled migration be re-bid from scratch?
Rarely. A full re-bid costs one to two quarters and repeats the original mistake of planning without a current baseline. A two-week re-baseline of the remaining scope preserves the work already done and produces a restart plan faster than a procurement cycle produces a vendor.
What are the warning signs a migration is about to stall?
Percent-complete tracking application count instead of complexity, velocity dropping while the plan date holds, dependency surprises appearing in testing rather than planning, migration staff repeatedly 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
If your migration is drifting, a 30-minute stalled-initiative review gets you an outside read on the remaining scope, which restart step matters most in your situation, and what a completion-owned finish would look like. No obligation.
Restarting often means revisiting the strategy that caused the stall: The Lift-and-Shift Trap: Why Moving Legacy As-Is to the Cloud Just Relocates the Problem.
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, 7% over schedule, 56% less value than predicted; 17% overrun above 200% and threaten the company's existence. mckinsey.com
Cloud migration overrun figures (75% over budget, 37% behind schedule) and the Uptime Institute dependency-conflict figure (38% of failed migrations): compiled industry figures as sourced in the NorthStar Cloud Migration Readiness Scorecard. Directional; verify before quoting in a client-facing asset.
"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.
U.S. GAO, "Information Technology: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems" (GAO-25-107795, published July 17, 2025): 11 critical federal legacy systems identified; only 3 fully documented a modernization plan with all key success practices, the other 8 did not; GAO ties undocumented plans directly to increased risk of cost overruns, schedule delays, and project failure. VERIFIED, primary source. gao.gov