Transition Architecture / Migration Plan
A plan describing the intermediate architectural states between the current state and target state, showing how the organisation will migrate from one to the other in manageable, low-risk increments.
Purpose
Transition architectures break a large transformation into achievable steps, each delivering value while moving towards the target state. They manage risk by ensuring the system remains operational and stable during migration.
When to Use
Create after the target state architecture is defined and before detailed project planning begins. Essential for programmes involving legacy migration, platform changes, or significant architectural evolution.
How to Build
Define the current state architecture clearly — you cannot plan a journey without knowing the starting point.
Identify the major changes needed to reach the target state. Group these into logical increments that can be delivered independently and each leave the system in a stable, operational state.
For each transition state, document: what changes, what stays the same, what temporary scaffolding is needed (e.g., data synchronisation, API adapters), and what can be decommissioned.
Sequence the transitions considering: dependencies, risk, value delivery, and resource availability. Earlier transitions should reduce risk and deliver learning.
Plan the cutover approach for each transition: big bang, phased rollout, canary deployment, or strangler fig pattern.
Tips
- Each transition state must be stable and operational — never plan a state where the system is broken.
- Use the Strangler Fig pattern for legacy replacement — gradually route traffic to the new system.
- Plan for rollback at each transition — what happens if the new state has problems?
- Include data migration strategy for each transition — this is often the hardest part.
- Communicate transition states to operations teams early — they need to support each state.
Common Mistakes
- Planning transitions that are too large, creating big-bang risk.
- Not planning for coexistence — old and new systems often need to run in parallel.
- Ignoring data migration complexity and the need for data synchronisation during transition.
- Not planning rollback strategies for each transition.
- Underestimating the operational overhead of supporting multiple architectural states simultaneously.
Government Context
In UK government, transition architectures are essential for legacy modernisation programmes. The government's commitment to reducing legacy IT risk means many departments are planning multi-year migrations. Transition plans should account for spending review cycles, parliamentary recesses (for ministerial approvals), and the GDS service assessment process at each phase gate.