01
Short answer
Migration costs extend beyond the target platform to dual running, reconciliation, specialist support, unresolved exceptions, and work delayed while both platforms remain active. Price each workload through shutdown rather than treating target go-live as completion.
There is a shape to stalled migrations that repeats across organizations almost exactly. The first waves go well, because the estate decomposes nicely at the top and the team is staffed and excited. Momentum carries the program to roughly 70 percent. Then it pauses, sometimes officially, usually not. The remaining 30 percent is the hardest estate, the easy savings are already booked, and the cost of standing still settles in as the new operating baseline.
Two platforms. Two support contracts. Two on-call rotations. A reconciliation bridge someone built "temporarily" eighteen months ago that three reports now depend on. And a queue of workloads that failed conversion and are waiting, aging, owned by no one in particular.
That operating baseline emerged gradually rather than through an explicit decision. Because the costs live in existing run-rate line items rather than the migration project's budget, the business case for finishing never quite gets made.
02
The lines the budget misses
If you are costing a migration, or defending one that has stalled, here is where the real money hides.
Dual running is the obvious one and still gets underestimated. Both platforms for the entire overlap, including the people. The overlap is always planned to be shorter than it turns out to be.
Reconciliation is sneakier. Every report that spans the cutover boundary needs a source-of-truth decision, and while both systems hold overlapping history, someone reconciles them by hand each month. That labor shows up as "analyst time," not as migration cost, and it grows with every month of overlap rather than shrinking.
The exception backlog is an inventory of debt with a carrying cost. Workloads that failed conversion accumulate as pending items; the older they get, the more the knowledge needed to convert them decays, because the engineers who understood the legacy system leave while the system stays.
Deferred capability is the line almost never written down. The modern analytics, the AI work, the new product reporting that cannot start because its foundation is in transit. Name one such initiative with its business value and put it in the case. The number is real even when it is uncomfortable to state.
03
Pricing one more quarter
The method I use with customers is blunt. Price one more quarter of the current state: both platforms' run costs including people, reconciliation hours sampled from the teams actually doing the bridging, the exception backlog with age distribution, and that one named deferred initiative. Then price the next migration wave.
When standing still for a quarter costs more than the wave, the wave funds itself. When it does not, you have learned something equally valuable: the remainder may genuinely be cheaper to keep than to move.
Either way the decision now rests on numbers instead of momentum or embarrassment. Refresh it quarterly with the estate owner in the room, because both sides of that comparison move.
04
When staying put is the right call
Sometimes it is. If the unmigrated remainder is stable, rarely changed, and cheap to run, leaving it alone can beat moving it. A decades-old archive that compliance still requires and nobody queries is a fine permanent resident of the old platform.
The distinction is a number, not a feeling. Stable, low-change, cheap to run: keep it, in writing, with an owner. Expensive, actively changing, or blocking work people are waiting on: it belongs in a wave. What poisons estates is the unexamined remainder, the one nobody has priced since the program paused.
05
Designing waves that finish
The structural fix for stalling is to make the remaining waves smaller, not the program longer. Decompose until a wave is a few weeks of work, and define its completion as a shutdown, not a go-live. A wave that ends with a workload migrated and both versions running has produced overlap, which is cost. A wave that ends with the legacy workload decommissioned has produced the pull that keeps the program moving.
Wave plans should carry their reconciliation result and rollback path with them, so each completion is a checkable fact rather than a demo. The migration economics guide on this site covers the method in detail, and the PeopleStrong and Google Cloud migration case studies show the shutdown-anchored pattern running in production.
06
Build the cost model by workload
One program total hides which workloads are producing value and which ones are extending overlap. Give every workload a row with its current run cost, target run cost, people needed during parallel operation, dependencies, validation owner, cutover date, and shutdown date. Update the row at the end of each wave.
Separate costs into four groups. The old platform includes infrastructure, licenses, support contracts, operational staff, and specialist vendors. The new platform includes the same items plus migration tools and temporary capacity. Parallel operation includes duplicate pipelines, reconciliation, extra monitoring, and business review. Delay cost covers initiatives that cannot start while the team is occupied or the target data remains incomplete.
Do not spread shared cost evenly. A workload that forces an old database license to remain active carries that renewal. A final pipeline requiring a specialist contractor carries the extension. This assignment makes sequence decisions visible: moving one awkward dependency earlier can remove a large fixed cost from every later month.
Review actual spend against the model after each cutover. Replace estimates with invoices, observed staff time, and measured reconciliation work. Forecast the next 90 days from the remaining workloads rather than from the original program percentage. “Eighty percent migrated” says little when the final twenty percent holds most dependencies.
07
Define shutdown before cutover
A cutover plan explains how traffic moves to the new system. A shutdown plan explains how the old one stops costing money. The workload is complete only when both plans have passed.
Before cutover, name the old jobs to disable, accounts to close, storage to retain, contracts to change, monitoring to remove, and reports that must point at the new source. Assign each item to a person with a date. Include business owners because shadow spreadsheets and manually exported files often keep the old path alive after engineering believes it is gone.
Set the observation period in advance. During that period, compare outputs, handle exceptions, and rehearse reversal without adding new features to the old path. At the end, a named owner accepts the reconciliation results and authorizes shutdown. Extending the period requires a specific failed check or unresolved risk, not general discomfort.
Archive only what law or operations require, with a tested way to retrieve it. Read-only access to an entire live platform is usually continued operation under a softer name. Export the required history, verify it, document the access path, and remove compute, scheduled work, and write credentials.
08
Price delay as a decision
Migration reviews often treat delay as a schedule variance. Finance should see it as a new purchase: another month of old-platform spend, another month of duplicated work, and another month before the blocked initiative can start. Put that price beside the reason for delay and the person who can resolve it.
Some delays are worth buying. A reconciliation failure, missing regulatory records, or untested rollback can cost more than another month of overlap. Others persist because no one has authority to accept a small discrepancy or retire a report. Pricing the extension separates safety work from indecision.
09
Use an exit pack for every wave
Keep the exit pack small enough to review: reconciled totals for named business measures, latency and volume at production load, open exceptions by severity, rollback exercise results, user acceptance, and confirmation that the old jobs are disabled. The program owner signs the wave only when that pack matches its exit criteria.
The same pack supports incident response after shutdown. If a discrepancy appears later, the team can see what was compared, which version ran, and who accepted the result. That reduces pressure to keep both systems live as an informal safety net.
10
Related
Where to read next on the same subject.