Migration planning and roadmap logic

Phase F takes the initial Architecture Roadmap produced in Phase E and subjects it to the discipline of migration planning. C220 defines three objectives for Phase F.

Objective 1: Finalise the Architecture Roadmap and the Implementation and Migration Plan

Phase E produced an initial roadmap. Phase F refines it by applying sequencing logic, readiness evidence, and cost/benefit analysis. The result is a finalised roadmap that has been tested against reality rather than merely sketched from ambition. Phase F also produces the Implementation and Migration Plan, which translates the architecture roadmap into delivery terms that project management can execute.

Objective 2: Coordinate the plan with the enterprise's approach to managing change

The Architecture Roadmap speaks in architecture terms. The Implementation and Migration Plan must also speak in delivery terms that align with the enterprise's project management, change management, and financial governance frameworks, so that the migration sits coherently within the overall change portfolio rather than competing with it. Phase F is where that translation happens.

Objective 3: Ensure that the business value and cost of work packages are understood

Each work package and transition architecture must be justified in terms that business stakeholders can evaluate. Phase F requires that the value delivered by each package is visible and that the cost of delivery is estimated well enough to support investment decisions. This objective prevents work packages from being sequenced without business justification.

The achievability test: essential practice, not a fourth objective

The standard stops at those three objectives, but sound migration planning also confirms that the enterprise can actually absorb the change at the planned pace. This means testing readiness across governance, information, technology, and organisational dimensions. If the transition is not achievable as planned, Phase F should reshape the roadmap rather than hand forward a plan that will fail.

Roadmap sequencing is driven by more than one kind of logic. This course groups the drivers a migration plan must balance into seven criteria. No single criterion is sufficient on its own. The enterprise must balance them, and the balance should be explicit and reviewable.

Dependency logic

Some work genuinely has to happen first because other work would be unsafe or incoherent without it. Dependency is the strongest sequencing driver because violating a genuine dependency creates failure, not just suboptimal ordering. Dependencies can be technical (Platform X before Application Y), informational (data authority before publication), organisational (governance forum before exception management), or regulatory (licence condition before service launch).

Value logic

The enterprise should know which steps create meaningful business or governance benefit early enough to matter. Value logic sequences high-value deliverables early to maintain executive support, demonstrate that the programme is real, and create feedback that improves later delivery. Value logic must be balanced against dependency logic: a high-value deliverable that depends on an unfinished foundation cannot be accelerated without risk.

Risk logic

The plan should reduce high-consequence uncertainty instead of pushing critical risk to the final release gate. Risk logic says: address the highest-uncertainty items early so that the enterprise learns whether its assumptions are valid before it has committed irreversibly. A roadmap that defers all high-risk work to the last phase is optimistic rather than disciplined.

Readiness logic

The organisation's current ability to absorb change should influence the order and pace of migration. Readiness covers governance maturity, data quality, platform preparedness, team capability, and stakeholder willingness. If the enterprise rates its governance readiness as low, starting with a work package that requires strong governance creates unnecessary adoption risk.

Cost and resource logic

The sequencing should reflect the enterprise's budget cycle, resource availability, and funding approval process. A work package that requires a large capital investment may need to be aligned with the enterprise's annual planning cycle. A work package that requires scarce specialist skills may need to wait until those skills are available.

Regulatory and contractual logic

External obligations may impose fixed sequencing constraints. A regulatory deadline overrides internal preference. A contractual dependency constrains what can be changed and when. These constraints are non-negotiable inputs to the roadmap.

Stakeholder impact logic

The sequencing should consider how much change different stakeholder groups can absorb simultaneously. If the same group is affected by three work packages running in parallel, the cumulative impact may overwhelm their capacity even if each package is individually manageable.

Phase F inherits the initial Architecture Roadmap from Phase E and turns it into a governed delivery path. Understanding what Phase F takes in and what it must produce shows why the sequencing criteria in 46.2 are not optional extras: without them, Phase F has no disciplined way to convert an initial roadmap into a plan that delivery teams can actually run.

Key inputs

• Initial Architecture Roadmap. The work packages, transition architectures, and proposed order of change produced in Phase E. Phase F refines this rather than starting from a blank page.
• Implementation and Migration Strategy. The high-level delivery approach chosen in Phase E, such as phased delivery, parallel running, or a pilot strategy. This choice constrains how Phase F can sequence the detailed plan.
• Architecture Definition Document and Architecture Requirements Specification. The target and baseline architectures and the requirements the migration must respect, so that sequencing decisions do not quietly drift from what was agreed.
• Capability assessments and readiness evidence. The governance, information, technology, and organisational readiness findings that feed the readiness logic described in 46.2.
• Enterprise project, portfolio, and financial management frameworks. The budget cycles, resourcing constraints, and change-management processes the migration plan must align with, since Phase F is where architecture sequencing meets delivery governance.

Key outputs

• Finalised Architecture Roadmap. The Phase E roadmap refined by sequencing logic, readiness evidence, and cost and benefit analysis.
• Implementation and Migration Plan. The delivery-facing document that adds project boundaries, resource assignments, timelines, and budgets to the Architecture Roadmap, described further in 46.4.
• Implementation Governance Model. The governance arrangement that carries the plan into delivery. It gives each delivery team an architecture contract binding their work to the agreed architecture, so that build activity does not quietly drift from the design it was meant to realise. This output is what lets Phase G govern implementation against the plan Phase F produced, rather than against a document nobody is checking delivery against.
• Updated Architecture Definition Document. Reflecting any changes that migration planning has exposed in the target architecture itself.

The Phase F steps

C220 sets out Phase F as a sequence of steps that move from confirming scope through to producing the finalised roadmap and plan. The course groups the standard's step logic into the following stages.

Confirm management framework interactions.Establish how the migration plan will interact with the enterprise's existing programme, portfolio, and operations management frameworks, so the plan is built to fit into governance that already exists rather than to compete with it.

Assign business value to each work package. Apply value logic so that the business case for each package is explicit and can be compared against its cost, which supports Objective 3 in 46.1.

Estimate resource requirements, project timing, and availability. Apply cost and resource logic and confirm that the timings implied by dependency and risk logic are actually deliverable given the resources on hand.

Prioritise the migration projects through cost and benefit assessment. Balance the sequencing criteria from 46.2 against one another explicitly, so the final order can be defended rather than merely presented.

Confirm architecture roadmap and update the Architecture Definition Document. Finalise the roadmap and feed back any changes the migration planning work has surfaced in the target architecture.

Generate the Implementation and Migration Plan.Produce the delivery-facing plan and, alongside it, confirm the Implementation Governance Model that will bind delivery teams to the architecture as work proceeds. This is the step that hands Phase F's work forward into Phase G, where implementation is governed against exactly this plan and model rather than against a stale or disconnected roadmap.

The standard distinguishes between two outputs that teams often conflate. Keeping them separate matters because they serve different audiences and answer different questions.

The Architecture Roadmap describes the sequence of transition architectures from baseline to target, with work packages assigned to each transition state and the sequencing rationale made explicit. Its audience is the Architecture Board and enterprise leadership. It answers: what changes, in what order, and why?

The Implementation and Migration Plan translates the Architecture Roadmap into delivery terms. It adds project boundaries, resource assignments, timelines, budgets, and change-management activities. Its audience is programme management and delivery teams. It answers: who delivers what, when, and how?

The Architecture Roadmap should be stable enough that the Implementation and Migration Plan can be built on it. If the roadmap changes frequently, the plan becomes unreliable. If the plan diverges from the roadmap without architecture review, the enterprise loses its governed path.

Decorative sequencing. The bars are arranged to look balanced across the calendar rather than to reflect dependency, readiness, or risk. This is the most common failure. The roadmap looks professional but cannot survive its first encounter with reality.

Hidden dependencies. The roadmap shows five work packages in parallel with no dependencies marked. This usually means the dependency analysis has not been done, not that the packages are genuinely independent. When a hidden dependency surfaces during delivery, the entire sequence may need to be reworked.

Value-blind sequencing. The roadmap sequences work by technical complexity or team availability rather than by business value. This means the enterprise invests heavily before seeing any business return, which erodes executive support and creates the conditions for programme cancellation.

Risk deferral. The highest-risk work packages are scheduled last, when the budget is committed and the enterprise has the least flexibility to respond to surprises. Risk logic says the opposite: test the riskiest assumptions early while you still have room to adapt.

Readiness denial. The roadmap assumes uniform readiness across the enterprise, ignoring evidence that some parts of the organisation are not prepared for the change at the planned pace. The implication for roadmap logic is simple: readiness gaps should reshape the sequence, not be papered over with optimistic assumptions.

Frozen roadmap. The roadmap is treated as a fixed plan that cannot be adjusted when new evidence emerges. A roadmap that cannot respond to learning is not a plan. It is a prediction, and predictions about complex enterprise change are reliably wrong.

A credible roadmap is one that has been reviewed with the following questions at each evidence gate and at every significant scope or constraint change.

• Why must this work package happen before the next one? If the answer is "because it appears earlier on the Gantt chart," the dependency logic is missing.
• What would break if the order were reversed? This question tests whether the dependency is genuine or assumed. If nothing would break, the dependency may be artificial.
• Which assumptions does the current sequence depend on still being true? This question surfaces the fragile assumptions that could invalidate the roadmap if they change.
• What evidence would justify keeping or changing the sequence at the next review point? This question connects the roadmap to evidence gates rather than leaving the sequence on autopilot.
• Which stakeholder groups are affected by overlapping work packages, and can they absorb the cumulative change? This question tests adoption feasibility, not just technical feasibility.
• Has any readiness assessment changed since the sequence was last confirmed? This question prevents the roadmap from drifting away from the enterprise's actual capacity.

The London roadmap is a strong teaching example because the work packages interact across domains. Customer transparency, authority control, publication quality, planning reuse, and resilience strengthening cannot be sequenced casually without creating hidden debt.

Applying the sequencing criteria to London

Dependency logic says data-authority codification must come before publication-channel migration, because publishing data from unclear authority sources creates compliance risk. The case-management spine must be in place before evidence workflows can be automated. OT/IT assurance integration depends on the publication foundation being stable.

Value logic says the case-management spine delivers early customer value because it improves connection-application transparency from the first deployment. This maintains executive support through the less visible authority and standards work.

Risk logic says the data-authority question is the highest-uncertainty item. If the enterprise cannot settle data ownership for its ten most important publication types, every downstream work package is at risk. That uncertainty should be resolved first.

Readiness logic says governance readiness is lower than technology readiness across the London enterprise. That means work packages requiring strong governance discipline (such as exception management and standards enforcement) should not be scheduled before governance maturity has been deliberately improved.

Regulatory logic says Ofgem transparency requirements create fixed deadlines that constrain the publication-quality work. Those deadlines are non-negotiable inputs to the roadmap.

London roadmap sequence

1. Data-authority codification and case-management spine (highest dependency, highest risk, early value)
2. Publication-channel migration and authority controls (dependent on step 1, regulatory deadline)
3. Model pipeline and standards integration (dependent on step 2, governance readiness gating)
4. Cross-layer assurance hardening (dependent on stable publication foundation)

Each sequencing decision can be explained by citing a specific criterion. If an executive asks why customer self-service improvements are not first, the answer references the dependency chain: self-service quality depends on publication quality, which depends on data authority. The customer improvement is not deprioritised. It is sequenced after its prerequisites.