Transition & Roadmap Planning

Transition planning maps the path from today’s system to the target design in safe, deployable phases — the architecture has to describe the journey, not just the destination.

At a glance

• What it is: Breaking the move from current state to target design into a sequence of phases that can each be delivered and validated independently, rather than one all-at-once cutover.
• Why it matters: most real solutions are delivered incrementally; a design that only describes the end state gives a project team no safe way to get there.
• For developers: this is the plan behind why a migration ships as “add the new path alongside the old one, then switch traffic gradually” instead of a single risky big-bang release.
• When to use it: once a target design exists (from Component & Integration Design) and known risks (from Risk & Constraint Management) are documented.
• When not to use it: for a brand-new solution with no current state to transition from — that’s just a build plan, not a transition.
• Prerequisites: a target component design and a documented risk register.

Mental model

flowchart LR
    A[Current state] --> B[Phase 1: Strangle]
    B --> C[Phase 2: Dual-write / parallel run]
    C --> D[Phase 3: Cutover]
    D --> E[Target state]

Each phase is independently deployable and reversible if something goes wrong — the design isn’t “done” once the target state is drawn, it’s done once there’s a safe path to reach it.

Step-by-step walkthrough

1. Confirm the current state and the target design are both clearly understood.
2. Identify a way to introduce the target design alongside the current one, rather than replacing it outright (e.g. the strangler pattern: route new functionality to the new system while the old one still handles the rest).
3. Plan a period where both old and new run in parallel, if data consistency needs validating before full cutover.
4. Define the cutover step and, critically, a rollback path if the new system doesn’t perform as expected.
5. Sequence the phases so each is independently valuable and safe to pause on if priorities shift.

Worked example

A logistics company’s 10-year-old monolith blocks independent deployment of its shipment-tracking feature.

• Input: target design extracts shipment tracking into its own service behind an API gateway, but the monolith currently owns that logic and its data.
• Process: rather than rewriting the whole monolith, the team applies the strangler pattern — new tracking requests are routed to the new service first, while the monolith keeps handling everything else; a dual-write phase keeps both systems’ tracking data in sync while confidence is built; only once validated does traffic fully cut over.
• Output: a three-phase roadmap (strangle the module, dual-write and validate, cut over and decommission the old logic) instead of a single risky big-bang rewrite, with a rollback option available at every phase until the final cutover.

Common use cases

Use case	When to use	Notes
Extracting a feature from a monolith	Feature needs independent deployment or scaling	The strangler pattern lets old and new coexist during transition
Replacing a vendor or platform	Switching without an acceptable downtime window	Dual-run and validate before cutover, keep a rollback path
Data migration to a new store	Correctness must be proven before relying on the new store	Run reads/writes against both stores in parallel before switching reads over

Advanced details

• Every phase needs a rollback path until the final cutover: a transition plan without a way back isn’t actually reducing risk, it’s just spreading a big-bang cutover across a longer timeline.
• Dual-write phases add real complexity: keeping two systems consistent temporarily is itself a design problem — plan for reconciliation, not just hope they stay in sync.
• Decommission the old path explicitly: a transition isn’t complete until the old system or code path is actually retired, not just unused.
• This maps to TOGAF ADM Phases E and F: identifying viable transition options (like choosing the strangler pattern over a rewrite) is Phase E — Opportunities & Solutions; sequencing them into phases with dependencies and rollback paths is Phase F — Migration Planning, which produces the actual Architecture Roadmap.

Quick reference

Term	Meaning
Transition architecture	An intermediate state between the current baseline and the target design
Strangler pattern	Gradually routing functionality to a new system while the old one still handles the rest, until it can be retired
Dual-write / parallel run	Running old and new systems simultaneously to validate correctness before full cutover
Rollback path	A defined way to revert to the previous state if a phase doesn’t perform as expected
TOGAF ADM Phase E / F	Opportunities & Solutions (identifying transition options) and Migration Planning (sequencing them into a roadmap)

Troubleshooting

Symptom	Likely cause	Fix
Migration stalls partway with no safe way forward or back	No transition plan existed — only a target design	Define phases with a rollback path for each before starting the migration
Data inconsistency discovered after cutover	Dual-write phase wasn’t validated before switching over	Add reconciliation checks during parallel run, and don’t cut over until they pass
Old system never gets decommissioned	Transition plan didn’t include an explicit decommission step	Add decommissioning as its own tracked phase, not an assumed side effect

Check your understanding

• Why does a transition plan need a rollback path at each phase, not just a description of the target state?
• Take a migration you’ve been part of and identify which phase (strangle, dual-write, cutover) it was in, and what the rollback path was.

Related pages

Part of Introduction to Solution Architecture. Follows Risk & Constraint Management and typically the last step before build begins. See also the Glossary.