Transition Architecture: The Discipline Everyone Skips
Companion to LinkedIn Post 2 - “The Transition State Is the Real Architecture”
In the first post in this series, I argued that a target-state diagram has never modernized anything by itself. A future state can be correct, elegant, and strategically aligned - and still change nothing about how systems are built or operated.
The reason is simple. Organizations do not leap from where they are to where they’ve drawn. They pass through intermediate states - often for months or years - while real customers, real systems, real budgets, and real operations teams keep depending on them.
That messy middle is where Enterprise Architecture either becomes useful or becomes theater.
There’s a name for the architecture of that middle. Some methods call them increments, migration waves, or capability releases. TOGAF, the most widely used enterprise architecture framework, calls them transition architectures and treats designing them as part of the core job rather than an afterthought. You don’t need the vocabulary to recognize the idea: an intermediate state the business actually operates on while the transformation is still incomplete.
And that word - operate - is the whole test.
The simplest question you can ask of any intermediate state is this: can the business run on it without heroic effort?
If the answer is no, you don’t have a transition architecture. You have a migration step. The two are not the same thing, and confusing them is where modernization programs quietly go wrong.
First, an assumption
This post assumes the upstream work is good.
A transition can only be as coherent as the architecture feeding it. If the vision is vague, the business and data dependencies are unmapped, and the technology standards don’t exist, no amount of clever sequencing will save you - the transition inherits that fog and amplifies it. Getting that upstream clarity right is a discipline of its own, and worth its own post.
Here, I want to assume it’s been done well and focus on the part that even strong programs skip: turning that clarity into intermediate states you can actually run.
A transition state is not a project milestone
A project milestone tells you that something happened. A transition architecture tells you what kind of enterprise you’re operating after it happens.
That distinction matters more than it sounds.
When a migration wave finishes, the milestone says “Wave 2 complete.” The transition architecture answers the harder questions:
- Which applications now run on cloud identity, and which still depend on the legacy directory?
- Which data flows still cross the hybrid boundary?
- Which network paths were meant to be temporary - and are quietly becoming permanent?
- Which controls does the platform enforce, and which still rely on someone remembering?
- Who operates this environment on Monday morning?
- What can finally be retired?
Without those answers, a transition is just motion. And motion can look productive while making the architecture worse. The most expensive transformations I’ve seen didn’t fail because nobody knew the target state. They failed because every step toward it added exceptions, duplicated controls, and ambiguous ownership - until the “temporary” state became the permanent one nobody could afford to clean up.
Run the test again: could the business operate on that state without heroics? If each wave makes that harder to answer yes, you’re accumulating debt, not making progress.
What a transition architecture has to decide
A transition architecture isn’t a smaller version of the target state. It’s a coherent, temporary, operable architecture with its own rules. For every one, I want to know at least eight things.
1. What business capability changes? If a transition state doesn’t improve, protect, or unlock a business capability, it’s hard to justify. Risk reduction, cost control, faster delivery, regulatory readiness, resilience - pick one, but make it explicit.
2. What systems move together? Application and data dependencies define the real migration unit. Moving one database or service in isolation can look simpler on a plan and create a worse operational state in reality.
3. What identity model is active? Hybrid states fail at identity more than anywhere else. Users, services, admins, secrets, and audit trails span old and new. If identity is vague, everything downstream is fragile.
4. What networking is temporary - and what replaces it? Temporary network paths have a habit of becoming permanent. Name which routes, firewall rules, and DNS patterns are time-boxed, and what retires them.
5. What platform standards apply now? You can’t wait for the target state to introduce standards. Landing zones, deployment patterns, observability, tagging, and policy enforcement have to mature in increments.
6. Who operates this state? Every transition state needs an operating model. If the answer is “the project team, for now,” that’s a risk, not a model. Someone owns incidents, changes, cost, access, and recovery.
7. What gets retired? Modernization without retirement is just accumulation. Each state should remove something - a legacy integration, an old environment, a manual control, a brittle pipeline.
8. What does this state prove? A good transition state reduces uncertainty. It validates a pattern, retires a risk, or builds confidence for the next wave. If it proves nothing, it’s probably just activity.
Notice how few of these are about technology. Most are about ownership, risk, and money - which is exactly why the transition is architecture and not project management.
A worked example: two states, not one
In the last post I used the migration of 1,200+ SQL Server databases and 64 applications toward Azure to make a point: it was never really a database problem. The target state fit on a slide - governed landing zones, the right database services, secure connectivity, a cleaner estate. The hard part was the sequence.
I won’t re-litigate that here. What’s more instructive is what those eight questions look like across two consecutive transition states - because the gap between them is where the design actually lives. Call them State A and State B.
State A - the first production wave. The goal isn’t scale; it’s proof. You move a small set of applications whose databases share a blast radius, so nothing gets split mid-transaction across the hybrid boundary. Identity is deliberately hybrid: the new workloads authenticate against the cloud directory but still trust the on-prem one, because cutting that cord now would be too much change at once. Networking leans on a temporary, explicitly time-boxed link back to the data center. The operating model is awkward but staffed - the on-prem DBAs keep their runbooks while a small cloud team shadows them. What State A proves is the landing zone, the backup story, and the connectivity pattern, under real load, with a population small enough to recover if any of it is wrong.
Could the business run on State A? Yes - clumsily, with two identity providers and a network path you’ve promised to kill. But yes. That’s what makes it an architecture and not just a step.
State B - the next wave inherits the proof. Now the questions change. The landing zone is no longer hypothetical, so new waves adopt it as a standard instead of debating it as a proposal. The temporary link from State A is either promoted to intentional design or scheduled for retirement - and naming which is a deliberate decision, not a default. Identity starts shifting its center of gravity toward the cloud directory, so State B can begin retiring the on-prem trust for the workloads that no longer need it. The operating model tilts: the cloud team now leads, the DBAs shadow. And critically, State B retires something State A couldn’t - a legacy integration, an old environment - so the estate is measurably simpler than before, not just larger.
The architecture isn’t State A or State B. It’s the delta between them: what got proven, what got promoted from temporary to permanent, what got retired, and who’s holding the pager when each one goes live. Miss that delta and you get the most common failure mode in modernization - a dozen “completed” waves that somehow leave the estate more complex than they found it.
Governance belongs in the transition, not after it
One more failure pattern worth naming: deferring governance until the target state is “ready.”
It sounds practical. It’s usually expensive. If teams build freely during the transition, the future platform inherits exactly the disorder the transformation was meant to fix. Cloud accounts multiply. Network exceptions pile up. Deployment patterns diverge. Every temporary workaround quietly acquires a business owner who now depends on it.
Governance doesn’t have to mean slow approvals or architecture theater. In a good transition architecture, it’s built into the path:
- Policies that define what teams can provision
- Golden paths that make the preferred pattern easier than the exception
- Decision records for the choices that need traceability
- Exceptions with named owners and expiration dates
- Funding boundaries that stop every transition cost from becoming permanent run cost
The goal isn’t to freeze delivery. It’s to keep the transition from hardening into a new unmanaged architecture.
The takeaway
Enterprises spend long stretches in the middle. Hybrid identity, split data estates, parallel platforms, mixed operating models - these aren’t edge cases. They’re the normal lived reality of modernization. The job of Enterprise Architecture isn’t to pretend that messy middle away. It’s to make it coherent enough to operate, govern, fund, and improve.
So if you’re leading or advising a modernization program, don’t only ask “what’s the target state?”
Ask the question that actually decides whether you reach it:
What’s the next state we can actually run, what does it prove, and what has to be true before we move to the one after it?
If you can answer that, you have an architecture. If you can’t, you have a drawing with a deadline.
Next in the series: Platform Engineering as Enterprise Architecture - why architects who ignore the platform get disconnected from delivery.