Abandonment Arithmetic

A migration off a legacy order system is eighteen months into a two-year plan, with 40% of traffic cut over. Then the business case evaporates: the vendor contract whose 2019 renewal price justified the programme renews cheaply. About nine engineer-years have gone in.

Every meeting will be about those nine engineer-years, and they are the one number that cannot help, because they are spent identically in every available future. The uncomfortable finding is that the option the room prefers - stop here, keep both, decide later - is the most expensive one.

Why it matters

Part-finished programmes are the dominant hidden cost in a mature estate, and they persist because stopping requires a decision while continuing does not. The sunk-cost framing is actively wrong rather than merely unhelpful: an argument built on "we have invested nine engineer-years" selects the option that justifies the past, and the past is not an input. Three forward-looking numbers change which option wins in a real share of cases.

Implementation patterns

• R - remaining cost to finish, bottom-up from what is left, as a range. Never as a proportion of spend: the tail is the awkward integrations, the unowned batch jobs and the bespoke customer contract, so cost per unit of remaining traffic exceeds the first 40%.
• C - carrying cost per month of both. Duplicate infrastructure, dual writes, the reconciliation job and whoever investigates its mismatches, two rotations, and the change tax: every product change in the domain lands twice while both exist. Measure it from one real month of invoices and time records.
• V - cost to revert: move the traffic back, delete the new system, absorb whatever depends on it.
• Price the middle option honestly. "Stop at 40%" has no end date, so C runs over an unbounded horizon: at two engineer-months a month, three years of carrying is six engineer-years, already the order of R and with no benefit delivered.
• Then ask the question that decides finish against revert: does the new system carry a benefit independent of the original case - lower change tax, a schema the team can reason about? If yes, re-baseline on that benefit in the same unit as R and finish. If no, revert this quarter.

Industry example

The best-documented instances are the migrations that finished and published their sequencing, because they show what R's tail looks like. The large sharding and partitioning programmes written up between 2021 and 2024 were run with a dated end and reversible stages, and the accounts treat completion as the deliverable rather than the cut-over percentage. The inverse case is hard to cite, which is itself evidence: abandonment is decided so rarely and recorded so seldom that there is almost no public record of it. Where an estate runs two generations of one system, the history is usually the absence of a decision to stop.

Failure scenarios

• The permanent dual run. No end date, so C is paid indefinitely and eventually exceeds R several times over.
• R estimated as a proportion, so 60% of traffic priced at 60% of spend understates the tail and produces a second stall at 85%.
• C never computed, so the comparison is a number against a feeling and the feeling wins.
• Decommissioning early for a quick win, removing the revert option and turning a traffic shift into a rebuild.
• The arithmetic bent to a predetermined answer, with R's range narrowed to the supportive end.

Trade-offs

What it buys: a decision where there was drift, with three auditable numbers. Exposing C is valuable on its own: several estates discover that part-finished work costs more to carry than the work they are planning next.

What it pays: computing C publicly attributes a cost to a programme somebody sponsored, and reverting reads as failure to people told the migration was on track. The arithmetic makes the alternative visible, not cheaper.

When not to use it

When the obligation is dated and statutory. A compliance-driven migration compares R against the penalty, not against reverting, because the benefit is not negotiable.

And when measuring costs more than deciding. A two-month piece of work at 40% does not justify a month of instrumenting C. The practice earns its overhead on programmes measured in engineer-years.

Interview question

Q: "You are eighteen months into a two-year migration, 40% cut over, and the business case has gone. The sponsor wants to pause and revisit next year. What do you measure and what do you recommend?"

What a strong answer covers: naming the three numbers and excluding spend to date because it is identical across options. Pricing the pause as an unbounded horizon on C rather than as a neutral choice. Estimating R bottom-up as a range. Narrowing to finish-or-revert on whether the new system has an independent benefit, and keeping decommissioning last so revert stays a traffic shift.

Quick check

Quiz: A programme is 40% cut over with nine engineer-years spent and no business case. Which three costs decide it? Remaining cost to finish, monthly carrying cost of both and cost to revert - the spend to date is identical in every branch, and pausing has no end date so C runs forever.

Flashcard: Why is a dual run's carrying cost larger than teams expect? - It includes duplicate infrastructure, dual writes, reconciliation investigation, two rotations and a change tax where every product change lands twice.