Sequencing decides when the benefit arrives, not whether

Modernization business cases are usually argued on total cost and end-state capability. Both are the wrong variables to optimise. The one that determines whether the programme survives contact with a budget cycle is when the first real benefit lands, and that is decided almost entirely by sequencing — which is a choice, not a constraint.

The single-cutover trap

The default plan is to build the replacement, then switch. It is easy to explain and easy to fund. It also concentrates every risk at the single moment when the team has the least remaining budget, the least remaining patience, and the most accumulated unknowns. Benefit is zero until the cutover, so a programme cancelled at eighty per cent complete has delivered nothing at all.

The alternative is to sequence so that each tranche delivers on its own terms and leaves a working system behind it. That constraint sounds like it should cost more. Usually it costs a little more in total and dramatically less in risk, because it converts one large irreversible decision into several small reversible ones.

A programme cancelled at eighty per cent complete has delivered nothing. Sequencing is what stops that being possible.

Interfaces first

The tranche that most often unlocks the rest is not a replacement of anything. It is an interface layer in front of the existing system — a stable, documented contract that new consumers can build against while the thing behind it is still the original.

This is unglamorous and rarely in the original plan. It is also what turns a monolithic replacement into a sequence, because once consumers depend on the contract rather than the system, the system behind it can be replaced in pieces without coordinating every downstream team at once. It is the difference between a migration that needs one heroic weekend and one that proceeds in ordinary working hours.

The interfaces nobody wrote down

Every long-lived system has dependencies that exist in practice but not in documentation: a nightly export somebody built a process around, a database another team reads directly, a file drop that feeds a regulatory return. These surface during migration, at the point where accommodating them is most expensive and least expected.

Discovery therefore has to include observation, not only documentation review — what the system does is a better source than what it was specified to do. Query logs, network flows, and file system activity routinely reveal consumers nobody in the room knew existed. Finding them in week three is a planning input. Finding them in month nine is a crisis.

Reversibility is a requirement, not a nicety

The ability to roll back is usually traded away early for schedule, then reconstructed expensively late. Treating it as a first-class requirement changes the architecture: dual-running, shadow reads, and reconciliation are cheap when designed in and close to impossible to retrofit.

This is also what makes each tranche a small decision rather than a large one. A change you can reverse in an afternoon needs a different approval than one you cannot, which means it can be approved by someone closer to the work. Reversibility does not only reduce risk; it moves decisions down the hierarchy, which is where most of the speed comes from.

Sequencing is also how the run cost comes down

Under a single cutover, the organization pays for both estates for the entire programme and retires nothing until the end. Under a tranched sequence, each tranche can decommission something — a server, a licence, an integration, a support contract, a manual reconciliation somebody performs monthly.

That changes the funding shape as much as the risk profile. A programme that retires cost as it proceeds partially funds its own later tranches and is far harder to cancel, because cancelling it means keeping costs that have already been shown to be avoidable. Make the decommission list an explicit deliverable of each tranche, with the associated run cost named, and the business case stops depending on benefits that arrive after the next budget cycle.

The corollary is that a tranche which retires nothing deserves scrutiny. It may still be correct — interface work often retires nothing directly — but it should be justified as an enabler of the tranches that do, not as value in itself.

Why this matters for AI specifically

Almost every organization that concluded it was "not ready for AI" was describing an integration problem rather than an AI one. The data existed but was unreachable, the systems of record had no stable interface, and there was nowhere to put a new capability without touching something fragile.

The interface-first tranche is the same work that makes AI adoption possible later. That is worth putting in the business case explicitly, because it changes modernization from a cost of keeping the lights on into the prerequisite for the thing the board is already asking about.