Enterprise architecture has spent two decades getting good at describing target states. Reference architectures, capability maps, domain decompositions and principles are now well understood, and most large organisations have at least one credible picture of where they intend their estate to go. What remains chronically underdeveloped is the connective tissue between today and that picture. Ask to see the target and you will usually be shown a diagram. Ask to see the roadmap and you will often be shown the same diagram with some quarters written next to the boxes.

This matters more now than it did a decade ago for a specific reason: change has become continuous and concurrent. Organisations are no longer executing a single transformation programme with a clean before and after. They are running cloud migration, application rationalisation, data platform consolidation, identity modernisation and regulatory remediation at the same time, across shared systems, with overlapping teams and finite funding. In that environment an unsequenced target is actively dangerous. It invites every programme to optimise for its own end state, and the collisions surface late, in production, as integration breakage, duplicated spend and half-migrated systems that nobody can safely finish or roll back.

The roadmap is what turns a set of independent good intentions into a survivable order of operations. Its job is not to be inspiring. Its job is to guarantee that the estate remains runnable at every step between here and the target, that each step can be paid for, and that the steps compose into the destination rather than merely gesturing at it. When that guarantee is missing, transformation stalls not because the target was wrong but because nobody sequenced the way there.

The core of roadmapping is a simple triad that organisations consistently underinvest in. There is the baseline architecture, the estate as it genuinely is today, including the undocumented integrations and the systems everyone forgot they still depend on. There is the target architecture, the intended end state. And between them there are transition architectures: intermediate states of the estate that are each internally coherent, operable in production, and worth stopping at. The transition architecture is the unit of work that roadmapping actually manufactures, and it is the concept most often skipped.

A transition architecture is not a milestone or a percentage complete. It is a described state of the whole estate at a point in time: which systems exist, which have been decommissioned, which integrations are live, which data flows have moved, and critically whether the business can operate on it. The discipline of defining them forces two questions that vague roadmaps avoid. First, is this intermediate state actually runnable, or does it require two systems of record to be simultaneously authoritative for the same data? Second, is it worth arriving at, or is it a state you pass through so quickly that carrying two operating models for a fortnight costs more than it saves?

Between transition architectures sit work packages: bundles of change that move the estate from one coherent state to the next, each carrying dependencies, a delivery owner and a cost. The roadmap is then the sequencing of these work packages such that dependencies are respected, no transition state is unrunnable, and each phase can be attached to a funding decision. Frameworks such as TOGAF formalise this in their migration planning phases, but the framework is less important than the underlying commitment: you are not planning a project, you are planning a series of operable estates, each one a place the organisation could, in principle, choose to stay.

Several shifts are reshaping the practice. The first is the move from time-boxed to capability-based and value-stream-based sequencing. Older roadmaps sequenced by system or by release train. Current practice sequences by business capability increment: which capabilities improve, in what order, and which architectural work is the minimum needed to unlock each one. This reframes the roadmap around outcomes the business will fund rather than components the architecture team finds tidy, and it makes the phasing legible to people who control budgets.

The second is the normalisation of coexistence patterns as first-class roadmap elements. The strangler pattern, parallel running, and incremental data migration are no longer clever exceptions; they are the default assumption for any estate of consequence, because big-bang cutover has proven too risky at scale. That changes what a roadmap must contain. It now has to specify the coexistence machinery explicitly: the anti-corruption layers, the routing that sends traffic to old or new, the reconciliation that keeps two systems agreeing while both are live. These are not implementation details to be discovered later. They are load-bearing parts of every transition architecture and often the most expensive part of a phase.

The third shift is financial. Portfolio and product funding models, incremental and rolling budgets, and the capital-to-operating cost migration that comes with cloud have all made the funding profile of a roadmap a design constraint rather than an afterthought. A phase that is architecturally elegant but requires a large capital commitment in a year with none available is not a viable phase. Increasingly, roadmapping is done with finance in the room, shaping increments so that each one produces enough realised value or cost avoidance to help fund the next. The roadmap becomes a self-financing sequence rather than a bill presented up front.

A durable roadmap obeys a few principles that separate it from a wish list. The first is that every transition architecture must be runnable. This is the non-negotiable one. At no planned point should the estate depend on a state that cannot actually operate the business: no phase where two systems both believe they own the customer master, no phase where a decommissioned integration has no replacement live. If a transition state is not operable, it is not a transition architecture, it is a cliff.

The second is that dependencies, not dates, drive the sequence. The roadmap should be built as a directed graph of what must precede what, with the critical path made visible, and dates derived from that graph rather than imposed on it. Data dependencies deserve particular respect. Migrating an application whose data has not been untangled from three other systems is where roadmaps quietly break, because data coupling is the dependency people forget to draw.

The third is that decommissioning is a deliverable, not a hope. A roadmap that only adds is not a roadmap, it is an accretion plan. Each phase should name what is being switched off and turned into realised savings, because the retirement of the old system is usually where the business case lives, and it is the step teams are most tempted to defer indefinitely. The fourth is optionality: good roadmaps are sequenced so that early phases keep later choices open and deliver standalone value, so that if funding or priorities shift after phase two, the organisation is left in a coherent state and not stranded mid-leap. Reversibility, or at least a defined fallback for each cutover, is part of the same principle. A phase you cannot safely abandon is a phase you should not start.

The big-bang temptation. The most common failure is a roadmap with too few, too large phases, culminating in a single decisive cutover. It looks efficient on a slide and it concentrates all the risk into one irreversible moment. Estates of any size cannot be re-platformed in one motion without accepting a probability of failure that no responsible organisation should. The fix is smaller, operable increments, even at the cost of temporary coexistence machinery.

The orphaned transition state. A close relative is the roadmap whose intermediate states are not actually runnable. The target is coherent and the start is coherent, but phase three requires two systems of record to be simultaneously authoritative, or leaves a critical interface with no live owner. These roadmaps pass review because reviewers check the endpoints and trust the middle. The discipline of writing down each transition architecture as an operable estate is precisely what catches this.

Funding and delivery divorced. Roadmaps drawn purely by architects, without finance and delivery, phase the work in an order the estate would like but the budget cannot support, or that assumes teams with no slack. Phases then slip not for technical reasons but because the money arrives in a different shape than the plan assumed. The never-decommissioned legacy. Related, and endemic: new systems land, old ones are meant to retire, but retirement is always next quarter. The savings that justified the programme never materialise, and the estate ends up more complex than before, carrying both generations at once. The frozen roadmap. Finally, roadmaps treated as fixed artefacts, published once and defended, rather than living models re-baselined as reality moves. An estate under continuous change invalidates last year's sequence; a roadmap that is not revisited becomes fiction that people nonetheless plan against.

Nashua approaches roadmapping as an exercise in sequencing operable estates, and it starts with an honest baseline rather than the documented one. Before proposing any phasing, we establish what the estate actually is: the real integrations, the true data ownership, the dependencies that live in operations rather than in the architecture repository. A roadmap built on an idealised current state inherits every gap in that idealisation, so the baseline work is not preamble, it is the foundation the sequence stands on.

From there we define transition architectures explicitly. Each intermediate state is described as a whole, operable estate and tested against a single question: could the business run on this, indefinitely, if it had to. Work packages are then defined to move between these states, dependencies are modelled as a graph with the critical path surfaced, and data coupling is treated as a first-class dependency rather than an implementation footnote. We build the sequence around capability increments and value streams, so that each phase maps to an outcome the business recognises and will fund, and so that decommissioning and its realised savings are written into the plan as deliverables rather than aspirations.

We do this with finance and delivery in the room from the start. The funding profile shapes the phasing: increments are sized so that each produces enough value or cost avoidance to help carry the next, capital and operating implications are made explicit, and the plan is stress-tested against the budget and the teams that actually exist. And we hand over the roadmap as a living model, instrumented and re-baselined as delivery proceeds, because the estate keeps moving and a roadmap that cannot move with it is worth little. The output is a fundable, sequenced programme, not a diagram with quarters attached.

The difference Nashua brings is the refusal to let the target substitute for the plan. Many advisors will validate your end state and leave the sequencing to whoever has to build it. The value is in the connective tissue: the operable transition architectures, the dependency graph that respects data as well as systems, the phasing that finance can fund and delivery can staff, and the discipline that keeps decommissioning and its savings on the plan rather than perpetually deferred. That is craft accumulated across many estates, and it is what turns a target into a route the organisation can actually travel while continuing to run.

There is also a practical corollary that changes what the work is permitted to assume. When an engagement calls for a capability that does not yet exist, it need not wait on a procurement cycle or a vendor's roadmap. The Nashua 360 Enterprise Platform is built to accommodate almost any feature at pace, through extreme vibe coding: what is needed is described in plain language and generated quickly, but always within firm architecture principles and under stringent quality assurance, so that speed never comes at the cost of coherence, security or control. The effect is strategic rather than merely convenient. It moves the make-or-buy line, keeps optionality cheap, and lets the architecture follow the strategy rather than the strategy bending to whatever happened to be on a shelf.

What consistently distinguishes the engagements is that the estate stays runnable throughout. Clients do not experience the roadmap as a leap of faith with a risky landing; they experience it as a series of coherent states, each one a place they could safely stop, each one closer to the target, each one paid for by the value the last one released. That is the point of roadmapping done properly. Not a more beautiful destination, but a sequenced, fundable path there that never asks the business to bet everything on a single cutover, and never leaves the estate stranded in a state it cannot operate. Nashua's contribution is to make that path real, and to keep it real as the ground shifts underneath it.