The roadmap has been approved. It describes a three-year target — coherent, argued, illustrated by a diagram everyone recognises. The plan that comes with it has milestones, a sequence, funding envelopes. The committee signed off, and it was right to: the target is a good one.

Eighteen months later, half the road has been travelled. One domain has moved across, another was deferred in favour of a regulatory deadline, the original sponsor has changed role and their successor has different priorities. The new system serves part of the perimeter, the old one serves the rest, and two master systems now describe the same customers under different rules. A nightly reconciliation, written at the outset “for the duration of the transition”, has become a critical step in daily operations.

Nobody did poor work. Every decision, taken on its own, was defensible. But the organisation now lives in a state nobody designed: not the starting point, not the target, and certainly not a state any architect would have agreed to draw had it been presented as a destination.

This is the ordinary fate of transformation trajectories, and it is explained neither by a lack of method nor by fickle leadership. It is explained by an imbalance in what gets produced: we carefully design a state we will probably not reach, and we do not design at all the states we will actually live in. The likelihood that an organisation stops partway is not an accident to be corrected — it is the expected behaviour, and it belongs in the design assumptions.

Why the target is almost never reached

The gap between the roadmap and what actually happens is not a matter of discipline. It rests on three structural properties better named than lamented.

The target’s horizon exceeds the organisation’s decision horizon. A target is framed over three to five years. Budget trade-offs are made a year at a time, priorities shift each cycle, and the people who approved the target are not necessarily the ones who will fund its final step. A trajectory that assumes continuity of intent over five years makes an assumption that nothing in the real workings of an executive team supports.

The target assumes a world that stands still. It is built from the perimeter, constraints and priorities of the moment. An acquisition, a regulatory change, a shift in the distribution model, and part of the target becomes moot — not because it was badly designed, but because the question changed. The further out the horizon, the more certain that erosion is.

The target is pleasant to approve; the trajectory is costly to own. Approving an end state commits nobody immediately: the debate is about principles, and everyone can find themselves in it. Deciding the sequence, by contrast, names who waits, who pays and who endures a transitional regime. That is a far harder trade-off, which is why it is so often reduced to a strip of milestones with no architectural content.

There is nothing to repair in these three observations. There is only a consequence to draw: the target remains useful, but its status changes. It is not a plan, it is a coherence criterion — the thing that lets you judge whether a decision taken this year moves you closer or further away. The deliverable that decides success is not the target: it is the intermediate states.

What an intermediate state must satisfy

A roadmap milestone is not an architectural state. To deserve the name, an intermediate state must satisfy three properties — and a fourth, less obvious one, which is in fact the most important.

It must be operable. An intermediate state is a system in production, with users, on-call rotas, incidents and audits. So it needs a defined operating model: who gets called at night, where you look when a flow fails, what procedure applies when the two coexisting systems disagree. A transitional state treated as a work site — that is, with no named operations, because “it won’t last” — is the one that will produce the incidents that take longest to resolve.

It must be fundable within one decision cycle. A milestone whose value only materialises at the next milestone does not survive a change of priority. The practical constraint is simple: a step must fit inside the horizon over which an organisation can actually hold an intention, which means a budget cycle, rarely more.

It must carry a benefit of its own. This is the point most often sacrificed, particularly when the trajectory is cut by technical layer. A foundation put in place with no use resting on it is not a first step: it is an investment whose return is entirely deferred, and therefore the first line cut when the year tightens. A step that produces nothing observable for the business will always compete on unfavourable terms with something else.

And it must be a place where you can stop. This is the decisive criterion, and it takes the form of a question to put to every milestone: if everything stopped here, for two years, would the organisation be in a tenable position? If the answer is no, the step is not a state, it is the middle of a ford. That does not forbid it — some transitions have no possible plateau — but it changes what has to be secured: a ford is crossed with a multi-year funding commitment obtained up front, not on the hope that conviction will hold.

The most honest way to test a trajectory is in fact to examine it backwards: take each step and ask not “what does it deliver?” but “what does the organisation look like if it stops here?”. The trajectories that fail this test are the ones that assume everything will run to completion.

The heart of the matter: coexistence regimes

Between the moment a new system enters service and the moment the old one is switched off, there is a period — often long, sometimes permanent — during which two systems carry the same reality. That is where most of a trajectory’s cost and risk sit, and it is almost always the least designed part.

A coexistence regime is not a degraded state you endure. It is an architecture in its own right, and it must answer three questions explicitly.

Who holds the truth, for which object? This is the founding question, and the one rule that admits no exception: at any given moment, for each business object, exactly one system is the system of record. The other holds a copy, which it uses but does not modify. A transitional regime in which both systems accept writes on the same object is not a transition: it is duplication, and it will produce divergences nobody can arbitrate, because no rule was ever written to say which side is right.

The granularity matters: record status is assigned per object, sometimes per attribute — never per application. It is perfectly normal for a new system to be the record for the customer while the old one remains the record for the contract during a phase. What is not normal is for the question to have no written answer.

Which way does data flow, and with what acknowledged latency? One-way synchronisation is a simple mechanism: testable and repairable. Two-way synchronisation is a distributed system with conflict resolution — a problem of an entirely different nature, one you should have decided to take on rather than discovered along the way. And latency is not a technical detail: it determines what a user sees, therefore what they believe, therefore the decisions they make. A propagation delay left unstated becomes an implicit business rule.

How will we know we have left the regime? A coexistence regime needs an observable exit condition, written at the moment it opens: what residual volume, over what perimeter, by what date. Without one, the exit no longer depends on a criterion but on availability — and a team is never available.

Two mechanisms usefully complete the picture. The first is continuous reconciliation: as long as two systems carry the same reality, the gap between them must be measured and published, not discovered at a period close. The second concerns dual entry: where it is imposed on users, it must be recognised for the cost it is — a recurring cost, borne by the business, and generally absent from the budget of the project that created it.

The temporary that settles in

A transitional regime has one formidable property: it works. That is precisely what makes it durable.

The mechanism is the same one that protects the systems nobody ever switches off, but here it acts earlier and more quietly. A gateway, a mapping table, a nightly batch that replays discrepancies: each of these was built fast, documented little, and is claimed by nobody. Its cost is diffuse and its removal has no sponsor, since the expected benefit — “not having to maintain it any more” — appears on no budget line. After a few years, these objects have become the place where part of the business logic actually lives, and nobody can explain any more why a code mapping is written the way it is.

Two rules are enough to contain the phenomenon, provided they are set before the regime opens rather than after.

The first: an intermediate state with no review date is not an intermediate state, it is a target you refuse to own. The wording is deliberately blunt, because it is useful in committee. If you are prepared to live in this state with no deadline, then it is no longer a transition, and it should be designed as a permanent architecture — with the documentation, operations and ownership that implies. Both answers are acceptable; what is not acceptable is failing to choose.

The second: the cost of exiting the transitional regime belongs to the project that opens it, within its scope, its budget and its completion criteria. A project that delivers a new system and leaves behind an unfunded coexistence arrangement has not finished: it has moved part of its bill into operations, where it will be paid without ever having been arbitrated.

These rules have a virtuous side effect, and it may be their main value: they make trajectories that multiply parallel transitional regimes more expensive to propose. That increase is not artificial — it reveals a real cost that the usual sequencing conceals.

Cutting a trajectory

That leaves the practical question: where to start, and along which line to cut.

The most widespread error is cutting by technical layer: foundation first, then data, then uses. It is appealing because it matches the logical order of construction, and it fails regularly because it concentrates all the cost at the start and all the benefit at the end. It produces first steps that are invisible to the business, and therefore fragile at the first trade-off.

The sequencing that holds follows the boundaries of the data. The right cut line is the one where separating old from new costs least to maintain during coexistence — that is, where a system of record can be designated unambiguously and where the necessary exchanges stay one-way. That criterion is far more discriminating than the apparent functional order, and it is almost always examined too late.

Three forms of sequencing occur, with different risk profiles.

By perimeter: one entity, geography or customer segment moves across entirely, the others wait. Coexistence is simple, because the boundary is sharp and an object belongs to one side or the other. The price is duration: the regime lasts as long as the final perimeter has not moved.

By function: the new system takes on one function after another, the old one keeping the rest. Progress is smoother, but coexistence is markedly more demanding, since both systems share the same business objects. This is the form that requires the most rigour in designating the record.

By new flow: the new system takes everything arriving after a given date, the old one keeping the existing stock until natural extinction. Where the business allows it, this is often the least risky form, because it avoids data migration. It has one known drawback: it defers the question of history, which returns when the old system is finally switched off.

That leaves the choice of first step, and it is worth being honest that a real trade-off exists. Starting with what delivers the most visible benefit secures funding for what follows. Starting with what carries the heaviest uncertainty — the data migration, the least understood interface — resolves the doubt while it is still correctable. Both logics are defensible; the only untenable position is starting with what is easy, which produces an early demonstration and pushes every real question past the point of no return.

What architecture must hold

Architecture’s role in a trajectory is not to guarantee that you will reach the end. It is to make sure that every place where you might stop is a place you can live in.

That means keeping the target as a criterion rather than a plan: revising it on a fixed cadence, accepting that part of it becomes moot, rather than defending it for a long time and then abandoning it all at once.

Putting every milestone through the four properties — operable, fundable, carrying its own benefit, and liveable if everything stops — and treating a milestone that satisfies none of them as what it is: a project stage, not an architectural state.

Naming, for each business object and at each step, the system of record, and refusing to open a coexistence regime until that designation is written down.

Placing the exit from the temporary inside the scope of the project that creates it, and maintaining the list of live transitional arrangements, each with a review date and an owner.

And making the cost of coexistence visible: as long as it stays dissolved in operations, long trajectories will look cheaper than they are, and sequencing will keep being decided on criteria other than the ones that matter.

A trajectory is a sequence of liveable states

The roadmap exercise has real value: it forces an intention to be stated and made debatable. But it sustains a stubborn illusion — that of a path travelled in the planned order, by people who stay in agreement long enough.

What distinguishes the transformations that succeed is not the quality of their target. It is that at every point along the way, the organisation was in a state an architect would have agreed to draw. The right question to put to a roadmap is therefore not “where do we want to arrive?” but “what happens if we stop here?”, asked at every step, until no answer is unacceptable.

A target that does not survive its own execution was not an architecture: it was an opinion about the future. What remains are the intermediate states — and they deserve to be designed with the same care as the destination they may never reach.