A programme plans an 18-month coexistence period during which the legacy platform and its replacement both serve production. Roughly what does the coexistence itself cost, on top of building the replacement, and which assumption dominates the estimate?

The assumptions, stated

Take a mid-sized estate: legacy run cost of about £1.4M a year (licences, infrastructure, vendor support, two support staff), a replacement platform ramping from £0 to about £0.5M a year, a delivery team of 20 at a fully loaded £110k, and 9 capabilities that will be live on both sides at some point during the period.

The arithmetic, step by step

1. Legacy run cost retained in full: £1.4M × 1.5 years = £2.1M. It does not taper. Licences are annual and infrastructure cannot be shrunk while the system serves anything, so the saving arrives at decommissioning, not during the migration.
2. New platform run cost, ramping: about 60% of £0.5M × 1.5 = £0.45M.
3. Reconciliation and coexistence engineering: 2 FTE for the period = about £0.33M. Somebody owns the comparison jobs, the drift investigations, the per-entity routing state and the rollback path. This is the line most often absent from the plan and the one that never shrinks.
4. Duplicate change, the dominant term. Any capability live on both sides must take every change twice - a statutory change, a price change, a new field. Assume each dual-live capability costs about 20% of one engineer for the period: 9 × 0.2 × 1.5 × £110k ≈ £0.3M, and that is the optimistic reading. If the business ships a significant change to a dual-live capability, the true multiplier is closer to 1.8 than 1.2 because the two implementations must be proven equivalent as well as built.
5. Duplicate on-call and incident cost: one extra rota and roughly double the triage surface for 18 months. Call it £0.15M and accept the error bar.

Total: roughly £3.3M, with a plausible range of £2.8M to £4.5M, against a build cost that might be £4M. The coexistence is not an overhead on the project; it is comparable to the project.

Which assumption dominates the error

The number of capabilities live on both sides at once, multiplied by the length of the period. The £2.1M legacy run cost is nearly certain and nearly fixed. The duplicate-change term is the one that can be wrong by a factor of three, because it depends on business behaviour nobody controls: if the business ships to dual-live capabilities, every change is paid twice and proven twice.

What the number rules in or out

It rules out "we will decide the sequencing later". Cost is roughly linear in months and superlinear in dual-live capabilities, so the plan should move whole capabilities one at a time and retire each legacy component as soon as its successor is authoritative, rather than migrating broadly and switching off at the end.

It also rules in a specific, fundable action: a freeze on new functionality in capabilities during their own migration window, negotiated per capability and time-boxed. That single decision removes most of the dominating term, and it is a business decision rather than a technical one - which is why it belongs in the business case rather than the design.

When this estimate is the wrong one to produce

When the coexistence is short - under about three months - and single-capability. The fixed costs dominate, the error bars swamp the answer, and the estimate costs more to defend than it informs. It is also the wrong number when the decision has already been made on risk grounds: a regulator requiring a parallel run does not care what it costs, and presenting the cost as an argument against it wastes credibility you will need later.