Eighteen months into a two-year migration off a legacy order system, 40% of traffic is cut over and the business case has evaporated - the vendor contract signed in 2019 whose renewal price justified the programme has been renewed at a lower price. The programme has consumed about 9 engineer-years. Finish it, stop it, or stop at 40%? What is the arithmetic and what is the sequence?

The three numbers, and the one you must not use

R - remaining cost to finish. Not 60% of what you have spent. The tail of a cutover is the awkward integrations, the batch jobs nobody owns and the one customer with a bespoke contract, so estimate R bottom-up from the systems left, as a range, and expect it to be worse per unit of traffic than the first 40% was.

C - carrying cost per month of running both. Duplicate infrastructure, dual writes, the reconciliation job and whoever investigates its mismatches, two on-call rotations, and the change tax: every product change in this domain lands twice for as long as both exist. C is nearly always the number nobody has computed, and it is the number that decides this.

V - cost to revert. Move the 40% back, delete the new system, and absorb whatever product behaviour already depends on it.

The number you must not use is the 9 engineer-years. It is spent in all three branches, so it cannot discriminate between them. Any argument that mentions it is an argument about reputation.

The reasoning

"Stop at 40%" looks like the cautious answer and it is the most expensive one, because it has no end date, so the horizon over which you pay C is unbounded. Compare C x horizon against R: at a C of two engineer-months a month, three years of carrying costs 6 engineer-years, which is on the order of R. Since nobody will commit to ending the dual run, the honest comparison is C x infinity against R, and R wins.

So the defensible answers are finish or revert, and the deciding question is narrow: does the new system have a benefit independent of the vendor contract? Usually it does - lower change tax, a schema the team can reason about, a deployment path that is not a quarterly event. If so, re-baseline the business case on that benefit, state the new benefit in the same unit as R, and finish. If it genuinely does not, revert, and say plainly that the information arrived late.

The sequence, each step reversible

1. Measure C for one month from real invoices and real time records. One month of data ends the argument faster than any model.
2. Re-estimate R bottom-up, as a range, with the hard tail enumerated by name.
3. Write the new business case or the revert decision, naming the benefit and the signal that would falsify it.
4. Freeze new cutovers during steps 1 to 3 - no more than three weeks - so the 40% does not drift to 55% while the decision is open.
5. If finishing: publish the end date for the dual run and make the legacy system's decommissioning a dated deliverable rather than a consequence.
6. If reverting: delete the new system in the same quarter. A half-deleted system is the carrying cost without the option.

The point of no return

The moment a legacy component is decommissioned. Before that, revert is a traffic shift. After it, revert is a rebuild. Order the cutover so that decommissioning happens last and in one deliberate step rather than incidentally.

When this is the wrong answer

When the migration is compliance-driven with a dated obligation. Then R is not optional and the comparison is not between finishing and reverting but between finishing and the penalty. The arithmetic above assumes the programme's benefit is economic and therefore negotiable, and a statutory deadline is neither.