AWS Cloud Adoption Framework: Overview & Transformation Phases — Purpose, the Four Transformation Domains, Envision–Align–Launch–Scale, and the Six Perspectives

Where this fits

The AWS Cloud Adoption Framework (AWS CAF) is Amazon’s prescriptive guidance for digitally transforming an organization through the cloud, and this article is part 1 of the series — the overview that establishes the mental model everything else hangs from. Before you ever open a single perspective and start closing capability gaps (the subject of later parts), you need to understand four things that the rest of the framework assumes you already grasp: why AWS CAF exists and what it is for, the four transformation domains that describe what is actually changing in your business, the four iterative phases — Envision, Align, Launch, Scale — that give your program a rhythm, and how the framework’s 47 capabilities map across the six perspectives. Get this overview right and the perspective-by-perspective work later has a frame to live in; skip it and you will treat AWS CAF as a checklist of 47 unrelated tasks instead of a connected transformation engine.

The purpose of the AWS CAF

What it is. The AWS Cloud Adoption Framework is a body of guidance, built from AWS’s own experience helping thousands of customers migrate and modernize, that helps you identify and prioritize transformation opportunities, evaluate and improve your cloud readiness, and iteratively evolve your transformation roadmap. It is not an architecture framework (that is the AWS Well-Architected Framework) and it is not a migration runbook (that is the Migration Acceleration Program and the 7 Rs). AWS CAF operates one level up: it is the organizational operating-model framework that answers “is the whole enterprise — its people, governance, finances, and security posture, not just its servers — ready to adopt cloud at scale, and what do we do about the gaps?”

Why it matters. The single most common cause of stalled cloud programs is not technical; it is the assumption that cloud adoption is an IT project. It is not. A migration that lifts 900 VMs into AWS but leaves the finance team unable to read a chargeback, the security team unable to evidence a control to an auditor, and the platform team hand-building accounts in the console has not transformed anything — it has simply relocated the problem and added a cloud bill. AWS CAF exists to make the non-technical readiness gaps visible and ownable so they get worked in parallel with the technical migration, not discovered six months in when the auditor asks who approved the public S3 bucket. The framework’s promise is business-outcome acceleration: lower costs, reduced business risk, improved operational efficiency, greater agility, faster innovation, new revenue streams, and reinvented customer and employee experience.

How to do it well. Treat AWS CAF as a diagnostic-and-planning instrument, not a maturity-model vanity exercise. The intended loop is: assess your current state across the six perspectives, identify the capabilities that are gating your strategic objectives, prioritize a small number of them, close those gaps, and re-assess. The framework is explicitly iterative and incremental — AWS tells you not to tackle all foundational capabilities at once but to evolve them as you progress through the journey. The most consequential decision is scoping: you anchor every CAF activity to a specific business outcome and a specific senior stakeholder, so that capability work is never abstract self-improvement but always traceable to “this unblocks that outcome that this executive owns.”

Artifacts, decisions, and AWS tooling.

The AWS tools that operationalize the purpose are the AWS Cloud Adoption Readiness Tool (CART) and AWS-facilitated CAF workshops for the assessment; AWS Migration Evaluator and AWS Application Discovery Service to put evidence under the migration business case; and the AWS Well-Architected Tool to assess individual workloads once they exist. CART produces the readiness baseline; Migration Evaluator turns “we think we have ~900 VMs” into a data-driven TCO and right-sizing report that confirms or kills the case before money is committed.

The four transformation domains (technology, process, organization, product)

What it is. The four transformation domains describe what changes during a cloud transformation, and — critically — AWS arranges them as a value chain, where each domain enables the next:

• Technology — Migrate and modernize legacy infrastructure, applications, and data and analytics platforms. This is the foundational layer: moving and re-platforming workloads, modernizing databases, and standing up the data and analytics platform.
• Process — Digitize, automate, and optimize your business operations by leveraging new data and analytics platforms and applying machine learning to your business processes. Process change is enabled by the technology change beneath it — you cannot automate a process onto a platform that does not yet exist.
• Organization — Reimagine your operating model by organizing your business and technology teams around products and value streams and adopting agile ways of working. Organizational change is enabled by the process change — once operations are digitized, the org can be restructured around the products that run them.
• Product — Reimagine your business model by creating new value propositions (products and services) and revenue models. Product change is the apex of the chain — enabled by the new technology, the optimized processes, and the product-aligned organization beneath it.

Why it matters. The domains stop executives from confusing “we moved to the cloud” (Technology only) with “we transformed” (all four). Most failed transformations are Technology-only efforts that never climb the value chain: the infrastructure moved, but the operating model, the processes, and the business model are exactly as they were, so the promised agility and new revenue never materialize. The value-chain framing also imposes sequencing discipline. You cannot credibly reimagine your business model (Product) on top of hand-cranked, undigitized operations (no Process change) running on lifted-and-shifted monoliths (shallow Technology change). The chain tells you that ambition in the upper domains is gated by foundations in the lower ones, which is exactly the conversation an over-eager “let’s build an AI product” board needs to have.

How to do it well. Map every transformation initiative to a domain and read the shape of your portfolio. A portfolio that is 100% Technology initiatives is a relocation, not a transformation — flag it. A portfolio with Product ambitions but no Process or Organization initiatives is building a penthouse with no floors below it. The healthiest early-stage portfolio is weighted toward Technology and Process with a few targeted Organization and Product bets that prove the chain works end to end.

Artifacts, decisions, and tooling. The artifact is a domain-tagged initiative portfolio — every initiative carries a domain label, a sponsoring stakeholder, and a target outcome. The key decision is how far up the chain this transformation intends to go, which sets the funding envelope and the success metrics: a Technology-and-Process program is measured on run-rate reduction and cycle-time improvement; a program that reaches Product is measured on new-revenue and time-to-market.

The transformation phases (Envision, Align, Launch, Scale)

What it is. AWS CAF recommends four iterative and incremental cloud transformation phases that give the whole program a cadence. They are not a one-time waterfall; you loop through them as the roadmap evolves.

• Envision — Demonstrate how cloud will accelerate business outcomes by identifying and prioritizing transformation opportunities across the four transformation domains in line with your strategic objectives. Each opportunity is associated with a senior stakeholder capable of driving change and with a measurable business outcome. Output: a prioritized set of transformation opportunities tied to owners and outcomes.
• Align — Identify capability gaps across the six AWS CAF perspectives, surface cross-organizational dependencies, and bring stakeholder concerns and challenges into the open. This is where the perspectives do their work: you assess current-vs-desired capability and build strategies to improve cloud readiness, secure stakeholder alignment, and drive organizational change management. Output: a readiness assessment, a gap-closure strategy, and a stakeholder-alignment / change plan.
• Launch — Deliver pilot initiatives in production and demonstrate incremental business value. Pilots are deliberately high-impact so that, when they succeed, they influence future direction; learning from them lets you adjust your approach before committing to full production scale. Output: production pilots, measured value, and refined operating practices. The emphasis word is production — a pilot that never serves real traffic teaches you nothing about your real readiness.
• Scale — Expand production pilots and business value to the desired scale, and ensure the business benefits associated with your cloud investments are realized and sustained. Output: scaled workloads, a steady-state operating model, and a benefits-realization track that proves the value persisted.

Why it matters. The phases force incrementalism, which is the antidote to the two failure modes of big transformations: analysis paralysis (endless planning, no production system) and the big-bang gamble (everything migrated at once, no learning loop, catastrophic blast radius if the operating model is wrong). By insisting that value is demonstrated early (Envision ties to outcomes, Launch ships to production) and that readiness gaps are surfaced before scale (Align), the phases keep the program honest and fundable. They also give the program a language for status — “we have three opportunities in Launch and the data-platform pilot is ready to enter Scale” is a far more useful executive update than a percentage-complete bar.

How to do it well. Run the phases as overlapping waves, not a single pass: while your first pilot is in Launch, your next set of opportunities should be in Envision and Align. Make the Envision→Align hand-off explicit — an opportunity is not allowed into Launch until its gating capability gaps (from Align) have an owner and a plan. Protect the Launch phase’s “highly impactful” rule: pick pilots that, if they succeed, change minds and unlock budget, and that, if they fail, fail cheaply and teach you something. And treat Scale as the phase where benefits-realization is measured, not assumed — the Governance perspective’s benefits-management capability lives here.

Artifacts, decisions, and tooling. The cross-phase artifact is the transformation roadmap, re-baselined each iteration. The defining decision in each phase: in Envision, which opportunities make the cut and who sponsors them; in Align, which capability gaps are gating and therefore funded now; in Launch, which pilot is impactful enough to be worth production risk; in Scale, whether the benefits actually realized and whether to expand, hold, or pivot.

How capabilities map to the six perspectives

What it is. A capability is an organizational ability to use people, processes, and technology to produce a business outcome — and AWS CAF organizes its capabilities into six perspectives, each owned by a recognizable set of stakeholders. AWS CAF v3 defines 47 capabilities across the six perspectives. The first three perspectives are business-focused (Business, People, Governance) and the last three are technology-focused (Platform, Security, Operations). When you do the Align phase, you are walking these capabilities one by one and rating them.

The six perspectives, their owners, and their capabilities:

The 47 capabilities, by perspective:

Why it matters. The perspective model is what makes cloud adoption an enterprise program rather than an IT one. By naming a Business perspective owned by the CFO and a Security perspective owned by the CISO, AWS CAF forces accountability onto the people who actually own those readiness gaps. It also prevents the classic blind spot: a brilliant Platform team can stand up a flawless landing zone, but if Governance’s cloud financial management capability is immature, the company still cannot allocate, forecast, or chargeback its spend, and the CFO will lose confidence in the whole program. The perspectives guarantee that you assess all the muscles a cloud organization needs, not just the technical ones, and that each muscle has a named owner.

How to do it well. Use the perspectives as an assessment grid, not a reorg chart — you are rating capabilities, not creating six new departments. Rate each relevant capability on a simple current-vs-desired scale, then filter ruthlessly to the few that gate this iteration’s outcomes. Notice the deliberate design: several capabilities recur as data threads across perspectives (data science and data monetization in Business; data governance and data curation in Governance; data architecture and data engineering in Platform; data protection in Security) — AWS is signalling that a data-and-AI transformation cuts across owners and must be coordinated, not owned by one team. Equally, identity and access management sits in Security but is consumed by Platform’s platform engineering (which federates the IdP) and by everyone who provisions — capabilities are interdependent, which is exactly why the Align phase also hunts for cross-organizational dependencies.

Artifacts, decisions, and tooling. The artifact is the capability assessment — a rated grid of (up to) 47 capabilities with owners and gap notes — feeding the prioritized backlog. The decisions are which capabilities are foundational for us now and who owns each gap. The tooling: CART and AWS-facilitated CAF workshops generate the assessment; specific capabilities then map to specific AWS services in later phases (for example, cloud financial management → Cost Explorer, Budgets, Cost Categories, and consolidated billing; identity and access management → IAM Identity Center; threat detection → GuardDuty; observability → CloudWatch and X-Ray; provisioning and orchestration → Service Catalog; platform engineering → Control Tower and Organizations).

Real-world enterprise scenario

Company. Meridian Freight Group — a fictional €4.1B European logistics and supply-chain operator: 11,000 employees, ~70 depots, a 2,400-server on-premises estate across two aging datacenters, and a 30-year-old monolithic transport-management system (TMS) written in Java EE. Their colocation lease on the primary datacenter expires in 22 months, and the board has separately demanded a “real-time shipment-visibility product” to defend three large retail accounts that a cloud-native competitor is courting.

The mandate. The CIO, Anja Roest (acting as Chief Transformation Officer), is told to deliver both the datacenter exit and the new product. She convenes a two-week AWS-facilitated CAF engagement and runs the four phases as overlapping waves.

Envision (the four domains). The team lists opportunities and tags each to a transformation domain:

• Technology — exit DC-1, migrate 2,400 servers, modernize the TMS database from on-prem Oracle to Amazon Aurora PostgreSQL via DMS.
• Process — digitize manual depot-handover paperwork and apply ML-based ETA prediction.
• Organization — restructure the 140-person IT department from project teams into nine product-aligned squads.
• Product — launch “Meridian Live,” a real-time shipment-visibility portal as a new paid tier.

Reading the portfolio shape, Anja sees it is Technology-and-Process-heavy with two upper-chain bets — a healthy shape. Each opportunity is bound to a sponsor (the DC exit to the COO on a hard lease date; Meridian Live to the Chief Product Officer) and a measurable outcome (€6.2M/yr run-rate reduction; €9M defended retail revenue).

Align (six perspectives, 47 capabilities). Using CART, Meridian rates its capabilities and finds the gating gaps are not mostly technical:

The Align output is a gap-closure strategy: stand up an AWS Control Tower landing zone with AWS Organizations and IAM Identity Center federation to the existing IdP; define a mandatory tag policy and Cost Categories so the CFO gets chargeback; run an AWS Skills Guild plus a ramp-up plan to get 60 engineers certified in two quarters; and adopt AWS Audit Manager so the CISO can evidence controls. A cross-org dependency surfaces immediately — the IdP federation (Platform) blocks the certification labs (People) and the auditable access model (Security) — so it is sequenced first.

Launch (production pilots). Two deliberately high-impact pilots go to production, not a sandbox:

1. The Meridian Live MVP — an event-driven stack (API Gateway + Lambda + DynamoDB + EventBridge, telemetry ingested via IoT Core from depot scanners) serving two friendly retail customers’ live shipments.
2. A single bounded context of the TMS — the “rating engine” — replatformed to Amazon EKS with a blue/green deploy via CodePipeline.

The Meridian Live pilot proves the operating model end to end (the new product squad, the landing zone account vending, the chargeback tags, the CloudWatch/X-Ray observability) and books its first measured outcome: ETA accuracy up from 71% to 94%. The rating-engine pilot exposes a real readiness gap — the on-call rota and runbooks were immature — which is fixed before scaling, exactly as the phase intends.

Scale (expand and sustain). With the model proven, Meridian uses Application Migration Service (MGN) to migrate the remaining DC-1 servers in waves ahead of the lease date, expands Meridian Live to all 11,000-employee customer base and 14 paying retail accounts, and stands up the benefits-realization track in Governance: Cost Explorer and Budgets confirm the €6.2M run-rate reduction is real (actual: €5.8M, 94% of target), and the CPO’s revenue dashboard shows €9M of retail revenue defended plus €2.3M new from the paid Live tier.

Measurable outcome (18 months in). DC-1 fully vacated 4 months before lease expiry; 2,260 of 2,400 servers migrated or retired (140 deliberately retained on-prem for data-residency); 64 engineers AWS-certified; first clean SOC 2 evidence pack produced from Audit Manager; €5.8M/yr saved and €11.3M of revenue defended or created. The transformation climbed all four domains — and the board can see it did, because every euro traces back to an Envision opportunity, a named sponsor, and a closed capability gap.

Deliverables & checklist

By the end of the Overview & Transformation Phases work you should have produced:

• A statement of purpose for the program — the business outcomes (cost, risk, agility, innovation, revenue, experience) AWS CAF is being used to accelerate, in writing.
• A cloud readiness assessment (via CART and/or an AWS-facilitated CAF workshop) rating the relevant capabilities across all six perspectives.
• A domain-tagged initiative portfolio — every opportunity labelled Technology / Process / Organization / Product, with the portfolio shape reviewed against the value chain.
• A stakeholder + outcome map binding each opportunity to a senior sponsor and a measurable business outcome.
• A prioritized capability backlog — the small set of gating capabilities to advance this iteration, each with a named owner.
• A cross-organizational dependency list surfaced during Align (e.g. IdP federation gating both certification and audit).
• A phased transformation roadmap expressing initiatives as Envision → Align → Launch → Scale waves, designed to overlap.
• Launch pilot definitions — high-impact, production-bound pilots with success criteria and a “fail cheaply” boundary.
• A benefits-realization plan for Scale, with the metrics (run-rate, time-to-market, adoption) and the AWS tools (Cost Explorer, Budgets) that will measure them.

Common pitfalls

1. Treating AWS CAF as an IT-only exercise. If only the Platform and Operations perspectives have owners and the Business, People, and Governance perspectives are unstaffed, you are running a migration, not a transformation. Avoid it by assigning each perspective to its named executive (Business→CFO/COO, People→CIO, Governance→CTO/CFO/CDO) before the Align phase starts.
2. Stopping at the Technology domain. Lifting and shifting and declaring victory leaves the operating model, processes, and business model untouched, so the promised agility and revenue never arrive. Avoid it by reading your portfolio’s domain shape and insisting on at least a few Process and Organization initiatives that prove the value chain climbs.
3. Boiling the ocean on capabilities. Trying to mature all 47 capabilities at once stalls the program in assessment. AWS explicitly says to evolve foundational capabilities incrementally. Avoid it by ruthlessly filtering to the handful of capabilities that gate this iteration’s outcomes and deferring the rest.
4. Pilots that never reach production. A “pilot” that runs only in a sandbox tells you nothing about your real readiness — your runbooks, on-call, chargeback, and audit evidence are all untested. Avoid it by honouring the Launch phase’s rule that pilots are delivered in production and are highly impactful.
5. Skipping the cross-organizational dependency hunt in Align. Capabilities are interdependent (IAM gates platform engineering gates certification labs); discovering this during Scale is expensive. Avoid it by explicitly mapping dependencies in Align and sequencing the blocking capability first.
6. Declaring success without benefits realization. Assuming the savings and revenue materialized, rather than measuring them in Scale, is how programs lose executive trust. Avoid it by standing up the Governance benefits-management capability with Cost Explorer/Budgets dashboards that prove the outcome against the Envision targets.

What’s next

Part 2 of the AWS Cloud Adoption Framework series goes deep on the first business-focused lens — the Business perspective — and its eight capabilities, from strategy and portfolio management through data monetization and data science.