How would you sequence a two-year modernisation so that cancelling it after six months still leaves the organisation better off?

What is being tested

Whether you sequence for incremental value, which is the property that makes a long programme survivable.

The premise to accept

Multi-year architecture programmes are frequently cancelled. Priorities change, sponsors move, budgets are reallocated. A programme whose value arrives at the end will lose everything when that happens.

So sequencing for incremental value is not a preference; it is the risk mitigation that makes the programme viable at all. It is the same reasoning behind strangler-fig migration.

The sequencing

1. Foundations that unblock the most, first. A deployment pipeline, identity, observability, a data platform. These pay back across everything after them, and they retain their value even if nothing else proceeds — which is exactly the property required.

2. Then the highest pain-to-effort ratio. An early visible win buys credibility for the harder work later, and credibility is the currency the programme runs on. If month six produces nothing anyone can point at, month twelve will not be funded.

3. Route on a business dimension. Migrate by capability, geography or customer segment rather than by a technical layer, so each slice is comprehensible to non-engineers and rollback is explicable.

4. Decommission as you go. Budget it explicitly as work. Otherwise you run both old and new indefinitely, which is strictly worse than either alone and is the characteristic failure of migration programmes.

5. Never a big-bang cutover. Every step should be reversible and independently valuable.

The test to apply to every step

"If we stopped here, are we better off than before we started?"

If the answer is no for any step, that step is too large or is sequenced wrongly. The classic failure is a step that migrates the data but not the consumers, leaving synchronisation to maintain and no benefit realised.

What to put on the roadmap

Outcomes and capabilities against rough horizons — now, next, later — rather than precise dates for work eighteen months out, which are fiction and are treated as commitments.

Include what is not being done, and why, so the roadmap is not read as a complete plan and the deprioritisation is explicit.

Keeping it honest

Revisit quarterly. State the assumptions, so it is clear which changes would invalidate the sequence. Track what was actually delivered against it — which is the only way anyone learns to sequence better.

What a strong answer adds

The primary metric: "capabilities remaining on legacy", not "capabilities delivered on new". The first measures progress toward finishing; the second can rise indefinitely while the old system stays alive and the programme quietly becomes permanent.