Recovering a Stalled Cloud Migration: Year-Two Playbook

Cloud migration programs stall for a small number of specific reasons, and by year two most of them are visible if you know where to look. This piece is a practical playbook for the data leader whose program has slipped past its original timeline, whose SI relationship is under strain, and whose steering committee is asking for a re-baseline that does not turn into another six months of analysis. The recovery pattern that works is not a bigger version of the original plan. It is a different starting point (the remaining estate only), a different delivery model (accelerator-led for the pattern-based work), and a different relationship with the SI.

1. Signals of a stalled program

The signals are consistent across the stalled programs I see.

Missed milestones. The date on the last steering committee slide has been revised twice, and the third revision is being negotiated. Wave three was supposed to complete in Q2 and it is late Q3.

SI scope creep. Change requests are landing regularly. The original fixed-scope engagement has drifted into time-and-materials in practice. The finance team is asking questions.

Remaining estate complexity. The 60 percent that shipped was the easy 60 percent. The 40 percent left is the hard part, and the SI's delivery model is not shaped for it.

Executive fatigue. The sponsor has stopped forwarding steering committee updates internally. The next escalation is a difficult one, and everyone knows it.

If more than two of these are true, the program is stalled. Naming it is the first step in recovering it.

Four diagnostic signals of a stalled migration: missed milestones, SI scope creep, remaining estate complexity, and executive fatigue, with a rule that two of four signals indicate the program is stalled.

2. Run a recovery baseline (remaining estate only)

The recovery baseline is not a re-assessment of the whole migration. That is what the original plan tried to do, and doing it again is not going to produce a different result. The recovery baseline is a source-connected read of the remaining estate only, focused on the objects that have not yet moved.

The specifics.

Source-connected discovery of remaining objects. Metadata extraction across the source system, focused on what has not been converted. Not interviews. A direct read.

Complexity scoring on remaining objects only. Applied consistently, not sampled. This is where the honest picture of remaining effort comes from.

Dependency mapping across the remaining estate. Which of the remaining objects depend on each other, and which have downstream consumers that are already on the target platform. Cutover risk lives here.

Effort estimate by complexity tier. Not by object count. This is what makes the number defensible.

An 8 business day Modernization Canvas produces exactly this shape of output. It replaces a three-month re-baseline with an 8-day one, and it produces a plan the steering committee can act on rather than another quarter of analysis.

3. Renegotiate with the SI

Once the recovery baseline exists, the SI conversation gets easier. Not easier in the sense of comfortable, but easier in the sense of grounded.

Scope. What of the remaining estate is in the SI's original scope, what has drifted in through change requests, and what genuinely needs a different delivery approach.

Price. The remaining scope, priced honestly against the recovery baseline effort estimate. Not the original plan, which everyone knows is wrong.

Timeline. A revised timeline that respects the dependencies in the recovery baseline. Not the original timeline, revised down by a fudge factor.

Delivery model. Where the SI's delivery pattern fits and where it does not. Some SIs are better at build-out phases than at complex conversion tail work. It is fair to name that and adjust rather than force a fit.

The conversation is harder if the CDO shows up without the recovery baseline. It is much easier with it, because the numbers on the table are grounded rather than negotiated.

4. Sequence remaining waves by dependency

The wave plan for the remaining 40 percent is not a shrunk version of the original wave plan. It is a different plan.

Dependency-aware. What has downstream consumers already on the target platform. What has downstream consumers still on the source. What is cross-domain and needs to be sequenced after the domain owners are aligned.

Complexity-tiered. The remaining objects are skewed toward higher complexity, because the low-complexity ones shipped first. The wave plan has to account for that.

Risk-front-loaded on decisions, not on execution. The risk in the remaining 40 percent is often architectural (do we refactor this procedure or lift-and-shift it, do we keep or split this domain) as much as it is execution risk. Front-load the decisions so the execution waves are not blocked by unresolved architectural questions.

Cutover-aware. Every remaining wave has to think about what happens to the downstream consumers when the source objects move. This is where late-migration outages happen.

Five-step year-two cloud migration recovery framework covering signal diagnosis, remaining-estate baseline, SI renegotiation, dependency-aware waves, and accelerator-led conversion.

5. When to bring in accelerator-led delivery

The specific point where accelerator-led delivery pays for itself on a recovery.

Remaining estate has 1,000 plus complex objects. Manual conversion at this stage is going to consume senior capacity the program does not have to spare.

Mixed dialects in what remains. If the remaining work is T-SQL only, manual might still be viable. If it is a mix of T-SQL, PL/SQL, BTEQ, and legacy SSIS, accelerator-led is the more sustainable delivery model.

Business logic recovery required. When the remaining objects encode business logic that no one currently on the team fully understands, Reverse Engineer plus senior architect review is far faster and more reliable than more interviews.

Consistency matters for handover. Recovery programs often produce a codebase that has to hand off to a different operating team. Accelerator-driven output is more consistent than hand-converted output, which makes the handover cleaner.

What the recovered program looks like

A recovered migration in year two is not the same shape as the original plan. It is smaller in scope (remaining estate only), more accelerator-heavy in delivery (for the pattern-based and mechanical work), more senior-review-heavy on the outputs, and more honest about the SI relationship.

The specific pattern that has worked in the recovery engagements I see. Recovery baseline in 8 business days. Scope and pricing renegotiation with the SI in the following two weeks. Accelerator-led conversion on the mechanical bulk over the next three to six months. Senior architect review at every deliverable. Cutover waves sequenced with dependency-first plans.

The alternative (letting the current plan continue and hoping year two catches up) is the alternative that most programs try first and most programs stall on further.

Year two program slippage is a recoverable position. It requires accepting that the original plan is not going to catch up, resetting from a source-connected baseline of the remaining estate, and running the recovery with a delivery model that fits what is left rather than what was originally scoped.

The recovery is worth doing. The alternative is a program that finishes 18 months late, over budget, and with a codebase nobody wants to inherit.

Conclusion

A stalled cloud migration will not recover by extending the original plan.
Re-baseline the remaining estate, reset SI terms, and sequence delivery around complexity and dependencies.
With accelerator-led execution and senior review, year-two slippage can become a controlled path to completion.