Architecture Roadmap and Transition Architectures: [Architecture engagement name]
Architecture Roadmap, Transition Architectures and Implementation and
Migration Plan for one engagement, the outputs of Phases E
(Opportunities and Solutions) and F (Migration Planning) of the
Architecture Development Method in The TOGAF Standard, 10th Edition
(2025 Update). It consolidates the gaps, groups them into work packages,
defines the plateaus between baseline and target, analyses dependencies,
value and risk per increment, estimates resources and cost, and hands the
plan to Phase G. Replace every [bracketed] value and every row marked
Example.
Document control
| Field | Value |
|---|
| Document ID | [ARM-ENG-001] |
| Engagement | [Architecture engagement name] |
| ADM phases | Phase E, Phase F |
| Based on | [ADD-ENG-001, version]; [AV-ENG-001, version] |
| Planning baseline date | YYYY-MM-DD |
| Planning horizon | [24 months] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner (lead architect) | [@lead-architect] |
| Programme manager | [@programme-manager] |
| Approvers / reviewers | [Architecture Board, sponsor, portfolio board, finance] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
Approvals
| Role | Name | Decision | Conditions | Date |
|---|
| Sponsor | [@sponsor] | [Approved / Approved with conditions / Rejected] | [Conditions] | YYYY-MM-DD |
| Architecture Board chair | [@chair] | [Decision] | [Conditions] | YYYY-MM-DD |
| Portfolio board | [@portfolio-lead] | [Decision] | [Conditions] | YYYY-MM-DD |
| Finance partner | [@finance] | [Decision] | [Conditions] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | Consolidated gaps and first work package grouping |
| 0.5 | YYYY-MM-DD | [@name] | Example: Transition Architectures, value and risk assessment, cost estimate |
| 1.0 | YYYY-MM-DD | [@name] | Example: Approved at board gate 3; handed to implementation governance |
Contents
1. Introduction
1.1 Purpose
This document turns the gaps between baseline and target architecture
into an ordered set of work packages, grouped into Transition
Architectures that each deliver measurable value. It is the basis for
portfolio funding, for Architecture Contracts with delivery teams and for
measuring progress toward the target.
1.2 Inputs
| Input | Reference | Status |
|---|
| Architecture Vision | [AV-ENG-001] | [Approved YYYY-MM-DD] |
| Architecture Definition Document | [ADD-ENG-001] | [Approved YYYY-MM-DD] |
| Architecture Requirements Specification | [Section 9 of ADD-ENG-001 or separate document] | [Status] |
| Current portfolio and capacity | [Portfolio plan reference] | [Status] |
| Business constraints | Example: CNS-01 budget cap, CNS-03 contract renewal, CNS-04 year-end freeze | Confirmed |
| [Input] | [Reference] | [Status] |
2. Implementation factors
| Factor ID | Factor | Category | Consequence for the plan |
|---|
| IMF-01 (Example) | Integration team is shared with two other programmes | Resource | Build the integration platform first, before parallel streams start |
| IMF-02 (Example) | Policy administration contract renewal date YYYY-MM-DD | Contract | Decide on policy system C consolidation before month 12 |
| IMF-03 (Example) | Year-end claims peak in [month] | Operational | No cut-over in [month]; plan go-live windows around it |
| IMF-04 (Example) | Data quality in policy system C is low | Risk | Start remediation in the first Transition Architecture |
| IMF-05 (Example) | Staff consultation needed for organisation change | Organisational | Start consultation three months before the new teams go live |
| IMF-06 (Example) | Capital budget phased over two financial years | Financial | Keep year 1 spend below the approved year 1 envelope |
| [IMF-nn] | [Factor] | [Risk / Issue / Resource / Contract / Operational / Financial / Organisational] | [Consequence] |
3. Consolidated gaps, solutions and dependencies
| Gap IDs | Gap summary | Proposed solution | Solution type | Depends on | Work package |
|---|
| GAP-T-01, GAP-T-02, GAP-T-03, GAP-T-04 (Example) | No modern integration or hosting for claims | Managed cloud hosting, API gateway, event streaming, observability | Reuse platform and configure | None | WP-01 |
| GAP-D-01, GAP-D-03 (Example) | No customer master or consent record | Customer data hub with matching, stewardship and consent | Buy | WP-01 | WP-02 |
| GAP-D-01 (quality) (Example) | Poor data in policy system C | Data cleansing and stewardship routines | Process and tooling | None | WP-02 |
| GAP-A-01, GAP-B-01, GAP-B-04, GAP-B-05, GAP-D-02 (Example) | Single manual claims path on aging system; monthly paper reporting | Claims platform package with triage rules, structured loss data and a daily claims dashboard | Buy and configure | WP-01, WP-02 | WP-03 |
| GAP-A-02, GAP-A-03, GAP-B-03 (Example) | No self-service; handlers use five screens | Portal, partner channel, handler workspace | Build on platform | WP-03 | WP-04 |
| GAP-A-05 (Example) | Policy system C end of life | Migrate policies to consolidated policy administration | Migrate | WP-02 | WP-05 |
| GAP-B-02 (Example) | Product-line teams | Cross-product claims teams and training | Organisational change | WP-03 | WP-06 |
| GAP-A-04, GAP-D-04 (Example) | Legacy CRM still running | Archive, switch off and terminate licence | Decommission | WP-02, WP-04 | WP-07 |
| [GAP-x-nn] | [Summary] | [Solution] | [Reuse / Buy / Build / Migrate / Decommission / Organisational] | [WP-nn] | [WP-nn] |
4. Work packages
| WP ID | Work package | Outcome | Candidate components | Owner | Estimate (kUSD) |
|---|
| WP-01 (Example) | Cloud and integration foundation | Claims domain can run in the cloud and integrate through APIs and events | CRC-11, CRC-12, CRC-13 | [@platform-lead] | 260 |
| WP-02 (Example) | Customer data hub and data quality | One golden customer record with consent | CRC-04, CRC-05 | [@data-owner] | 420 |
| WP-03 (Example) | Claims platform and triage | Simple claims decided automatically | CRC-01, CRC-06, CRC-07 | [@claims-it-lead] | 520 |
| WP-04 (Example) | Digital channels and handler workspace | Customers and partners self-serve; handlers use one workspace | CRC-03, CRC-08 | [@digital-lead] | 300 |
| WP-05 (Example) | Policy system C consolidation | Policy system C switched off | CRC-09 | [@policy-it-lead] | 460 |
| WP-06 (Example) | Claims organisation change | Cross-product teams working the new process | CRC-02 | [@head-of-claims] | 80 |
| WP-07 (Example) | Legacy CRM decommissioning | CRM switched off and archived | CRC-10 | [@application-owner] | 60 |
| Total | | | | 2,100 |
Use a project charter (business/project-charter) for each work package
that becomes a project.
5. Transition Architectures
5.1 Plateau overview
Example: three plateaus over 24 months. Each arrow is crossed only when
the exit criteria in section 8 are met and the Architecture Board has
completed its compliance review for that state.
5.2 Transition Architecture definitions
| ID | Name | Work packages completed | Architecture state reached | KPIs expected to move |
|---|
| TA-1 (Example) | Foundation | WP-01, WP-02 | Integration platform live; hub is master for customers from policy systems A and B; system C data cleansed and loaded read-only | KPI-02 to 60% |
| TA-2 (Example) | Digital claims | WP-03, WP-04, WP-06 | New claims platform with triage; portal, partner channel and workspace live; old claims system read-only | KPI-01 to 50%, KPI-03 down 12% |
| Target (Example) | Consolidated | WP-05, WP-07 | Policy system C and legacy CRM retired; all customers mastered in the hub | KPI-01 70%, KPI-02 98%, KPI-03 down 20%, KPI-04 met |
| [TA-n] | [Name] | [WP-nn] | [State] | [KPI movement] |
5.3 State evolution by building block
| Building block | Baseline | TA-1 | TA-2 | Target |
|---|
| Example: Integration | File transfer | Gateway and events (new); files remain for claims | Files retired for claims | Files retired |
| Example: Customer master | None | Hub for systems A and B | Hub for A, B and channels | Hub for all sources |
| Example: Claims system | Legacy | Legacy | New platform; legacy read-only | Legacy archived |
| Example: Policy system C | Live | Live, data cleansed | Live | Retired |
| Example: Legacy CRM | Live | Live | Read-only | Retired |
| [Building block] | [State] | [State] | [State] | [State] |
6. Dependency analysis
| Dependency ID | From | To | Type | Note |
|---|
| DEP-01 (Example) | WP-02 | WP-01 | Technical | Hub runs on the cloud platform and publishes events |
| DEP-02 (Example) | WP-03 | WP-02 | Data | Triage needs golden customer and cover data |
| DEP-03 (Example) | WP-04 | WP-03 | Technical | Channels call claims platform APIs |
| DEP-04 (Example) | WP-06 | WP-03 | Business | New teams work on the new process only |
| DEP-05 (Example) | WP-05 | WP-02 | Data | Migrated policies reference golden customer IDs |
| DEP-06 (Example) | WP-07 | WP-04 | Business | Service desk moves to the workspace before CRM switch-off |
| DEP-07 (Example) | WP-03 and WP-05 | Integration team | Resource | Same team; do not overlap their integration peaks |
| [DEP-nn] | [WP-nn] | [WP-nn or resource] | [Technical / Data / Business / Resource] | [Note] |
Critical path (Example): WP-01, WP-02, WP-03, WP-04, WP-07.
7. Business value and risk per increment
| Increment | Business value | Value score (1 to 5) | Delivery risk | Risk score (1 to 5) | Annual benefit (kUSD) |
|---|
| TA-1 (Example) | Customer data trusted for two policy lines; file transfer licence reduced | 3 | Matching accuracy, cloud readiness | 3 | 90 |
| TA-2 (Example) | Simple claims decided in 48 hours; handler productivity | 5 | Package fit, staff adoption | 4 | 450 |
| Target (Example) | Two legacy systems retired; lower run cost | 4 | Policy migration complexity | 4 | 290 |
| Total | | | | 830 |
Benefits are tracked after delivery in the benefits realization plan
(project/benefits-realization-plan).
8. Architecture Roadmap
| Milestone | Date | Gate | Exit criteria |
|---|
| TA-1 reached (Example) | 2027-08-30 | Board compliance review | Hub mastering A and B customers; integration platform in production; KPI-02 at least 60% |
| TA-2 reached (Example) | 2028-04-24 | Board compliance review | Triage live for motor and home; KPI-01 at least 50% |
| Target reached (Example) | 2028-12-18 | Board compliance review | Policy system C and CRM retired; KPI targets met or plan agreed |
| [Milestone] | YYYY-MM-DD | [Gate] | [Criteria] |
Publish a business-facing version of the roadmap with the product roadmap
template (product/roadmap) when needed.
9. Implementation and Migration Plan
9.1 Delivery approach per work package
| WP ID | Delivery approach | Migration strategy | Coexistence period | Rollback |
|---|
| WP-01 (Example) | Platform team, iterative | Not applicable (new) | None | Not applicable |
| WP-02 (Example) | Vendor plus internal data team | Incremental by source system | Hub and local stores in sync for 6 months | Revert consumers to local stores |
| WP-03 (Example) | Package configuration, agile releases | New claims on new platform; open claims run off on legacy | 4 months | Route new claims back to legacy |
| WP-04 (Example) | Product teams | New channels added beside phone and e-mail | Permanent (channels coexist) | Disable channel |
| WP-05 (Example) | Migration factory | Wave migration by product line | Per wave | Wave rollback plan |
| WP-06 (Example) | HR-led change programme | Team by team | 2 months per team | Return to old team structure |
| WP-07 (Example) | Application owner | Archive then switch off | 1 month read-only | Restore from archive |
| [WP-nn] | [Approach] | [Strategy] | [Period] | [Rollback] |
Detail migration waves and cut-over runbooks in the migration wave plan
(project/migration-wave-plan).
9.2 Decommissioning plan
| System | Retire after | Data disposition | Contract action | Owner |
|---|
| Example: Legacy claims system | TA-2 plus 4 months | Archive closed claims for retention period | Not applicable (owned) | [@claims-it-lead] |
| Example: Legacy CRM | Target | Archive contact history; delete beyond retention | Give notice by YYYY-MM-DD | [@application-owner] |
| Example: Policy system C | Target | Migrate active policies; archive closed ones | Terminate support contract | [@policy-it-lead] |
| [System] | [Milestone] | [Disposition] | [Action] | [@owner] |
9.3 Delivery risks
| Risk ID | Risk | Likelihood | Impact | Mitigation | Owner |
|---|
| RMR-01 (Example) | Integration team overloaded when WP-03 and WP-05 overlap | High | High | Stagger integration peaks; add partner capacity | [@programme-manager] |
| RMR-02 (Example) | Package upgrade during WP-03 breaks configuration | Medium | Medium | Freeze package version until TA-2 | [@claims-it-lead] |
| RMR-03 (Example) | Contract notice date for CRM missed | Low | High | Calendar reminder and board milestone | [@application-owner] |
| [RMR-nn] | [Risk] | [H / M / L] | [H / M / L] | [Mitigation] | [@owner] |
Carry these into the programme RAID log (project/raid-log).
10. Resource and cost estimates
10.1 Cost per increment
| Increment | Work packages | Cost (kUSD) |
|---|
| TA-1 (Example) | WP-01 (260), WP-02 (420) | 680 |
| TA-2 (Example) | WP-03 (520), WP-04 (300), WP-06 (80) | 900 |
| Target (Example) | WP-05 (460), WP-07 (60) | 520 |
| Total | | 2,100 |
10.2 Contingency, effort and payback
Example assumptions: contingency of 15%, labour at 60% of base cost,
blended rate of 0.8 kUSD per person-day, and annual benefits of 830 kUSD
once the target is reached (section 7).
Cbase=i=1∑7CWPi=680+900+520=2100 kUSD Ctotal=Cbase×(1+0.15)=2100×1.15=2415 kUSD E=0.80.60×Cbase=0.81260=1575 person-days Tpayback=BannualCtotal=8302415≈2.9 years The total of USD 2,415 thousand stays within the capital cap of USD 2.5
million (constraint CNS-01). The simple payback ignores benefits realised
before the target state; a full discounted analysis belongs in the
business case (business/business-case) or the TCO analysis
(architecture/tco-analysis).
10.3 Resource plan
| Role | TA-1 (FTE) | TA-2 (FTE) | Target (FTE) | Source |
|---|
| Example: Platform engineers | 3 | 1 | 1 | Internal platform team |
| Example: Integration engineers | 2 | 3 | 2 | Internal plus partner |
| Example: Data engineers and stewards | 3 | 1 | 2 | Internal data team |
| Example: Claims package specialists | 0 | 4 | 0 | Vendor |
| Example: Product team (channels) | 0 | 5 | 0 | Internal digital team |
| Example: Migration factory | 0 | 0 | 4 | Partner |
| [Role] | [FTE] | [FTE] | [FTE] | [Source] |
11. Governance hand-off to Phase G
11.1 Architecture Contracts to issue
| Contract ID | Work package | Delivery party | Key architecture requirements | Review points |
|---|
| AC-01 (Example) | WP-01 | Platform team | ARS-TEC-01, ARS-DAT-02 | Design, pre-production |
| AC-02 (Example) | WP-02 | Data hub vendor and data team | ARS-DAT-01, ARS-INT-01 | Design, pre-production, TA-1 |
| AC-03 (Example) | WP-03 | Claims package vendor | ARS-BUS-01, ARS-APP-01 | Design, pre-production, TA-2 |
| [AC-nn] | [WP-nn] | [Party] | [ARS IDs] | [Points] |
Contracts and compliance reviews follow the Architecture Board charter
(architecture/architecture-governance-charter). Delivery teams submit
designs with the architecture review request
(architecture/architecture-review-request).
11.2 Roadmap change control
| Change type | Decided by | Record |
|---|
| Date change within an increment, no change to Transition Architecture | Programme manager | Programme log |
| Work package scope or cost change above [10%] | Architecture Board and sponsor | Change request and new roadmap version |
| Change to a Transition Architecture or the target | Architecture Board | Change request; Phase H assessment |
| New gap or requirement | Lead architect, then Board | Requirements impact assessment |
11.3 Monitoring after hand-off
[Describe how progress toward each Transition Architecture is reported to
the board: KPI dashboard, quarterly roadmap review, and fitness functions
where they can be automated (architecture/fitness-functions).] Track
architecture debt accepted during delivery in the tech debt register
(architecture/tech-debt-register).
12. Glossary and references
12.1 Glossary
| Term | Meaning in this document |
|---|
| Work package | A unit of change with one owner, an outcome and an estimate |
| Transition Architecture | A stable, operable architecture state between baseline and target |
| Plateau | A synonym for a stable intermediate architecture state, used in modelling |
| Architecture Roadmap | The ordered set of work packages and transitions from baseline to target |
| Implementation and Migration Plan | How the work packages are delivered and how the enterprise moves between states |
| Architecture Contract | Agreement between the architecture function and a delivery party on what must be built and how compliance is checked |
| Critical path | The chain of dependent work packages that sets the earliest completion date |
| [Term] | [Meaning] |
12.2 References
| ID | Reference | Version / date |
|---|
| REF-01 | The TOGAF Standard, 10th Edition (The Open Group), 2025 Update | June 2025 |
| REF-02 | Architecture Vision (architecture/togaf-architecture-vision) | [x.y] |
| REF-03 | Architecture Definition Document (architecture/architecture-definition-document) | [x.y] |
| REF-04 | Architecture Board Charter (architecture/architecture-governance-charter) | [x.y] |
| REF-05 | Migration wave plan (project/migration-wave-plan) | [x.y] |
| REF-06 | Application portfolio rationalization (architecture/application-portfolio-rationalization) | [x.y] |
| REF-07 | Business case (business/business-case) | [x.y] |
Standard and licence note
Structure aligned with The TOGAF Standard, 10th Edition (2025 Update),
published by The Open Group: Phase E (Opportunities and Solutions) and
Phase F (Migration Planning) of the Architecture Development Method, the
Architecture Roadmap, Transition Architectures and the Implementation and
Migration Plan, with consolidated gaps, dependencies and a value and risk
assessment per increment. Only phase and deliverable names are used; this
template is original text and reproduces no definitions, tables or other
text from the standard. TOGAF is a registered trademark of The Open Group.
Check the current edition at opengroup.org and obtain the standard for its
full guidance. Template licence: MIT.