Section 1: Phase F Overview
Phase F — Migration Planning — is the bridge between architecture and delivery. Its core purpose is to finalise a prioritised, costed, and resource-planned set of implementation projects (work packages) that will realise the Target Architecture through one or more Transition Architectures. Phase F takes the draft Architecture Roadmap produced in Phase E and transforms it into a committed, Board-approved Implementation and Migration Plan.
The ADM phase in which the organisation finalises the Architecture Roadmap and produces the Implementation and Migration Plan, confirming the priority, sequence, resource requirements, and dependencies of the work packages that will implement the Target Architecture.
| Attribute | Detail |
|---|---|
| Primary Goal | Produce a finalised, approved Implementation and Migration Plan |
| Key Input | Draft Architecture Roadmap (from Phase E); stakeholder concerns; capability assessments |
| Key Outputs | Implementation & Migration Plan (finalised); Finalised Architecture Roadmap; Prioritised Work Packages; Transition Architecture definitions |
| Approved by | Architecture Board and relevant programme governance bodies |
| Transition from | Phase E (identifying options) to Phase F (committing to plan) |
Phase E identifies and generates options — it produces a draft roadmap and a list of candidate work packages. Phase F commits to a plan — it finalises priorities, assigns resources, confirms dependencies, and obtains formal approval. The exam tests this distinction frequently: E = identify, F = finalise.
Section 2: Coordinating with Management Frameworks
TOGAF does not prescribe how implementation projects should be managed. Instead, Phase F explicitly requires the architecture team to coordinate with whatever project and programme management frameworks the organisation already uses. This coordination ensures that the Implementation and Migration Plan is expressed in terms that project sponsors and delivery teams will recognise and adopt.
Maps work packages to PRINCE2 projects. The Business Case and Project Initiation Documentation (PID) align with Phase F cost and benefit estimates. Architecture compliance requirements become PRINCE2 quality criteria.
Transition architectures map to MSP tranches. The Blueprint (MSP's future-state description) is informed by the Target Architecture. The Programme Plan corresponds to the Architecture Roadmap.
Work packages align with PMBOK projects. The Implementation and Migration Plan feeds Programme Management Plans. Architecture requirements become project scope statements and quality management plans.
Work packages decompose into product increments or sprints. Transition architectures define the end-state per release. Architecture principles guide sprint-level technical decisions, with compliance checked at programme increment boundaries.
Beyond project-level frameworks, Phase F also aligns with Enterprise Portfolio Management — ensuring that the Implementation and Migration Plan fits within the organisation's overall investment portfolio — and with IT governance structures to confirm funding approval, resource allocation authority, and escalation paths.
A common Part 2 scenario describes an organisation using PRINCE2 or Agile and asks how TOGAF Phase F should integrate. The correct answer always emphasises coordination and alignment rather than replacement. TOGAF does not displace existing delivery methods; it feeds architecture context into them.
Section 3: Implementation and Migration Plan
The Implementation and Migration Plan is the primary deliverable of Phase F. It is more detailed than the Architecture Roadmap (Phase E output) — it moves from strategic sequencing to project-level scheduling, costing, and resource assignment.
| Component | Description |
|---|---|
| Finalised architecture | Confirmed Target Architecture and approved Transition Architecture definitions |
| Work packages | Discrete, deliverable units of change with defined scope, owner, and acceptance criteria |
| Dependencies | Precedence relationships between work packages (technical and organisational) |
| Risk register | Identified risks, likelihood, impact, and mitigation actions per work package |
| Resource requirements | Skills, headcount, budget, and vendor/partner involvement per work package |
| Milestones and schedule | Time-phased delivery plan showing when each work package and transition architecture will be achieved |
| Benefits realisation | Mapping of work packages to the business benefits identified in the Architecture Vision |
The Implementation and Migration Plan is formally approved by the Architecture Board before Phase G begins. Approval confirms that the plan is architecturally sound and that governance structures are in place to oversee delivery.
Section 4: Work Package Prioritisation
A central Phase F activity is determining the sequence in which work packages will be implemented. Prioritisation balances competing factors — not all high-value work packages can be started first if they carry high risk or hard dependencies.
Prioritisation Factors
- Business value: Revenue generation, cost savings, strategic enablement, or compliance mandate
- Complexity and risk: Technical difficulty, organisational change burden, integration complexity
- Dependencies: Whether a work package is a prerequisite for others (blocking vs. non-blocking)
- Resource availability: Skills, budget, and third-party capacity constraints
- Time-sensitivity: Regulatory deadlines, contract renewals, market windows
Priority Assessment Matrix
| Low Complexity | Medium Complexity | High Complexity | |
|---|---|---|---|
| High Business Value | Quick Win — Prioritise first | High Priority — Plan carefully | Major Programme — Phase into tranches |
| Medium Business Value | Schedule early — low-hanging fruit | Mid-tier — sequence after dependencies | Defer or simplify scope |
| Low Business Value | Consider bundling or deferring | Defer — poor return on effort | Cancel or descope |
Quick wins — high-value, low-complexity work packages — are deliberately scheduled early in the Implementation and Migration Plan to build organisational confidence, generate early business benefits, and validate the architecture approach before committing to more complex tranches.
Section 5: Resource Planning in Phase F
Phase F translates the work package list into a resource demand model — identifying who needs to do what and when. Three dimensions of resource planning are particularly important:
- Skills requirements: Each work package requires a skills profile (architecture, project management, technical delivery, change management). Phase F identifies skills gaps and triggers recruitment, training, or contractor sourcing decisions before Phase G begins.
- Organisational change management: Many work packages deliver technology change that requires people to change behaviour. Phase F plans the communications, training, and business readiness activities needed to make each transition architecture operational.
- Vendor and partner coordination: Work packages that involve third parties (system integrators, cloud providers, SaaS vendors) must include procurement lead times, contractual milestones, and interface agreements in the schedule. The Implementation and Migration Plan becomes an input to procurement processes.
Section 6: Transition Architecture Handoff
Phase F finalises the definitions of each Transition Architecture (T1, T2, etc.) that were identified in Phase E. Each Transition Architecture represents a stable, deployable state of the enterprise — a genuine intermediate architecture that delivers business value and can be governed independently.
| Handoff Element | Phase F Action | Phase G Continuation |
|---|---|---|
| T1 definition | Confirm scope, deliverables, and acceptance criteria for first transition architecture | Issue Architecture Contract covering T1 work packages |
| Compliance criteria | Document architecture compliance requirements per work package | Conduct compliance assessments against those criteria |
| Repository update | Store finalised Transition Architecture artefacts in Architecture Repository | Reference repository during implementation governance reviews |
| Feedback loop | Establish mechanism for Phase G findings to return to Architecture Repository | Log deviations, dispensations, and change requests |
The Architecture Repository is updated at the end of Phase F to reflect the finalised architecture definitions, ensuring that Phase G governance teams work from an authoritative, approved baseline rather than draft Phase E artefacts.
Section 7: Risk Assessment and Mitigation in Phase F
Phase F conducts a structured risk review that is more detailed than the high-level risk identification performed in Phase A. At this stage, risks are assessed at the work-package level rather than the programme level, enabling targeted mitigation and realistic contingency planning.
| Risk Category | Example | Typical Mitigation |
|---|---|---|
| Delivery risk | Vendor unable to meet contractual delivery date | Build schedule buffer; identify alternative vendors; stage deliverables |
| Technical risk | Integration between legacy system and new platform is more complex than estimated | Proof-of-concept in earlier tranche; specialist technical review |
| Organisational risk | Business unit resistance to process change | Executive sponsorship; early stakeholder engagement; change management plan |
| Dependency risk | Work package B cannot start until Work Package A data migration is complete | Re-sequence the roadmap; add intermediate milestone gates |
| Resource risk | Specialist skills unavailable in the required timeframe | Advance recruitment; training programme; managed service contract |
The risk register produced in Phase F is handed to Phase G as a key governance input. During implementation, Phase G monitors whether risks materialise and escalates significant changes back to the Architecture Board for potential plan revision.
Section 8: Phase F and Phase G — Planning to Governance
Phase F concludes when the Implementation and Migration Plan is formally approved. At that point, control passes to Phase G (Implementation Governance), which oversees the actual delivery of work packages against the approved plan.
| Dimension | Phase F (Migration Planning) | Phase G (Implementation Governance) |
|---|---|---|
| Focus | Plan creation and approval | Plan execution and conformance oversight |
| Primary artefact | Implementation and Migration Plan | Architecture Contracts |
| Key activity | Prioritise, sequence, resource-plan, obtain Board approval | Assess compliance, issue dispensations, log change requests |
| Risk posture | Identify and mitigate before commitment | Monitor and escalate during delivery |
| Handoff trigger | Architecture Board approves Implementation and Migration Plan | First Architecture Contract issued to a delivery project |
It is important to note that Phase F and Phase G can overlap in time when multiple transition architectures are in scope. Phase G may be governing T1 delivery while Phase F is still finalising the detailed plan for T2. This concurrency is expected and handled through the Architecture Repository and the Architecture Board's governance cadence.
- Phase F output ≠ Phase E output: Phase E produces a draft roadmap; Phase F produces the finalised Implementation and Migration Plan. Know the difference.
- Approval body: The Architecture Board formally approves the Implementation and Migration Plan at the end of Phase F — not the sponsor (who approved the Statement of Architecture Work in Phase A).
- TOGAF does not replace PM frameworks: Phase F coordinates with PRINCE2, MSP, PMI — it does not replace them. Exam distractors often suggest TOGAF overrides existing methods.
- Quick wins: High-value, low-complexity work packages are deliberately scheduled first to build momentum — a classic Part 2 scenario answer for sequencing questions.
- Concurrent phases: Phase G can begin while Phase F is still refining later tranches — overlap is explicitly supported by TOGAF iteration principles.
Revision Summary — Chapter 08
- Phase F finalises the Implementation and Migration Plan, transforming Phase E's draft roadmap into a Board-approved, prioritised delivery commitment.
- Key inputs: Architecture Roadmap (Phase E), stakeholder concerns, capability assessments. Key outputs: finalised Implementation and Migration Plan, prioritised work packages, confirmed Transition Architecture definitions.
- TOGAF does not specify how projects are managed — Phase F coordinates with PRINCE2, MSP, PMI/PMBOK, and Agile, aligning architecture artefacts to existing delivery frameworks.
- The Implementation and Migration Plan includes: finalised architecture, work packages, dependencies, risk register, resource requirements, milestones, and benefits mapping.
- Work packages are prioritised using: business value, complexity, risk, dependencies, and resource availability. Quick wins (high value, low complexity) are scheduled first.
- Phase F finalises Transition Architecture definitions (T1, T2...) and stores them in the Architecture Repository, providing Phase G with an approved governance baseline.
- Phase F risk assessment operates at work-package level; the resulting risk register is handed to Phase G for monitoring during delivery.
- Phase F concludes when the Architecture Board approves the Implementation and Migration Plan; Phase G then issues Architecture Contracts to delivery projects. The two phases may overlap when multiple transition architectures are in play.
Practice Questions
Five exam-style questions covering Phase F. Click a question to reveal the answer and explanation.
A. A draft Architecture Roadmap listing candidate work packages
B. Architecture Contracts issued to delivery projects
C. A finalised, Board-approved Implementation and Migration Plan with prioritised work packages
D. A Gap Analysis identifying differences between Baseline and Target Architecture
Explanation: Option C is correct. Phase F's primary deliverable is the finalised Implementation and Migration Plan, approved by the Architecture Board, which includes prioritised work packages, dependencies, resources, and a schedule. Option A describes Phase E's output (draft roadmap). Option B describes Phase G's output (Architecture Contracts). Option D describes an activity from Phases B, C, and D.
A. Replace PRINCE2 with TOGAF's own project management approach for architecture-related projects
B. Align the Implementation and Migration Plan with PRINCE2 constructs, mapping work packages to PRINCE2 projects and using Business Cases to express costs and benefits
C. Require PRINCE2 projects to re-plan according to the Architecture Roadmap without modification
D. Defer Phase F until the organisation adopts a framework that TOGAF directly supports
Explanation: Option B is correct. TOGAF explicitly states that it does not specify how to manage implementation projects — instead, Phase F coordinates with whatever management framework the organisation uses. The correct approach is to express the Implementation and Migration Plan in PRINCE2 terms (Business Case, Project Initiation Documentation) so that delivery teams can act on it. Options A and C incorrectly suggest TOGAF replaces or overrides PRINCE2. Option D is incorrect — there is no such deferral provision in TOGAF.
A. W first, then X, then Y, then Z (or cancel Z)
B. X first, then W, then Z, then Y
C. Y first (lowest risk), then W, then X, then Z
D. All packages should be implemented in parallel to maximise speed
Explanation: Option A is correct. Phase F prioritisation places quick wins (high value, low complexity) first — Package W is a classic quick win. Package X (high value, high complexity) is a major priority but requires careful planning and phasing, so it follows W. Package Y (low value, low complexity) can be scheduled later or bundled. Package Z (low value, high complexity) should be deferred or cancelled — the effort is disproportionate to the return. This priority matrix logic is directly tested in Part 2 scenario questions.
A. The programme sponsor, as owner of the business case
B. The Chief Information Officer, as the senior IT authority
C. The Architecture Board, as the governance authority for architecture decisions
D. The Requirements Management process, which validates all phase outputs
Explanation: Option C is correct. The Architecture Board is the governance body responsible for approving the Implementation and Migration Plan before Phase G implementation begins. The sponsor approved the Statement of Architecture Work in Phase A (Option A is wrong for Phase F). The CIO may be involved but is not the defined TOGAF approval authority (Option B). Requirements Management is a process, not an approval body (Option D).
A. This is incorrect — Phase G cannot begin until Phase F has completed all Transition Architecture plans
B. This is acceptable — Phase F and Phase G can run concurrently when multiple transition architectures are in scope, supported by the ADM's iteration principles
C. Phase F should be suspended until Phase G completes T1 delivery to avoid conflicting governance
D. Both phases should be merged into a single combined planning-and-governance phase to avoid overlap
Explanation: Option B is correct. TOGAF's ADM iteration model explicitly supports concurrent phase execution when multiple transition architectures are in scope. It is common and expected for Phase G to begin governing T1 delivery while Phase F continues refining the T2 plan. The Architecture Repository and Architecture Board cadence provide the coordination mechanism. Option A incorrectly imposes a strict sequential constraint that TOGAF does not mandate. Options C and D are not consistent with TOGAF guidance.