9.3 Implementation and Migration Plan Deliverable, Resource Allocation, and Transition Roadmaps
Key Takeaways
The Implementation and Migration Plan is the Phase F deliverable that turns work packages into a schedule of projects, resources, and governance arrangements.
The Architecture Definition Document says what will be built, the Architecture Roadmap says in what sequence, and the Implementation and Migration Plan says how, by whom, and at what cost.
Transition Architectures are stable intermediate states that each deliver measurable business value, so a long transformation can pause safely between them.
TOGAF's final Phase F step is to complete the architecture development cycle and document lessons learned; an Implementation Governance Model can also be output.
Once the plan is agreed at the end of Phase F, an Architecture Contract may be drawn up with business stakeholders; contracts with implementing organizations are documented and signed at the beginning of Phase G.
9.3 Implementation and Migration Plan Deliverable, Resource Allocation, and Transition Roadmaps
The ultimate measure of an enterprise architecture practice is its ability to translate strategic vision into executed reality. Phase F culminates in the creation and formal approval of the Implementation and Migration Plan—the authoritative bridge connecting enterprise architecture to project execution. By finalizing the Architecture Roadmap and refining the Architecture Definition Document (ADD) to detail intermediate Transition Architectures, Phase F ensures that every participant, from executive sponsors to engineering project leads, understands what will be built, when it will be delivered, how resources are allocated, and how architectural governance will be enforced during implementation.
The Core Deliverable: Implementation and Migration Plan
According to the TOGAF Standard, 10th Edition, the Implementation and Migration Plan is the approved Phase F deliverable that provides the schedule, resource allocations, governance framework, and project portfolio required to implement the target architecture. While earlier phases produce architectural models, the Implementation and Migration Plan is a management deliverable co-developed with portfolio managers, the PMO, and corporate finance.
Detailed Anatomy of the Implementation and Migration Plan
A robust, exam-ready Implementation and Migration Plan contains six essential components:
- Implementation and Migration Strategy: The overarching strategic approach guiding execution. It establishes whether the enterprise will adopt an incremental Strangler Fig pattern, a greenfield replacement, a commercial off-the-shelf (COTS) package rollout, or a phased regional deployment.
- Project Charters and Work Package Definitions: Detailed operational charters for each implementation project derived from the architectural work packages. Each charter specifies project scope, business objectives, architectural building blocks (ABBs and SBBs) to be implemented, deliverables, acceptance criteria, and project boundaries.
- Consolidated Implementation Schedule & Milestones: A time-sequenced project schedule establishing dependencies across work packages, critical path milestones, transition architecture cutover dates, and delivery checkpoints.
- Resource Allocation and Financial Budgets: Comprehensive capital expenditure (CapEx) and operational expenditure (OpEx) commitments, internal staffing models, external systems integrator assignments, specialized hardware/software tooling allocations, and facilities requirements.
- Governance and Compliance Framework: Specific governance mechanisms, including mandatory Architecture Board review gates, compliance criteria, stage-gate sign-offs, and procedures for requesting architectural dispensations during Phase G.
- Risk Management and Contingency Protocols: Documented project and operational risks, fallback protocols, disaster recovery procedures, and rollback criteria in the event a production cutover encounters critical defects.
The Phase F Deliverables Triad
A critical area of testing on the OGEA-103 examination is distinguishing between the three core deliverables updated or finalized in Phase F:
[ PHASE F DELIVERABLE TRIAD ]
|
+------------------------------------+------------------------------------+
| | |
v v v
[ Architecture Definition Document ] [ Architecture Roadmap ] [ Implementation & Migration Plan ]
- The 'WHAT' (Models & Specifications) - The 'WHEN & IN WHAT SEQUENCE' - The 'HOW, WHO & AT WHAT COST'
- Baseline Architecture Description - Chronological timeline - Executable project charters
- Target Architecture Description - Transition Architectures - Resource assignments & budgets
- Formal Transition Architectures (1-N) - Milestone dependencies - Work breakdown structures & PMO gates
| Deliverable Dimension | Architecture Definition Document (ADD) | Architecture Roadmap | Implementation and Migration Plan |
|---|---|---|---|
| Core Purpose | Specifies what is being built across all architecture domains (baseline, transition, and target). | Specifies when and in what sequence architectural increments and transition states occur over time. | Specifies how, by whom, and at what financial cost the projects will be physically executed. |
| Primary Audience | Enterprise architects, solution designers, domain specialists, technical leads. | Business sponsors, portfolio managers, C-level executives, steering committees. | Project managers, PMO, resource managers, procurement, financial controllers. |
| Key Contents | Baseline/Target models, ABBs/SBBs, gap matrices, interface contracts, transition state models. | Gantt-level transition milestones, capability increments, dependency arrows, work package timelines. | Project charters, WBS, CapEx/OpEx cash flow profiles, staffing allocations, Phase G review gates. |
| Governance Role | Establishes the technical baseline against which architectural compliance is evaluated. | Communicates the strategic transformation path and capability realization trajectory. | Serves as the operational contract authorizing project mobilization and expenditure of funds. |
Transition Architectures: De-Risking the Journey
In complex enterprise environments, the distance between the baseline architecture and the target architecture is vast. Attempting to leap directly to the target state in a single, massive cutover—the infamous 'Big Bang' anti-pattern—almost universally leads to budget overruns, operational outages, and project cancellations. The TOGAF Standard solves this through Transition Architectures.
A Transition Architecture represents a formally defined, stable intermediate architectural state that delivers continuous business value and independent operational viability while progressively advancing toward the target architecture.
Principles of Transition Architectures
- Independent Operational Viability: A transition architecture must never leave the enterprise in a half-finished, non-functional limbo. If executive leadership freezes funding at Transition Architecture 2 due to an economic downturn, the organization must be able to operate indefinitely and profitably in that state.
- Measurable Business Value: Each transition state must deliver tangible business benefits (e.g., retiring an expensive mainframe subsystem, launching a mobile onboarding feature, or automating regulatory reporting) rather than purely invisible technical refactoring.
- De-Risked Sequencing: High-risk dependencies are isolated and systematically neutralized across transition states using proven architectural patterns (e.g., deploying API mediation layers in Transition Architecture 1 before replacing back-end databases in Transition Architecture 2).
[ Baseline Architecture ]
|
v (Work Packages: API Gateway, Cloud Infrastructure, Security)
[ Transition Architecture 1 ] ---> Delivers: Mobile Channel Access & \$1.2M Cost Savings
|
v (Work Packages: Microservices Ledger, Core Data Migration)
[ Transition Architecture 2 ] ---> Delivers: Real-time Payments & Decommission Legacy Core
|
v (Work Packages: AI Predictive Analytics, Global Expansion)
[ Target Architecture ] ---> Delivers: Full Autonomous Digital Enterprise
Resource Allocation and Capacity Planning
During Phase F, the enterprise architect collaborates with portfolio managers to align architectural demand with the organization's finite delivery capacity. This requires three distinct disciplines:
- Resource Leveling: Adjusting project start dates and milestones to resolve resource over-allocation without extending overall roadmap delivery beyond executive deadlines. For example, if both the 'Customer Portal' and 'Claims Processing' work packages require the same dedicated identity security team, their identity integration sprints must be staggered sequentially.
- Human Capital & Capability Uplift: Assessing whether internal engineering teams possess the necessary skills to support each transition state. The Implementation and Migration Plan must budget for training programs, external contractor augmentation, and knowledge transfer checkpoints.
- Technical Environment Capacity: Managing the availability of non-production environments (development, integration testing, user acceptance testing, staging). Migration projects frequently fail because multiple project teams contend for a single shared legacy testing environment that cannot be replicated easily.
Securing Sponsor Sign-off and Architecture Board Approval
Before the plan is executed, the Implementation and Migration Plan is approved through the enterprise's governance and change-portfolio processes. TOGAF's own final Phase F step is to complete the architecture development cycle and document lessons learned. Approval typically involves:
- Executive Business Sponsors: Sign off on the business cases, financial commitments (CapEx/OpEx), operational disruption windows, and capability release timelines.
- Architecture Board: Formally reviews the updated Architecture Definition Document and Architecture Roadmap, verifying that all cross-domain dependencies are resolved, that transition states maintain architectural integrity, and that no unapproved deviations from enterprise architecture principles have been introduced.
- Enterprise PMO & Portfolio Steering Committee: Confirms that project schedules, resource allocations, and vendor contracts are realistic and align with overall corporate delivery bandwidth.
- Operations and Support Executives: Accept the operational readiness criteria, support handoff procedures, and legacy decommissioning schedules.
Securing this formal consensus prevents future disputes during implementation, ensuring that executive leadership remains unified when unexpected delivery challenges arise.
Transitioning to Phase G (Implementation Governance)
Phase F prepares the ground for Phase G (Implementation Governance) in three ways:
- Implementation Governance Model: Phase F can output an Implementation Governance Model describing how implementation will be governed, including review points, roles, and how deviations are handled.
- Compliance review schedule: Architecture Compliance reviews are typically planned for project initiation, initial design, major design changes, and ad hoc needs (Section 10.3), and are embedded in the project plans.
- Dispensation route: The plan makes clear how implementation teams request time-bound dispensations from the Architecture Board when constraints force a temporary deviation.
TOGAF describes Architecture Contracts at several points in the ADM. The Statement of Architecture Work in Phase A is effectively one. When the Implementation and Migration Plan has been agreed at the end of Phase F, a contract may be drawn up between the architecting function and the business stakeholders who will build and deploy the architected solutions. At the beginning of Phase G, the contract with the function implementing the architecture, whether an in-house development team or a major contractor, is documented and signed by all developing organizations and the sponsoring organization. This happens in the Phase G step Guide development of solutions deployment.
Common Exam Traps & Practitioner Pitfalls
- Confusing the Architecture Roadmap with the Implementation and Migration Plan: The Architecture Roadmap is an architectural view specifying the timeline of transition and target architectural states. The Implementation and Migration Plan is an executable management plan detailing project charters, resource allocations, funding approvals, and work breakdown structures.
- The 'Big Bang' Cutover Fallacy: Recommending a single, direct transition from baseline to target architecture for complex systems, ignoring the necessity of defining stable, value-delivering Transition Architectures.
- Skipping Formal Architecture Board Sign-off: Mobilizing development teams directly into implementation without securing formal Architecture Board approval and signed Architecture Contracts. On the exam, skipping governance gates is an automatic distracter.
- Treating Transition Architectures as Throwaway Milestones: Failing to recognize that Transition Architectures must be independently viable operating states capable of sustaining business operations if subsequent phases are delayed or cancelled.
At the conclusion of Phase F, the enterprise architecture team finalizes the Implementation and Migration Plan. What is the fundamental purpose of this deliverable in relation to the Architecture Roadmap and project execution?
It is a reference white paper kept in the Architecture Repository for context, with no authority over how projects are funded or sequenced
It defines the low-level source code structure and unit test suites for each application, so developers can begin building immediately
It replaces project management and portfolio governance in later phases, since the plan already fixes every schedule and decision
It is the approved plan for delivery: the projects, resources, milestones, and governance needed to realize the target architecture
An enterprise transformation involves transitioning an organization from a fragmented on-premises legacy estate to an integrated digital cloud platform. The transformation cannot safely be achieved in a single release. In Phase F, what role do Transition Architectures play within the finalized Architecture Roadmap?
They are optional marketing diagrams that help secure sponsorship and can be discarded once project execution and delivery begin
They are defined, stable intermediate states, each delivering business value and operating on its own, that move the enterprise toward the target
They are permanent dispensations allowing business units to ignore enterprise standards until the final target architecture is reached
They document historical architectures retired in earlier cycles, so that the roadmap shows how the current baseline came about
An organization has agreed its Implementation and Migration Plan at the end of Phase F. Which statement about Phase F outputs and Architecture Contracts reflects TOGAF?
All implementation contracts with delivery partners must be signed before the Implementation and Migration Plan is drafted, so the plan reflects agreed commitments
Phase F has no outputs of its own: it hands the Phase E roadmap to the PMO, which then produces every implementation document without architecture input
Phase F finalizes the plan, ADD, requirements, and roadmap; a business-stakeholder contract may be drawn up now, and implementer contracts are signed at the start of Phase G
Phase F decommissions legacy systems before any new solution is built, so that the first Transition Architecture starts from a clean technology baseline
Sections you finish are checked off in the contents.