Businesswoman presenting ERP migration roadmap to diverse team in conference room

Insight Arc | SAP, Enterprise Architecture & Supply Chain Strategy

TOGAF® ADM Phase F Migration Planning in ERP Implementations: How Enterprise Architects Leverage the EA Repository

ERP Migration Planning: Why TOGAF® ADM Phase F and the EA Repository Matter in ERP Implementation Projects

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.

Why Phase F Is So Critical for ERP Implementations

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.

What the EA Repository Really Supports

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:

  • As-Is and To-Be business, application, data, and technology architectures.
  • Solution options and work packages that address each identified gap.
  • Transition Architectures or plateaus that describe staged rollouts and interim states.
  • Standard templates, integration principles, master data standards, and design constraints.
  • Architecture Roadmaps that show rollout sequencing, dependencies, and investment priorities.

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.

What Enterprise Architects Actually Do in Phase F

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:

  • Integrate all Phase E outputs in the EA Repository and prepare migration-planning views linked to business capabilities, applications, and data entities.
  • For each work package, attach attributes such as expected benefits, business impact, system impact, risks, and dependencies.
  • Use these attributes to define migration waves, regional rollout sequencing, and domain-by-domain priorities.
  • Reflect the agreed plan in the Architecture Roadmap and the Implementation and Migration Plan, and secure stakeholder alignment across business, IT, and program management.

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.

Practical ERP Use Cases for TOGAF® Phase F and the EA Repository

1. Designing Migration Waves for Global SAP S/4HANA Rollout

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.

2. Prioritizing Master Data Harmonization

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.

3. Planning ERP Integration with MES, PLM, and SCM

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.

The Strategic Perspective Required from Enterprise Architects

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:

  • Every migration decision must be traceable to business value, risk, and dependencies, and explainable to stakeholders in these terms.
  • Architectural artifacts must be maintained as dynamic repository assets rather than static documents, so they can be updated as the program evolves.
  • Views produced from the EA Repository must act as a common language across program management, business units, and IT, enabling consistent decision-making.

Summary

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.

Reference Links

Disclaimer

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.

Back to Top

REI Avatar

Published by

REI
Categories:
Tags: , , , , , , ,

Leave a Reply

Discover more from Insight Arc | SAP, Enterprise Architecture & Supply Chain Strategy

Subscribe now to keep reading and get access to the full archive.

Continue reading