Dual-Run Cost Overlap
also called Migration Cost Hump, Parallel-Running Overlap
The period in any platform migration when both the old and the new system are paid for at once, which raises the run rate before it falls and sets the true date on which a cost business case begins to pay back.
A telemetry migration is signed off on a promise of 40% savings. Four months in, the monthly cost line is 20% higher than when the project started. Nothing has gone wrong: the old vendor is still under a minimum commitment, the new stack's storage and ingest are now running, and an on-call rota has been added for it. The business case described the destination and said nothing about the journey, so the project loses support at exactly the moment it is working.
Dual-run cost overlap is the hump in the cost curve between the first production traffic on the new system and decommissioning of the old one. It appears in vendor exits, datastore migrations, cluster replatforming, region moves and monolith decomposition. It is predictable, and it is left out of most business cases.
Why it matters
A cost business case is read as a promise about a monthly number. If that number rises for two quarters and nobody said it would, the project acquires a credibility problem that its eventual success does not repair. Saying "costs rise by roughly 25% for one to two quarters, then fall to 60% of today" is a stronger position than a single percentage, because it survives contact with the first invoice.
It also changes sequencing. The overlap is bounded on one side by how fast the new system can take traffic safely and on the other by the old system's contract term, so the fastest possible migration is frequently not the cheapest one. Where a commitment floor runs for another 14 months, finishing in month four buys ten months of paying twice.
Implementation patterns
- Model three curves, not one: today's run rate, the overlap period, and the steady state. Put dates on the transitions and name what ends each phase.
- Bound the overlap explicitly in the plan, typically a quarter for a telemetry or datastore move, and treat an overrun as an escalation rather than as drift.
- Delete before you migrate. Unused telemetry series, dead tables, stale indexes and abandoned topics all cost double during the overlap, and removing them may change the decision.
- Pace the cut-over to the contract boundary, landing one or two months before renewal rather than as early as the engineering allows.
- Include the operating cost of the new system, not just its infrastructure: on-call, upgrades, and the engineers who now run a platform instead of using one.
- Report the overlap separately in cost reviews, so a rising line is visibly the plan rather than a surprise.
Industry example
The pattern is visible in every published account of a large storage or database migration from about 2015 onward, and in the engineering blog posts that describe them. The archetype is a consumer file-sync provider moving exabyte-scale storage off a public cloud onto its own hardware over roughly two years: old and new storage paths run in parallel while every object is written twice and verified, so the cost line carries both for the duration. The headline savings such programmes report describe the steady state reached afterwards, not the years in which two storage systems were funded at once and a hardware and operations capability was being built from nothing. Read any published migration saving as the end state and ask separately what the hump cost.
Failure scenarios
- The business case quotes only the steady state, the first invoice rises, and the programme is paused at the point of maximum cost and minimum benefit.
- The migration is rushed to finish early while a commitment floor runs on, so the saving is not realised any sooner and the overlap is longer than it needed to be.
- Waste is migrated rather than deleted, so the overlap pays for it twice.
- The old system is kept "just in case" indefinitely, and the overlap never ends. This is the most common outcome, and it is prevented by naming the decommissioning date and its owner in the same document as the business case.
- The new system's operating cost is omitted, so the steady state is understated and the eventual saving disappoints.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| Long overlap with careful verification | Confidence, reversibility, a real rollback | Months of double running and a visible cost hump |
| Short overlap and a fast cut-over | Less double spend | Less evidence before the irreversible step and a higher chance of an emergency rollback |
| Pace to the contract boundary | Maximum realised saving | The engineering team waits with finished work |
When not to use it
A small system with a clean rollback does not need a modelled overlap — a stateless service moving between clusters costs a rounding error to double-run for a week. The concept earns its place when the duplicated cost is material against the saving being promised, which is typically any migration of a storage, telemetry or data platform, or any move where the old system is under a contractual floor. Do not use the overlap as an argument against migrating: it is a term in the model, not a verdict, and a migration with a two-quarter hump and a three-year payback is still a good decision.
Interview question
Q: You are presenting a migration business case that promises a 40% reduction in platform spend. What must the case say about the first two quarters, and how would you pace the work?
What a strong answer covers: modelling the overlap as its own phase with dates; explaining that the run rate rises before it falls and why that is the plan; deleting unused data before migrating rather than after; pacing the cut-over against the old contract's term end rather than against engineering readiness; and naming the decommissioning date and its owner so the overlap actually closes.
Quick check
Quiz: Why can a migration finishing six months early save no money at all? If the old system is under a minimum commitment, the saving starts at the contract boundary, so finishing early only extends the period in which both systems are paid for.
Flashcard: What does a cost business case most often omit? The overlap: the quarter or two during which both systems run and the monthly line goes up before it comes down, plus the operating cost of the system you now own.