In TOGAF's ADM, Phase E (Opportunities & Solutions) and Phase F (Migration Planning) are separate phases even though both deal with turning architecture gaps into implementation work. What's the actual division of labor between them, and what breaks if a team collapses them into a single 'planning' step?

## Same raw material, different questions Phases E and F sit back-to-back in the ADM and both operate on the same raw material — the gaps identified in Phases B, C, and D — which is exactly why they're easy to conflate in practice, but they answer different questions and are staffed and executed differently. ## Phase E — shaping the solution Phase E, Opportunities & Solutions, is the first phase in the ADM that shifts from pure architecture description toward implementation shape. Its inputs are the gap analyses and updated Architecture Definition Document from Phases B, C, and D. Its core activities are: - **consolidating and cross-referencing gaps** from all three domains to find natural groupings (a business-process change, a data-model change, and an infrastructure change that only make sense delivered together become one candidate Work Package); - **making build-vs-buy-vs-reuse decisions** for each grouping; - **identifying dependencies between work packages** (Work Package B can't start until Work Package A delivers a shared data platform); - and, for organizations whose transformation is too large to deliver in one cutover, **defining candidate Transition Architectures** — named, coherent intermediate states between the current Baseline and the ultimate Target Architecture. The output of Phase E is essentially a solution-shaped inventory: here are the logical chunks of work, here's roughly how each will be sourced, here's how they depend on each other, and here are the intermediate landing states. ## Phase F — sequencing the work Phase F, Migration Planning, takes that inventory and answers a different question: given limited budget, limited delivery capacity, and real business risk tolerance, in what order should these work packages actually be executed, and what does the concrete plan look like? Its core activities are: - **performing cost/benefit/risk analysis** on each work package; - **applying prioritization criteria** that reflect actual business value and risk appetite (a work package that closes a regulatory-compliance gap outranks one that only improves developer convenience, even if the latter is technically 'ready' sooner); - **producing the finalized, detailed Implementation and Migration Plan** together with an Architecture Roadmap that has real dates, owners, and dependencies, suitable for handing to Phase G's governance process and the delivery organization. The two phases answer different questions: | Phase | The question it answers | |---|---| | **Phase E** | 'what are the pieces and how might each be built' | | **Phase F** | 'in what order, on what timeline, and why this order rather than another' | ## Why they stay separate The reason TOGAF keeps them as two phases rather than one combined 'planning' step is a separation-of-concerns argument similar to the one behind splitting B/C/D: solution-shaping (Phase E) requires architecture and technical-sourcing judgment, while prioritization and migration sequencing (Phase F) requires business-value, risk, and portfolio-management judgment — often different stakeholders doing genuinely different analytical work. Collapsing them tends to produce a plan where the 'what' gets real attention but the 'why this order' gets skipped, because nobody explicitly owned the prioritization step as its own deliverable. ## The trade-off The trade-off, as with the rest of the ADM's phase granularity, is thoroughness against speed: running Phase E and Phase F as genuinely separate exercises, each with the right stakeholders, takes real calendar time and forces explicit prioritization conversations that a team eager to start building would rather skip. For a small, low-risk engagement with one obvious sequence, TOGAF's tailoring guidance allows compressing them; for a multi-year, multi-million-dollar transformation program, skipping the distinction is a much costlier mistake. ## What goes wrong in practice A concrete failure mode: a team runs a thorough Phase E, producing a well-reasoned set of work packages with clear build-vs-buy calls and dependencies, but treats Phase F as a rubber-stamp — the delivery order ends up being 'whichever work package the strongest internal advocate pushed hardest for,' with no documented cost/benefit/risk comparison. Eighteen months later, when the program's budget gets cut by a third, there's no defensible basis for deciding which work packages to defer, because Phase F never produced the prioritization rationale that would justify any particular cut. ## Where it shows up A worked example: a hospital network's EHR modernization identifies (in Phase E) three work packages — a new patient-data model, a clinician-facing UI overhaul, and a legacy interface-engine replacement — with the interface-engine replacement flagged as a dependency for the other two. Phase F then does cost/benefit/risk analysis and, because regulatory audit findings make the interface engine's current state a compliance risk, sequences it first in the Architecture Roadmap even though the clinician-facing UI overhaul had stronger day-one user demand — a sequencing decision that only Phase F's risk-weighted prioritization, not Phase E's solution-shaping, was equipped to make.