Phase F: Migration Planning — Making the Roadmap Real

Phase: Phase F — Migration Planning Perspective: Enterprise Architect

Phase F is where architecture stops being a strategy document and becomes a delivery plan. Every hour spent here prevents months of rework in implementation.

Key Inputs

Architecture Roadmap from Phase E
Transition Architectures
Existing project and programme plans
Resource and budget constraints
Business change readiness assessment
IT delivery capability assessment

The Process

Confirm priorities with stakeholders
Estimate costs, resources, and timelines
Conduct risk and dependency analysis
Define migration sequencing plan
Align with existing programmes and investments
Secure formal commitments and governance sign-off

Deliverables

Finalised Architecture Roadmap
Migration Plan
Project charters / initiation documents
Resource and budget commitments
Risk Register
Capability Development Plan

Practitioner Perspective

The Migration Plan is not an architecture artefact — it is a business commitment document. Treat it accordingly. Engage finance to ensure funding is secured, not just estimated. A roadmap without committed budget is a wish list.

Work with HR and change management to assess organisational readiness. The biggest migration risks are human, not technical. Data migration is always underestimated. Legacy system decommissioning always takes longer than planned. Organisational resistance to change always surfaces later than expected.

Be explicit about what must be retired. Decommissioning legacy systems is as important as building new capability — the costs of maintaining the old world while building the new one compound quickly.

The most common mistake: Planning the build without planning the cutover. The Migration Plan must include detailed transition plans for each system cutover, not just project delivery milestones.

Practical tips:

Build a dependency network diagram across all work packages — the critical path often runs through unglamorous foundational work like identity management or data migration
Include a "decommissioning plan" for every system being replaced — name the date, the owner, and the conditions for retirement
Conduct a formal change readiness assessment: survey the business areas most affected and surface resistance early
Create a "what good looks like" definition for each Transition Architecture — how will you know when you have successfully reached each intermediate state?

Part of a series: TOGAF from an Enterprise Architect's Perspective