Why do enterprise architects usually insert one or more intermediate 'transition architectures' between the baseline and target states instead of migrating directly, and what determines how many are needed?

## What a transition architecture is A transition architecture is a fully specified, internally consistent architectural state that sits between the current baseline and the eventual target — critically, it is **not** a half-finished version of the target but a legitimate architecture that could, in principle, be operated on its own for an extended period if circumstances forced a pause. To build one, an architect takes the **work packages** produced by gap analysis and groups a coherent subset of them into an **increment** — a bundle of changes that together: - move specific business capabilities forward, - can be deployed and validated independently, - and leaves every component in the resulting state actually working together, rather than mid-cutover. Multiple transition architectures are then chained — Transition Architecture 1 becomes the new baseline for defining Transition Architecture 2, and so on — until the chain reaches the target. Each one is documented with the same rigor as the baseline and target, and mapped to a roadmap increment with a **timeframe**, **funding source**, and **business value statement**. ## Why increments rather than one cutover This exists because almost no non-trivial transformation can be delivered, funded, or safely validated in a single release. A direct baseline-to-target cutover concentrates all of the program's risk into one event: if something goes wrong, there is no coherent intermediate state to fall back to short of a full rollback, which for large data or platform migrations may not even be technically possible. Transition architectures break that risk into a sequence of smaller, reversible steps, each of which delivers a slice of business value on its own — which matters because: - most organizations fund transformation incrementally rather than as one multi-year lump sum, and - stakeholders need visible progress and checkpoints to keep sponsoring a multi-year program. ## How many, and how big The number and size of transition architectures is a direct trade-off between **delivery speed and risk**. | Increment shape | What it buys, and what it costs | |---|---| | **Fewer, larger increments** | mean less overhead spent designing and validating intermediate states and a shorter total calendar time to the target, but each increment carries more risk and a bigger blast radius if it fails, and stakeholders go longer between visible milestones | | **More, smaller increments** | reduce risk per step and produce more frequent proof points, but add coordination and design overhead — every transition state needs its own consistency checks, interfaces, and often bridging technology (adapters, dual-write layers, feature flags) that will themselves be thrown away once the target is reached, which is pure transitional cost with no long-term payoff | The right number depends on the size of the gap, the organization's change capacity, the release/funding cadence, and how reversible each step needs to be. ## Failure modes 1. The most common failure is treating a transition architecture as merely 'the target, but not finished yet' rather than designing it as its own coherent state — this shows up as broken integrations, undocumented temporary workarounds, and operational teams unable to support a state nobody actually designed to be supportable. 2. A second failure is picking too few transition states for a program's actual risk profile, effectively doing a big-bang migration in slow motion — all the coordination overhead of a phased approach with none of its risk-reduction benefit. 3. A third is the opposite: over-decomposing into so many tiny increments that the bridging technology required becomes a project of its own, and the organization spends more effort maintaining transitional plumbing than moving toward the target. 4. A fourth, common in practice, is a transition architecture that quietly becomes permanent — funding or attention moves to the next priority before the final increment ships, and the 'temporary' bridging state is still running years later. ## A worked example A telecom operator replacing a monolithic CRM with a modular, API-first platform might define three transition architectures over two years rather than a single cutover. 1. **Transition Architecture 1** stands up the new platform's customer-profile service alongside the legacy monolith, with the monolith remaining the system of record and the new service populated via one-way replication — a coherent, operable state on its own, deployed as one funded increment. 2. **Transition Architecture 2** flips the system of record for customer profiles to the new platform while the legacy monolith still owns billing and support-ticket workflows, requiring a synchronization bridge back to the monolith — again a complete, independently valid state. 3. **Transition Architecture 3** migrates billing onto the new platform and retires the synchronization bridge, arriving at the target. Each transition is separately fundable, separately rollback-able, and delivers a slice of value rather than the organization betting an entire budget cycle on one irreversible cutover weekend.