A team discusses the ERP migration roadmap from legacy systems to cloud ERP.
In ERP implementation programs, one of the moments when the value of the Enterprise Architect is most critically tested is TOGAF® ADM Phase F, “Migration Planning”. Phase F aims to finalize a detailed Implementation and Migration Plan that enables the organization to move from the Baseline Architecture to the Target Architecture in a controlled, value-driven way. At the heart of this effort sits the EA Repository, which consolidates work packages, Transition Architectures, reference models, standards, dependencies, and roadmaps into a single, coherent environment so that ERP implementation is managed not as a “system rollout”, but as a business transformation program tied to tangible enterprise value.
ERP implementation is never just about deploying a new system. It simultaneously addresses business process standardization, master data harmonization, integration with surrounding systems, regional rollouts, and decommissioning of legacy platforms. Simply defining a target architecture is not enough to succeed. In practice, unless the organization can clearly answer questions such as “What should we change first?”, “Which capabilities must be delivered in which migration wave?”, and “Which risks will we accept, and which dependencies must be resolved early?”, the program will quickly fall into scope creep, priority conflicts, and stakeholder misalignment.
TOGAF® defines Phase F as follows:
“This chapter addresses migration planning; that is, how to move from the Baseline to the Target Architectures by finalizing a detailed Implementation and Migration Plan.”
This definition highlights that the essence of Phase F is refinement of the plan. Enterprise Architects are accountable for transforming the architectural outputs produced during the earlier phases into executable migration sequences and investment decisions that reflect business value, risk, and constraints.
In the TOGAF® standard, the Architecture Repository is explicitly listed as an input to Phase F. It includes reusable building blocks, publicly available reference models, organization-specific reference models, and organization standards.
“Architecture Repository … including: Re-usable building blocks; Publicly available reference models; Organization-specific reference models; Organization standards.”
Phase F also assumes that the Architecture Definition Document contains the Baseline Architecture, Target Architecture, and any Transition Architectures that describe intermediate states on the way from As-Is to To-Be.
“Draft Architecture Definition Document … including: … Transition Architectures, if any.”
This means the EA Repository is far more than a static filing cabinet. In ERP implementations, the Enterprise Architect must use the repository to manage at least the following information in a consistent, traceable manner:
The Enterprise Architect’s role is not merely to produce diagrams and documents in isolation, but to ensure that these artifacts are stored as interconnected, traceable objects in the EA Repository. In practice, this is supported by tools such as SAP LeanIX and Sparx Enterprise Architect, which position the repository as the central Architecture Repository where catalogs, matrices, and diagrams can be managed as living assets.
TOGAF® describes the main steps in Phase F as assigning business value to work packages, estimating resource requirements and timings, prioritizing projects based on cost, benefit, and risk, confirming the Architecture Roadmap, and completing the Implementation and Migration Plan.
“The steps in Phase F are as follows: … Assign a Business Value to Each Work Package … Estimate Resource Requirements, Project Timings … Prioritize the migration projects … Confirm Architecture Roadmap … Complete the Implementation and Migration Plan.”
The standard is very explicit about the need to assign business value:
“Establish and assign a business value to each of the work packages.”
Work packages are then used as the basis for identifying projects in the Implementation and Migration Plan, and risks are assigned to projects and increments by aggregating the risks captured in the consolidated gaps, solutions, and dependencies matrix from Phase E.
“Use the work packages as a basis of identifying projects that will be in the Implementation and Migration Plan. … Risks should then be assigned to the projects and project increments by aggregating risks identified in the Consolidated Gaps, Solutions, and Dependencies Matrix (from Phase E).”
Translating this into concrete ERP implementation practice, the Enterprise Architect’s responsibilities in Phase F can be organized as follows:
Without an EA Repository, these activities tend to be fragmented across multiple Excel sheets, PowerPoint files, and project plans, making it difficult to trace decisions back to architectural evidence or to maintain consistency as the program evolves.
In multi-site ERP rollouts, it is rarely feasible or advisable to switch all locations at once. Instead, enterprises adopt wave-based introductions by region or plant. If the EA Repository maintains site-specific process deviations, local requirements, template adoption rates, and integration patterns around each plant, the Enterprise Architect can logically determine which locations should form Wave 1, Wave 2, and so on.
TOGAF® expects the Architecture Roadmap to include Transition Architectures:
“Architecture Roadmap, Version 0.1 … including: Identification of work packages; Identification of Transition Architectures …”
For example, Transition 1 might be defined as “Headquarter Finance and Procurement first”, Transition 2 as “Production and inventory harmonization at key plants”, and Transition 3 as “Standardized global template rollout to all regions”. By linking each Transition Architecture to its supporting work packages in the EA Repository, the roadmap becomes more than a timeline—it becomes a record of architectural evolution and business value delivery.
ERP success is heavily dependent on the consolidation of master data such as materials, business partners, BOMs, locations, and chart of accounts. If the EA Repository captures data entities, responsible organizations, data quality issues, consuming applications, and planned migration timings, the Enterprise Architect can systematically determine which master data domains must be standardized first.
This directly supports the Phase F requirement to assign business value and prioritize based on dependencies. For instance, without material master standardization, integrated production planning and inventory visibility are impossible, so the MDG implementation work package must be placed at a higher priority. Repository-managed dependencies make this decision transparent and defensible.
ERP implementation rarely stands alone. The program must include integration with MES, PLM, SCM, analytics platforms, and EDI hubs. ArchiMate’s Implementation and Migration Extension introduces concepts such as plateaus, work packages, deliverables, and migration paths that can be used to model these integrations. It allows Enterprise Architects to represent intermediate architectural states that bridge the Baseline and Target Architectures.
“The Implementation and Migration Extension adds concepts to support the implementation and migration of architectures in Phase E, Phase F, and Phase G of the TOGAF® ADM.”
For example, Phase 1 might focus on PLM-to-ERP integration only, Phase 2 adds MES production feedback, and Phase 3 introduces demand forecasting and S&OP analytics. Managing these scenarios in the EA Repository clarifies preconditions, expected outcomes, and sequencing for each integration, and supports a coherent Implementation and Migration Plan.
In ERP implementation, the Enterprise Architect must be more than a “diagram author”; they are the design owner for business transformation. SAP LeanIX and Sparx Enterprise Architect both emphasize that Enterprise Architects are accountable for key skills, responsibilities, and deliverables that shape how architectures are executed.
Sparx Enterprise Architect’s TOGAF® guidance explains that catalogs, matrices, and diagrams can be stored in the repository and used as the Architecture Repository to model enterprises of any size.
“You can use the TOGAF® facilities in Enterprise Architect to model an enterprise of any size, and you can create or import any number of Artifacts including Catalogues, Matrices and diagrams, which can all be conveniently stored in the repository that will serve as the Architecture Repository.”
In day-to-day ERP work, three perspectives are particularly important:
In ERP implementations, TOGAF® ADM Phase F is the point where conceptual architecture is transformed into a practical, executable migration plan. Its success depends heavily on how effectively the Enterprise Architect uses the EA Repository as a living backbone for work packages, Transition Architectures, dependencies, standards, and roadmaps. By orchestrating these elements around ERP-specific concerns—such as global rollouts, master data harmonization, and integration with MES, PLM, and SCM—the Enterprise Architect can bridge “design” and “delivery” and lead Migration Planning that balances business value with implementation feasibility.
Parts of this article were developed with reference to generative AI suggestions and were reviewed, refined, and supplemented based on the author’s professional expertise and judgment.
ERP implementation in global manufacturing requires critical decisions about ERP scope, surrounding applications, global standardization,…
Measure SAP S/4HANA ROI over just three years and you will mostly see cost. This…
Explore how SAP Digital Manufacturing supports FPC production, including quality management, traceability, S/4HANA integration, implementation…
PLM is the system of record for what a product is and why it changed;…
What does AI need to rate stakeholder power and interest as High, Middle, or Low…
How can AI streamline TOGAF stakeholder management? This guide outlines a practical six-step process, from…