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 Part 2 defines specific 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: Ensure that the business value and cost of work packages are understood

Each work package 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.

Objective 3: Ensure that the transition from the baseline to the target is achievable

Phase F must confirm 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.

Objective 4: Coordinate the migration plan with the enterprise's management frameworks

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. Phase F is where that translation happens.

C220 describes multiple criteria that should drive roadmap sequencing. 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.

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. Module 50 covers readiness assessment in full, but 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.