# Cloud Adoption Strategy: [Organisation or programme name]

> Strategy and plan for adopting public cloud across an organisation:
> motivations and business outcomes, current state and readiness, the
> cloud operating model, the landing zone and platform approach, the
> workload portfolio and its migration and modernisation dispositions
> (the 7 Rs), governance, security and compliance, skills and
> organisation, the financial model and FinOps, the roadmap and the
> risks. Mapping tables link each section to the Microsoft Cloud
> Adoption Framework for Azure (seven phases: Strategy, Plan, Ready,
> Adopt, Govern, Secure, Manage, as published in August 2026), the AWS
> Cloud Adoption Framework (six perspectives, whitepaper of 22 November
> 2021) and the Google Cloud Adoption Framework (four themes and three
> maturity phases). Provider-neutral. Replace every `[bracketed]` value
> and every row marked *Example*.

<!--
Guidance: How to use this template
- Write one strategy per organisation or per adoption programme. It is a
  decision document for executives and a plan for the platform and
  workload teams, so keep each section short and decision-oriented.
- Fill section 1 (motivations and outcomes) with the executive sponsor
  before anything else. A strategy that cannot name measurable outcomes
  turns into a data centre exit project with no way to judge success.
- Use the provider mappings in section 13 to borrow checklists from the
  framework of your chosen provider, but keep decisions in this document.
- Detailed designs live in their own documents: Landing zone design
  (`architecture/landing-zone-design`), Migration wave plan
  (`project/migration-wave-plan`), Modernization assessment
  (`architecture/modernization-assessment`), TCO analysis
  (`architecture/tco-analysis`), FinOps cost review
  (`ops/finops-cost-review`), Security architecture
  (`security/security-architecture`).
-->

## Document control

<!-- Guidance: Identify the programme, its sponsor and the scope of the estate covered. A change of target provider, scope or funding model is a new major version. -->

| Field | Value |
|---|---|
| Document ID | [CAS-001] |
| Programme | [Cloud adoption programme name] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@cloud-programme-lead] |
| Executive sponsor | [@cio-or-cto] |
| Approvers/reviewers | [@cfo-delegate], [@ciso], [@enterprise-architect], [@head-of-operations] |
| Target provider(s) | [Primary provider], [Secondary provider, if any] |
| Estate in scope | [Business units, data centres, number of applications] |
| Planning horizon | [YYYY-MM-DD to YYYY-MM-DD] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
| Next review | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Executive sponsor | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Finance | [@name] | [Decision] | YYYY-MM-DD |
| Security and risk | [@name] | [Decision] | YYYY-MM-DD |
| Enterprise architecture | [@name] | [Decision] | YYYY-MM-DD |
| Operations | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft for sponsor review |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Readiness assessment results and portfolio dispositions added |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved by the steering committee; funding for year 1 released |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Motivations and business outcomes](#1-motivations-and-business-outcomes)
2. [Current state and readiness](#2-current-state-and-readiness)
3. [Cloud operating model](#3-cloud-operating-model)
4. [Landing zone and platform approach](#4-landing-zone-and-platform-approach)
5. [Workload portfolio and dispositions](#5-workload-portfolio-and-dispositions)
6. [Governance](#6-governance)
7. [Security and compliance](#7-security-and-compliance)
8. [Skills and organisation](#8-skills-and-organisation)
9. [Financial model and FinOps](#9-financial-model-and-finops)
10. [Roadmap](#10-roadmap)
11. [Risks and assumptions](#11-risks-and-assumptions)
12. [Decisions and traceability](#12-decisions-and-traceability)
13. [Framework mappings](#13-framework-mappings)
14. [Glossary and references](#14-glossary-and-references)

## 1. Motivations and business outcomes

<!-- Guidance: Why the organisation is adopting cloud and how success will be measured. Questions: which business event triggers the move (contract end, hardware refresh, growth, acquisition, regulation)? Which outcomes matter to whom? Pitfall: listing "cost savings" without a baseline or a date. -->

### 1.1 Motivations

State the triggers and motivations that make cloud adoption a priority
now. Separate critical business events, which carry a date, from
longer-term innovation goals, which carry a value. Rank them, because
they drive the sequencing in section 10.

| ID | Motivation | Type | Trigger date | Sponsor |
|---|---|---|---|---|
| MOT-001 *(Example)* | Exit the leased data centre when the contract ends | Critical business event | YYYY-MM-DD | @cfo |
| MOT-002 *(Example)* | Shorten time to launch new digital products | Innovation | n/a | @chief-digital-officer |
| MOT-003 *(Example)* | Meet recovery objectives for tier 1 services | Risk reduction | YYYY-MM-DD | @cro |
| [MOT-NNN] | [Motivation] | [Type] | [Date] | [@owner] |

### 1.2 Business outcomes and measures

Express each outcome as a measurable change against a baseline. Each
outcome needs an owner outside IT where possible, a baseline measured
before migration starts and a target date.

| ID | Outcome | Measure | Baseline | Target | Date | Owner |
|---|---|---|---|---|---|---|
| OUT-001 *(Example)* | Lower infrastructure run cost | Annual infrastructure cost per active customer | [Value] | [Value] | YYYY-MM-DD | @cfo |
| OUT-002 *(Example)* | Faster delivery | Lead time from commit to production for tier 2 apps | [14 days] | [1 day] | YYYY-MM-DD | @head-of-engineering |
| OUT-003 *(Example)* | Resilience | Share of tier 1 services with a tested RTO of 1 hour or less | [20 %] | [100 %] | YYYY-MM-DD | @head-of-operations |
| [OUT-NNN] | [Outcome] | [Measure] | [Baseline] | [Target] | YYYY-MM-DD | [@owner] |

### 1.3 Strategic principles

Write five to eight principles that settle recurring debates before they
start. Each one should rule something out.

- *Example:* Managed services before self-managed software, unless an
  exception is approved by the architecture board.
- *Example:* One primary provider; a second provider only for a named
  regulatory or commercial reason.
- *Example:* Every workload enters cloud through the landing zone; no
  accounts, subscriptions or projects outside it.
- *Example:* Migrate first and modernise after, except where section 5
  records a reason to refactor during the move.
- [Principle]

## 2. Current state and readiness

<!-- Guidance: Describe the estate and the organisation as they are, with evidence. Questions: what runs where, on what contracts, with which skills? Where are the readiness gaps? Pitfall: an inventory copied from a CMDB that nobody has validated. -->

### 2.1 Estate summary

| Item | Value | Source |
|---|---|---|
| Data centres and hosting contracts | *Example:* 2 sites; site A lease ends YYYY-MM-DD | Facilities contracts |
| Applications in scope | *Example:* 310 applications, 74 business critical | Validated portfolio, section 5 |
| Servers and storage | *Example:* 2,100 virtual machines, 180 physical hosts, 1.4 PB | Discovery tool export YYYY-MM-DD |
| Existing cloud use | *Example:* 46 unmanaged accounts and subscriptions, 9 SaaS platforms | Billing records |
| Licences with mobility constraints | [Database, operating system and middleware licences] | Licence register |
| Network connectivity | [Current WAN, internet breakout, existing cloud links] | Network team |

### 2.2 Readiness assessment

Rate readiness on evidence. Use the same five areas as the operating
model so that each gap maps to a workstream.

| Area | Current state | Rating (1 to 5) | Gap | Action ID |
|---|---|---|---|---|
| Business and strategy *(Example)* | Outcomes agreed for 2 of 5 business units | 2 | No shared business case | ACT-001 |
| People and skills *(Example)* | 6 certified engineers, no platform team | 2 | Platform engineering capacity | ACT-004 |
| Governance and finance *(Example)* | No cloud policy, costs not allocated | 1 | Policies, tagging, showback | ACT-006 |
| Platform and operations *(Example)* | Manual provisioning, on-premises monitoring only | 2 | Landing zone, observability | ACT-002 |
| Security *(Example)* | Strong identity provider, no cloud security baseline | 3 | Guardrails, logging | ACT-003 |
| [Area] | [State] | [1 to 5] | [Gap] | [ACT-NNN] |

Rating scale: 1 no capability, 2 ad hoc, 3 defined, 4 managed and
measured, 5 optimised. Record the date and the people who rated each
area, and repeat the assessment at every major roadmap milestone.

### 2.3 Readiness actions

| ID | Action | Closes gap in | Owner | Due |
|---|---|---|---|---|
| ACT-001 *(Example)* | Agree outcomes and a shared business case with every business unit in scope | Business and strategy | @cloud-programme-lead | YYYY-MM-DD |
| ACT-002 *(Example)* | Build the landing zone and central observability | Platform and operations | @platform-lead | YYYY-MM-DD |
| ACT-003 *(Example)* | Define the cloud security baseline, guardrails and central logging | Security | @security-architect | YYYY-MM-DD |
| ACT-004 *(Example)* | Form the platform team and start the learning plan in section 8.2 | People and skills | @head-of-engineering | YYYY-MM-DD |
| ACT-005 *(Example)* | Review licence mobility for databases and middleware (RSK-004) | Platform and operations | @procurement | YYYY-MM-DD |
| ACT-006 *(Example)* | Publish cloud policies, the tagging standard and monthly showback | Governance and finance | @finops-lead | YYYY-MM-DD |
| [ACT-NNN] | [Action] | [Area] | [@owner] | YYYY-MM-DD |

## 3. Cloud operating model

<!-- Guidance: Decide who owns what once workloads run in cloud. Questions: which team builds and runs the platform, which teams run workloads, who sets policy and who pays? Pitfall: keeping the on-premises ticket-driven model and expecting cloud speed. -->

### 3.1 Operating model choice

Choose the model that matches the organisation's appetite for central
control versus team autonomy, and say why the alternatives were
rejected.

| Model | Description | Chosen | Reason |
|---|---|---|---|
| Centralised operations | A central team builds and runs all cloud resources | [Yes / No] | [Reason] |
| Enterprise platform with workload autonomy | A platform team provides the landing zone and paved roads; workload teams build and run their own services inside guardrails | [Yes / No] | *Example:* Matches product team structure; keeps policy central |
| Decentralised | Each business unit runs its own cloud estate | [Yes / No] | [Reason] |
| [Hybrid variant] | [Description] | [Yes / No] | [Reason] |

### 3.2 Responsibilities

| Capability | Cloud centre of excellence | Platform team | Workload team | Security | Finance |
|---|---|---|---|---|---|
| Cloud policy and standards | A | C | I | R | C |
| Landing zone build and run | C | A/R | I | C | I |
| Account, subscription or project vending | I | A/R | R (request) | C | I |
| Workload architecture and operation | C | C | A/R | C | I |
| Security monitoring and response | I | C | R | A | I |
| Budgets, showback and optimisation | C | R | R | I | A |

R responsible, A accountable, C consulted, I informed.

### 3.3 Interaction model

The diagram shows how policy, guardrails and money flow to the platform
team, and how vended environments and feedback flow between the
platform and workload teams.

```mermaid
flowchart LR
  CCOE[Cloud centre of excellence<br/>policy and standards] --> PLAT[Platform team<br/>landing zone and paved roads]
  SEC[Security team<br/>guardrails and monitoring] --> PLAT
  FIN[Finance and FinOps<br/>budgets and showback] --> PLAT
  PLAT -->|vended environments| WT1[Workload team A]
  PLAT -->|vended environments| WT2[Workload team B]
  WT1 -->|feedback and requests| PLAT
  WT2 -->|feedback and requests| PLAT
  WT1 -->|cost and usage data| FIN
  WT2 -->|cost and usage data| FIN
```

## 4. Landing zone and platform approach

<!-- Guidance: Summarise the foundation decisions here and keep the detail in the landing zone design. Questions: build or adopt an accelerator? Which shared services are central? How do teams get environments? Pitfall: migrating the first workloads before identity, network and logging are in place. -->

The landing zone is the governed foundation into which every workload is
deployed: resource hierarchy, identity, network, security baseline,
logging, policy as code and the vending process. Record the strategic
choices here; the full design belongs in the Landing zone design
(`architecture/landing-zone-design`).

| Decision | Choice | Rationale | Decision ID |
|---|---|---|---|
| Implementation approach *(Example)* | Provider reference implementation, customised through IaC | Faster start; known upgrade path | DEC-002 |
| Hierarchy pattern *(Example)* | Separate platform and workload branches, environments split at account, subscription or project level | Clear policy inheritance | DEC-003 |
| Network topology *(Example)* | Hub and spoke with central egress inspection | Matches inspection requirements | DEC-004 |
| Identity *(Example)* | Federation from the existing identity provider, no local cloud users | Single joiner, mover and leaver process | DEC-005 |
| Environment vending *(Example)* | Self-service request through the service portal, automated provisioning in under one day | Supports workload autonomy | DEC-006 |
| [Decision] | [Choice] | [Rationale] | [DEC-NNN] |

List the paved-road platform services the platform team will offer, with
the date each becomes available, because the migration waves in section
10 depend on them.

| Service | Description | Available from | Owner |
|---|---|---|---|
| Container platform *(Example)* | Managed Kubernetes with standard ingress and observability | YYYY-MM-DD | @platform-lead |
| Managed relational database *(Example)* | Standard configurations with backup and encryption defaults | YYYY-MM-DD | @platform-lead |
| CI/CD templates *(Example)* | Pipeline templates with policy checks and artefact signing | YYYY-MM-DD | @devex-lead |
| [Service] | [Description] | YYYY-MM-DD | [@owner] |

## 5. Workload portfolio and dispositions

<!-- Guidance: Decide what happens to each application at portfolio level. Questions: which applications go first, which are retired, which need modernisation? Pitfall: assigning refactor to many applications in a time-boxed data centre exit. -->

### 5.1 Disposition vocabulary (7 Rs)

Use the seven migration strategies described in AWS Prescriptive
Guidance. They are provider-neutral in practice; the other frameworks
use similar categories under different names.

| Strategy | Meaning in this programme | Typical use |
|---|---|---|
| Retire | Decommission or archive; no cloud target | Low value, duplicate or unused applications |
| Retain | Keep in the source environment for now; revisit at a set date | Regulatory, hardware or dependency constraints |
| Rehost | Move to cloud virtual machines without changing the application | Time-boxed exits, large volumes |
| Relocate | Move at hypervisor or platform level to a cloud version of the same platform | Large virtualised estates with a compatible cloud service |
| Repurchase | Replace with a different product, usually SaaS | Commodity capabilities such as HR or ticketing |
| Replatform | Move with targeted optimisation, such as a managed database | Reduce operational effort without redesign |
| Refactor or re-architect | Redesign to use cloud-native capabilities | Strong business case for agility or scale |

### 5.2 Portfolio summary

| Disposition | Applications | Share | Notes |
|---|---|---|---|
| Retire *(Example)* | 42 | 14 % | Confirmed with business owners |
| Retain *(Example)* | 18 | 6 % | Mainframe and plant systems; review YYYY-MM-DD |
| Rehost *(Example)* | 121 | 39 % | Mostly in waves 2 to 6 |
| Relocate *(Example)* | 35 | 11 % | Virtualised cluster in site A |
| Repurchase *(Example)* | 22 | 7 % | SaaS replacements |
| Replatform *(Example)* | 52 | 17 % | Database moves to managed services |
| Refactor *(Example)* | 20 | 6 % | Customer-facing products only |
| Total *(Example)* | 310 | 100 % | |

Record per-application dispositions, scoring and target states in the
Modernization assessment (`architecture/modernization-assessment`) and
the sequencing in the Migration wave plan (`project/migration-wave-plan`).

### 5.3 Cloud-native and new workloads

New products should start in cloud on the paved road. State which
patterns are preferred for new builds (for example serverless functions,
containers or managed data services), which require an architecture
review, and how teams request an exception.

## 6. Governance

<!-- Guidance: Define how decisions are made, how policy is set and how compliance is checked. Questions: who approves exceptions? Which policies are enforced automatically? How often are they reviewed? Pitfall: governance written as a document but not enforced in code. -->

### 6.1 Governance bodies

| Body | Purpose | Members | Cadence |
|---|---|---|---|
| Steering committee *(Example)* | Funding, priorities, roadmap changes | Sponsor, finance, business unit heads | Monthly |
| Architecture board *(Example)* | Standards, exceptions, platform roadmap | Enterprise and platform architects, security | Fortnightly |
| Cloud centre of excellence *(Example)* | Policy drafting, enablement, metrics | Cross-functional core team | Weekly |
| [Body] | [Purpose] | [Members] | [Cadence] |

### 6.2 Cloud policies

| ID | Policy statement | Enforcement | Owner |
|---|---|---|---|
| POL-001 *(Example)* | Resources are deployed only in approved regions | Preventive guardrail at hierarchy root | @security-architect |
| POL-002 *(Example)* | Every resource carries the mandatory cost tags | Deny on create, weekly compliance report | @finops-lead |
| POL-003 *(Example)* | Data classified confidential is encrypted with customer-managed keys | Detective control, remediation within 30 days | @ciso |
| [POL-NNN] | [Statement] | [Preventive / Detective / Manual review] | [@owner] |

### 6.3 Exception process

Describe how a team requests a policy exception, who decides, how long
an exception lasts and where it is recorded. Every exception carries an
expiry date and a named risk owner.

## 7. Security and compliance

<!-- Guidance: State the security strategy for cloud and the obligations that constrain design. Questions: which laws, standards and contracts apply? What changes in the shared responsibility model? Pitfall: copying on-premises perimeter controls into cloud instead of identity-centric controls. -->

### 7.1 Security strategy

Summarise the security approach in a few statements: identity as the
primary control plane, least privilege, encryption by default, central
logging, continuous posture management and incident response that covers
cloud control-plane events. Link to the Security architecture
(`security/security-architecture`) for the detailed design.

### 7.2 Shared responsibility

| Layer | Provider responsibility | Our responsibility | Notes |
|---|---|---|---|
| Physical facilities and hardware | Full | None | Provider attestations reviewed annually |
| Virtualisation and managed service runtime | Full for managed services | Configuration | Varies by service model |
| Operating systems on virtual machines | None | Full | Patch baseline applies |
| Identity, access and data | None | Full | Always ours |
| [Layer] | [Provider] | [Ours] | [Notes] |

### 7.3 Compliance obligations

| ID | Obligation | Source | Impact on design | Owner |
|---|---|---|---|---|
| CMP-001 *(Example)* | Personal data of EU residents stays in approved regions | Data protection law and contracts | Region policy POL-001 | @dpo |
| CMP-002 *(Example)* | Payment card data isolated from other workloads | Card industry standard | Dedicated hierarchy branch | @ciso |
| [CMP-NNN] | [Obligation] | [Law, standard or contract] | [Design impact] | [@owner] |

## 8. Skills and organisation

<!-- Guidance: Plan the people side with the same care as the technology. Questions: which roles change, which new roles are needed, how will people be trained and supported? Pitfall: relying on a partner for the first year and never building internal capability. -->

### 8.1 Role changes

| Current role | Future role | People affected | Change approach |
|---|---|---|---|
| Server administrator *(Example)* | Platform engineer or site reliability engineer | 14 | Training path, pairing in waves 1 to 3 |
| Network engineer *(Example)* | Cloud network engineer | 6 | Certification, landing zone build |
| Database administrator *(Example)* | Data platform engineer | 5 | Managed database operations training |
| [Role] | [Future role] | [Number] | [Approach] |

### 8.2 Learning plan

| Audience | Learning objective | Format | Target date | Measure |
|---|---|---|---|---|
| All engineers *(Example)* | Cloud fundamentals and landing zone usage | Online course and internal workshop | YYYY-MM-DD | 90 % completion |
| Platform team *(Example)* | Advanced networking, IaC and policy as code | Instructor-led and hands-on labs | YYYY-MM-DD | Professional certification |
| Leaders and finance *(Example)* | Cloud economics and FinOps | Briefing series | YYYY-MM-DD | Attendance, showback in use |
| [Audience] | [Objective] | [Format] | YYYY-MM-DD | [Measure] |

### 8.3 Change management

Describe how the programme communicates with staff, how concerns are
raised and answered, and how early successes are recognised. Name the
change lead and the channels used.

## 9. Financial model and FinOps

<!-- Guidance: Explain how cloud will be funded, charged and optimised. Questions: capital or operating budget? Who pays for the platform? How are commitments bought? Pitfall: no cost allocation until the first large invoice arrives. -->

### 9.1 Business case summary

Summarise the multi-year cost comparison and link to the full TCO
analysis (`architecture/tco-analysis`). Include dual-running costs
during migration, exit costs and the cost of training and partners.

| Cost element | Year 1 | Year 2 | Year 3 | Notes |
|---|---|---|---|---|
| Cloud consumption *(Example)* | [Value] | [Value] | [Value] | Grows with waves |
| Dual running on premises *(Example)* | [Value] | [Value] | [Value] | Falls after site exit |
| Migration services and tools *(Example)* | [Value] | [Value] | [Value] | Partner and discovery tooling |
| Training and change *(Example)* | [Value] | [Value] | [Value] | Section 8 |
| Avoided cost *(Example)* | [Value] | [Value] | [Value] | Hardware refresh and lease |

### 9.2 Funding and allocation

| Item | Approach |
|---|---|
| Platform costs | *Example:* Funded centrally for two years, then allocated by consumption share |
| Workload costs | *Example:* Shown back to business units monthly, charged back from year 2 |
| Commitments and discounts | *Example:* Bought centrally after three months of stable usage, reviewed quarterly |
| Budget alerts | *Example:* Alert at 80 % and 100 % of monthly budget per environment |

### 9.3 FinOps practice

Adopt the FinOps Framework phases (Inform, Optimize, Operate) from the
FinOps Foundation. Name the FinOps lead, the review cadence and the
reports each audience receives. Run recurring reviews with the FinOps
cost review template (`ops/finops-cost-review`).

## 10. Roadmap

<!-- Guidance: Sequence the programme in phases with exit criteria. Questions: what must exist before the first production migration? Which dates are fixed by business events? Pitfall: a roadmap with dates but no criteria for moving between phases. -->

```mermaid
gantt
  title Cloud adoption roadmap (Example)
  dateFormat YYYY-MM-DD
  section Foundation
  Strategy and business case      :done,    s1, 2026-01-05, 60d
  Landing zone build              :active,  s2, 2026-03-02, 90d
  section Migration
  Pilot wave                      :         m1, 2026-06-01, 45d
  Waves 1 to 3                    :         m2, after m1, 120d
  Waves 4 to 6 and site A exit    :         m3, after m2, 150d
  section Optimise and modernise
  Commitments and rightsizing     :         o1, after m1, 300d
  Product refactoring             :         o2, after m2, 240d
```

| Phase | Scope | Exit criteria | Target date |
|---|---|---|---|
| PH-1 Foundation *(Example)* | Strategy approved, landing zone live, first platform services | Security baseline verified, vending in production | YYYY-MM-DD |
| PH-2 Pilot *(Example)* | Three low-risk applications | Runbooks proven, rollback tested | YYYY-MM-DD |
| PH-3 Scale migration *(Example)* | Waves 1 to 6 | Site A empty, contracts closed | YYYY-MM-DD |
| PH-4 Optimise *(Example)* | Rightsizing, commitments, modernisation | Outcome targets OUT-001 to OUT-003 met | YYYY-MM-DD |
| [PH-N] | [Scope] | [Criteria] | YYYY-MM-DD |

## 11. Risks and assumptions

<!-- Guidance: Record programme-level risks with owners and responses; keep project risks in the RAID log. Pitfall: risks without a trigger or an owner. -->

| ID | Risk | Likelihood | Impact | Response | Owner |
|---|---|---|---|---|---|
| RSK-001 *(Example)* | Data centre exit date slips because discovery is incomplete | Medium | High | Funded discovery sprint, weekly dependency review | @migration-lead |
| RSK-002 *(Example)* | Skills gap slows landing zone delivery | High | Medium | Partner pairing with knowledge transfer milestones | @platform-lead |
| RSK-003 *(Example)* | Cloud costs exceed forecast during dual running | Medium | High | Budgets, alerts, monthly FinOps review | @finops-lead |
| RSK-004 *(Example)* | Licence terms prevent moving key databases | Medium | High | Licence review before wave planning | @procurement |
| [RSK-NNN] | [Risk] | [L / M / H] | [L / M / H] | [Response] | [@owner] |

| ID | Assumption | Validated by | Date |
|---|---|---|---|
| ASM-001 *(Example)* | Network bandwidth to cloud is sufficient for replication of 40 TB per week | Network test | YYYY-MM-DD |
| [ASM-NNN] | [Assumption] | [Method] | YYYY-MM-DD |

Track project-level risks, issues and dependencies in the RAID log
(`project/raid-log`).

## 12. Decisions and traceability

<!-- Guidance: Show that every outcome is served by decisions and actions, and that every action traces to a gap or an outcome. -->

| Outcome | Motivation | Decisions | Actions | Roadmap phase | Measure reported in |
|---|---|---|---|---|---|
| OUT-001 *(Example)* | MOT-001 | DEC-002, DEC-006 | ACT-002, ACT-006 | PH-3, PH-4 | Monthly FinOps report |
| OUT-002 *(Example)* | MOT-002 | DEC-006 | ACT-004 | PH-2, PH-4 | Engineering metrics dashboard |
| OUT-003 *(Example)* | MOT-003 | DEC-004 | ACT-003 | PH-3 | DR test reports |
| [OUT-NNN] | [MOT-NNN] | [DEC-NNN] | [ACT-NNN] | [PH-N] | [Report] |

Record significant decisions as architecture decision records using the
ADR template (`architecture/adr-full`).

## 13. Framework mappings

<!-- Guidance: Use these tables to find the provider guidance that supports each section. The framework names are those published by each provider; check the current version before relying on a mapping. -->

### 13.1 Microsoft Cloud Adoption Framework for Azure

As published on Microsoft Learn (overview updated August 2026), Azure
adoption is organised in seven phases. Migrating, modernising and
building cloud-native workloads are all covered under Adopt; older
material may still show them as separate methodologies. Microsoft also
publishes scenarios that build on this foundation, such as AI adoption,
AI agents, data platform and sovereignty.

| CAF phase | Key question in CAF | Sections of this document |
|---|---|---|
| Strategy | What should adoption look like? | 1, 9.1 |
| Plan | How will we prepare for adoption? | 2, 5, 8, 10 |
| Ready | How will we build the landing zone? | 4 |
| Adopt | How will we migrate, modernise and build workloads? | 5, 10 |
| Govern | How will we control the environment? | 6, 9.2 |
| Secure | How will we protect the environment? | 7 |
| Manage | How will we operate and optimise over time? | 3, 9.3 |

### 13.2 AWS Cloud Adoption Framework

The AWS CAF groups foundational capabilities into six perspectives.

| AWS CAF perspective | Focus | Sections of this document |
|---|---|---|
| Business | Cloud investment linked to business outcomes | 1, 9.1 |
| People | Culture, organisation structure, leadership and workforce | 3, 8 |
| Governance | Orchestrating initiatives, maximising benefit, limiting risk | 6, 9.2, 11 |
| Platform | Scalable hybrid platform, modernising workloads, cloud-native builds | 4, 5 |
| Security | Confidentiality, integrity and availability of data and workloads | 7 |
| Operations | Delivering cloud services at the level the business needs | 3, 9.3 |

### 13.3 Google Cloud Adoption Framework

The Google Cloud Adoption Framework whitepaper assesses maturity across
four themes (Learn, Lead, Scale, Secure) and three phases (Tactical,
Strategic, Transformational), which together form its Cloud Maturity
Scale; workstreams are called epics.

| Theme | Focus | Sections of this document |
|---|---|---|
| Learn | Upskilling staff and using external expertise | 8 |
| Lead | Executive mandate and cross-functional teams | 1, 3, 6 |
| Scale | Managed services and automation that cut manual effort | 4, 5, 9.3 |
| Secure | Protection through identity-centric, layered security | 7 |

Use the three phases as the rating scale in section 2.2 if the
organisation prefers the Google maturity language: Tactical (ratings 1
and 2), Strategic (rating 3), Transformational (ratings 4 and 5).

## 14. Glossary and references

<!-- Guidance: Define terms that readers outside the platform team will meet in this document. -->

### 14.1 Glossary

| Term | Meaning |
|---|---|
| Landing zone | Governed, pre-configured cloud foundation into which workloads are deployed |
| Cloud centre of excellence | Cross-functional team that sets cloud standards and enables adoption |
| Paved road | Supported, pre-approved way of building and running a common type of workload |
| Vending | Automated provisioning of a governed account, subscription or project on request |
| Showback / chargeback | Reporting costs to consumers / billing them to consumers |
| 7 Rs | Seven migration strategies: retire, retain, rehost, relocate, repurchase, replatform, refactor |
| Dual running | Period when both source and cloud environments are paid for |

### 14.2 References

| Reference | Version or date | Use |
|---|---|---|
| Microsoft Cloud Adoption Framework for Azure, learn.microsoft.com/azure/cloud-adoption-framework | Overview updated August 2026 | Phase mapping, section 13.1 |
| An Overview of the AWS Cloud Adoption Framework, AWS whitepaper | 22 November 2021 | Perspective mapping, section 13.2 |
| The Google Cloud Adoption Framework, Google Cloud whitepaper | As published by Google Cloud | Theme mapping, section 13.3 |
| AWS Prescriptive Guidance, Guide for AWS large migrations: About the migration strategies | Current web edition | 7 Rs vocabulary, section 5.1 |
| FinOps Framework, FinOps Foundation | Current web edition | Phases, section 9.3 |
| [Internal policy or standard] | [Version] | [Use] |

## Standard and licence note

Structure aligned with the publicly documented phases of the Microsoft
Cloud Adoption Framework for Azure, the six perspectives of the AWS
Cloud Adoption Framework, the themes and maturity phases of the Google
Cloud Adoption Framework, the seven migration strategies described in
AWS Prescriptive Guidance and the phases of the FinOps Framework. The
framework, phase, perspective and theme names belong to their
publishers and are used for mapping only. This template is original text
written for this collection and reproduces no text from these sources.
Check the current official version of each framework before use; the
provider pages are updated frequently. Template licence: MIT.