TOGAF Phases E and F: Opportunities, Solutions and Migration Planning

Defining the target architecture is only half the job. The harder question is always: how do we get there from here? Phases E and F of the TOGAF ADM answer exactly that. Together, they bridge the gap between the beautiful target state defined in Phases B through D and the messy, complex reality of making it happen in a real organization.

Phase E is about identifying the best path forward from among many possible options. Phase F is about turning that chosen path into a detailed, executable migration plan. These two phases are where architecture work becomes delivery planning, and where the architecture team hands the baton to project and programme managers.

---

Phase E: Opportunities and Solutions

What Phase E Does

Phase E is the first planning phase after the four core architectural domains have been defined. Its job is to take the Gap Analysis outputs from Phases B, C, and D and turn them into an initial Architecture Roadmap.

The Architecture Roadmap describes the sequence of work packages needed to move from the current baseline to the target architecture. Phase E does not plan the detailed delivery of each work package. It identifies what they are, prioritizes them, and assesses how they might be grouped and sequenced.

The Key Objectives of Phase E

1. Generate the initial complete version of the Architecture Roadmap based on gap analysis results from Phases B, C, and D
2. Determine whether an incremental approach is needed, and if so, identify Transition Architectures
3. Define the business value of each work package
4. Confirm the readiness and risk for business transformation
5. Formulate an implementation and migration strategy

---

Consolidating the Gap Analysis

The gap analyses from Phases B, C, and D each produced lists of things that need to change. Phase E brings these together into a consolidated view of the full transformation scope.

This consolidated gap view identifies:

• Which new capabilities must be built or acquired
• Which applications must be developed, purchased, enhanced, or retired
• Which data management changes are required
• Which technology components must be upgraded, replaced, or decommissioned
• Which organizational changes (roles, skills, processes) are needed

The consolidated view often reveals dependencies between gaps. An application cannot be migrated before its underlying database has been restructured. A new platform cannot be deployed before the network security architecture has been updated. Identifying these dependencies is essential for building a realistic roadmap.

---

Identifying Work Packages

A work package is a coherent set of changes that can be defined, resourced, and delivered together. Phase E groups the identified gaps into logical work packages.

Each work package is assessed against:

• Business value: What benefit does completing this work package deliver to the organization?
• Dependencies: Which other work packages must be completed before this one can begin?
• Risk: What is the technical, organizational, and commercial risk of this work?
• Effort and cost: What level of resource is required?
• Strategic priority: How critical is this to the goals in the Architecture Vision?

---

Transition Architectures

For large or complex transformations, it is not possible to move directly from the baseline to the target in a single step. The organization must operate continuously throughout the transformation, and large-bang changes carry enormous risk.

Transition Architectures define intermediate stable states the organization will pass through on the way to the target. Each Transition Architecture represents a genuine, operational state of the enterprise — not a half-finished configuration.

For example, a bank migrating from a mainframe-based core banking system to a cloud-native platform might define three Transition Architectures:

1. Transition Architecture 1: Non-critical workloads migrated to cloud; mainframe still handles core transactions
2. Transition Architecture 2: New cloud core banking system running in parallel for new customers; mainframe retained for existing portfolio
3. Transition Architecture 3: Full migration complete; mainframe decommissioned; all operations on cloud

Each of these is defined with enough architectural detail that the organization can actually operate in that state without ambiguity about what systems are authoritative, what processes apply, and what standards govern each component.

---

The Implementation and Migration Strategy

Alongside the roadmap, Phase E produces the Implementation and Migration Strategy, which defines the overall approach to the transformation. Key choices include:

• Greenfield vs brownfield: Whether to build new capability alongside existing systems before switching over, or to transform existing systems in place
• Big-bang vs phased: Whether to make all changes simultaneously (high risk, fast results) or incrementally (lower risk, longer timeline)
• Programme structure: How the work packages will be organized into programmes and projects
• Governance of delivery: How the Architecture Board will oversee delivery to ensure the target architecture is being implemented as designed

---

Phase F: Migration Planning

Where Phase E identifies and prioritizes what needs to happen, Phase F creates the detailed plan for how and when it will happen.

What Phase F Does

Phase F produces the formal Migration Plan, which translates the Architecture Roadmap into a programme of projects with defined sequence, dependencies, resource requirements, and governance checkpoints.

The Key Objectives of Phase F

1. Finalize the Architecture Roadmap and Migration Plan
2. Ensure the Migration Plan is properly coordinated with the enterprise's portfolio and project management frameworks
3. Assign business value to each work package for ongoing prioritization
4. Confirm transition costs and benefits and ensure they are captured in a business case
5. Finalize the Architecture Definition Document (the full output of Phases B through D)

---

Prioritizing Work Packages

Phase F takes the work packages identified in Phase E and finalizes their priority and sequencing. Prioritization considers several factors:

• Quick wins: Work packages that deliver high business value quickly and with relatively low risk should be prioritized early to demonstrate the value of the architecture programme
• Foundation requirements: Some work packages must be completed before others can begin. These foundation items are prioritized regardless of their immediate business value
• Risk reduction: Work packages that address high-risk items (such as systems approaching end of life or known security vulnerabilities) are often elevated in priority
• Business calendar alignment: Delivery windows must avoid critical business periods such as financial year-end, regulatory reporting cycles, or major trading events

---

The Migration Plan

The Migration Plan is the formal output of Phase F. It is the document that hands the architecture work to the delivery organization. A good Migration Plan includes:

• The complete list of work packages with their priority order
• The sequencing of work packages showing dependencies
• The Transition Architectures that define the intermediate stable states
• High-level resource requirements for each phase of delivery
• Key milestones and decision points
• Governance checkpoints where the Architecture Board will review compliance
• Risks and dependencies that could affect the plan
• The business case for the transformation, linking costs to quantified business benefits

---

Coordinating with Portfolio Management

Phase F explicitly requires that the Architecture Migration Plan be integrated with the organization's existing portfolio and project management frameworks.

This integration is important because it ensures:

• Architecture-driven work packages compete fairly for resources alongside other organizational priorities
• Project managers who will deliver the work packages have visibility of the architecture constraints and requirements from the start
• The organisation's existing governance and reporting structures include the transformation programme
• Architecture compliance reviews are built into the project delivery process as standard checkpoints, not added as afterthoughts

---

Key Deliverables from Phases E and F

Phase E:

• Initial Architecture Roadmap
• Transition Architecture definitions
• Implementation and Migration Strategy
• Business value assessments for each work package

Phase F:

• Finalized Architecture Roadmap
• Migration Plan
• Finalized Architecture Definition Document
• Architecture Building Blocks updated with implementation details
• Updated Architecture Repository

---

Real-World Example: UK Public Sector Digital Transformation

A UK government department undertaking a major digital transformation programme uses Phases E and F as follows:

• Phase E gap consolidation: 47 individual gaps identified across Business, Application, Data, and Technology domains. These are grouped into 12 work packages
• Three Transition Architectures defined: Year 1 covers citizen-facing digital services; Year 2 covers back-office process automation; Year 3 covers full legacy decommissioning
• Quick wins identified: A new citizen self-service portal (Work Package 1) delivers immediate public value with low technical risk. It is prioritized first despite not being the largest change
• Foundation requirement: The shared identity platform must be delivered in Year 1 before any other citizen-facing service can launch
• Migration Plan output: A three-year programme of 12 projects presented to HM Treasury with a full business case showing £45M in efficiency savings over five years

---

Summary

Phases E and F are where the architecture turns into a plan. Phase E generates the Architecture Roadmap by grouping gaps into work packages, defining Transition Architectures, and choosing an implementation strategy. Phase F finalizes that plan into a coordinated, prioritized, and properly resourced Migration Plan.

Together they ensure that the organization has a clear, realistic path from where it is today to where it needs to be.

In the next post, we cover the final two ADM phases: Phase G and H — Implementation Governance and Architecture Change Management, where architects shift from planning to oversight and long-term change control.

For context on where the gaps come from, review Phase B Business Architecture, Phase C Application Architecture, and Phase D Technology Architecture.