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

In a nutshell

Imagine your company is relocating its entire headquarters to a new city. The easy part is loading the furniture onto trucks and setting it down in the new building — that is the equivalent of “migrating the servers.” But if that is all you do, the first Monday is chaos: payroll does not know the new cost centres, the security desk has no badge system, the org chart still assumes the old floor plan, and nobody has thought about the new products the bigger space was supposed to make possible. A successful relocation moves the furniture and re-wires the finances, the security, the people, and the ambitions.

The AWS Cloud Adoption Framework (AWS CAF) is the checklist and playbook for that whole-company move to the cloud. It is not a tool you install and it is not an architecture diagram — it is a way of organising the conversation so that every part of the business that has to change actually gets an owner and a plan. CAF slices the readiness question into six perspectives (Business, People, Governance, Platform, Security, Operations), lists 47 capabilities an enterprise needs to run well in the cloud, describes four things that change (Technology, Process, Organization, Product), and gives the program a four-phase rhythm (Envision → Align → Launch → Scale).

If you remember one sentence: CAF makes the non-technical readiness gaps visible and ownable so they get fixed in parallel with the migration, instead of being discovered six months in when the auditor asks who approved the public S3 bucket. It works at the level of the whole organisation; its sibling, the Well-Architected Framework, works at the level of a single workload — and, confusingly, “AWS WAF” is also the name of an unrelated firewall product, a collision we untangle later.

Level: Beginner → Intermediate (strategy, no console required) · Time: ~55 min

Prerequisites. No hands-on AWS is needed — this is a strategy lesson you could read before you have ever opened the console. It helps to know, at a high level, what “migrating to the cloud” means, and to have met the idea that AWS has both a Cloud Adoption Framework (org-wide) and a Well-Architected Framework (per-workload). If you have read the cloud-fundamentals lesson you are more than ready.

After this lesson you will be able to:

• Explain, in plain language, what AWS CAF is for and how it differs from the Well-Architected Framework and from a migration runbook (MAP).
• Name the six perspectives, say which three are business-focused and which three are technical, and describe roughly how the 47 capabilities distribute across them.
• Describe the four transformation domains as a value chain and read the “shape” of a transformation portfolio at a glance.
• Walk a program through the Envision → Align → Launch → Scale phases and explain why they are iterative waves, not a one-time waterfall.
• Run a lightweight CAF assessment, turn it into a prioritized action plan, and tie every item to a business outcome and a named sponsor.
• Place any claimed benefit into the Cloud Value Framework so it becomes a fundable, measurable number.

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 cloud value framework — measuring what CAF accelerates

The purpose section above lists the outcomes CAF chases — lower cost, less risk, more agility, faster innovation, new revenue, better experience. But “we became more agile” is not a number a CFO will fund against or hold you to. AWS pairs CAF with the Cloud Value Framework (CVF), which sorts every claimed benefit into four measurable value dimensions so that the initial business case and the later benefits-realization track speak the same language.

Why two frameworks, not one. CAF tells you what to change and in what order; CVF tells you how to prove the change paid off. The two lock together at the seams: an Envision opportunity is written as a value hypothesis in one of these four dimensions (“exit DC-1 → cost savings of €6.2M/yr”), and the Scale phase’s benefits-realization work measures the actual number against that hypothesis. If you cannot place a proposed initiative into one of the four dimensions with a metric attached, that is a signal the opportunity is not yet real enough to fund.

Worked example — turning a vague benefit into a CVF line. A stakeholder says “the cloud will make us more innovative.” That sentence is unfundable and unmeasurable. Push it through CVF, one question at a time:

1. Which dimension? Business agility.
2. Which metric? Time-to-market for a new customer-facing feature.
3. What is the baseline today? 14 weeks — procure hardware, ticket-driven provisioning, a quarterly release train.
4. What is the target? Under 2 weeks — self-service account vending plus CI/CD.

Now “be more innovative” has become a fundable, testable objective. And the act of writing the target exposes the capability gaps that must close for the number to move — Platform’s provisioning and orchestration and Platform’s CI/CD — which is exactly the hand-off into the Align phase. This is the everyday mechanics of CAF: a fuzzy ambition becomes a measured value hypothesis, and the hypothesis points straight at the capabilities you must mature to make it true.

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.

Worked example — reading a portfolio’s domain shape

Tagging each initiative with a domain is only useful if you then read the shape of the whole portfolio. Here are three portfolios that landed on a CTO’s desk, each carrying the same headline, “cloud transformation”:

The value-chain rule reads left to right: each domain is enabled by the ones to its left. So Portfolio B is not “ambitious,” it is ungrounded — you cannot reimagine the business model (Product) on top of undigitized operations (no Process) running on a single lifted monolith (thin Technology). The fix is not to cancel the Product bets but to insert the missing Process and Organization initiatives beneath them, so the ambition has floors to stand on.

Portfolio A is the opposite failure: entirely legitimate as an engineering effort, but mislabelled. The remedy is honest naming — call it a migration, measure it on run-rate and cycle-time, and stop promising the board the agility and new revenue that only the upper domains deliver. Reading portfolio shape this way turns a pile of unrelated projects into a fundable, sequenced story, and it is a thirty-second sanity check you can run on any transformation plan you are handed.

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.

Worked example — the Envision→Align hand-off as a gate

The phases are only iterative if the hand-offs between them are gates, not rubber stamps. The most abused hand-off is Envision → Align: an executive falls in love with an opportunity in Envision and wants it in Launch by Friday, skipping the unglamorous readiness work in Align. Make the gate explicit and it protects itself.

Gate rule: an Envision opportunity may not enter Launch until every capability gap that Align flagged as “gating” has a named owner and a dated plan (or an explicit, signed-off waiver).

Trace one opportunity through it:

1. Envision produces the opportunity: “Launch Meridian Live (Product domain), sponsored by the CPO, worth €9M of defended retail revenue.”
2. Align assesses the six perspectives against that specific opportunity and finds three gating gaps: there is no landing-zone account to host it (Platform → platform engineering), no way to charge the new revenue back to a cost centre (Governance → cloud financial management), and no federated identity for the new product squad (Security → identity and access management).
3. The gate: those three gaps get owners (Head of Architecture, CFO, CISO) and dates before the pilot is allowed to start. The identity-federation gap turns out to block the other two — you cannot vend an account or produce audit evidence without it — so it is sequenced first. That is a cross-organizational dependency surfaced exactly where the framework intends it to be.
4. Launch then delivers the pilot in production on top of closed (or explicitly waived) gaps, so the pilot tests the product idea, not the missing plumbing.

Skip the gate and the pilot fails for reasons that have nothing to do with the product — no account to deploy into, no chargeback, no logins — and the organisation draws exactly the wrong conclusion: “the cloud does not work for us.” The gate is cheap; the false conclusion is expensive, because it discredits the whole program.

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).

The CAF assessment and the action plan

Everything above becomes real through one repeatable activity: the CAF assessment. This is the engine that turns “we should adopt the cloud” into a prioritized, owned, dated plan — and it is the deliverable AWS Solutions Architects and Professional Services most often run with customers.

What the assessment is. Facilitated as a workshop (or self-served with the AWS Cloud Adoption Readiness Tool, CART), the assessment walks the relevant subset of the 47 capabilities and rates each one on a simple current-state vs. desired-state scale. A common rating scale:

The gap that matters is not “how low is the score” but desired minus current for a capability that gates a strategic outcome. A capability sitting at 2 that nobody needs above 2 is not a gap — leave it alone. A capability at 3 that the new shipment-visibility product needs at 5 is a gap, and a gating one. This distinction is what stops an assessment from becoming a demoralising list of everything you are bad at.

From assessment to action plan. The output is not a maturity report to frame on a wall — it is an action plan, built in six moves:

1. Rate the in-scope capabilities (current vs desired), per perspective.
2. Filter to the capabilities whose gap gates a prioritized Envision outcome. Ruthlessly — most capabilities are deliberately left untouched this iteration.
3. Assign each surviving gap to a named owner (the perspective’s executive), with a target state and a date.
4. Sequence by dependency — a capability that blocks others (identity, landing zone, tagging) goes first.
5. Map each gap to the initiatives and AWS services that close it (for example cloud financial management → Cost Categories + Budgets + Cost Explorer; identity and access management → IAM Identity Center).
6. Re-assess next iteration — the framework is a loop, so last iteration’s “desired” becomes this iteration’s “current,” and the bar moves up.

The discipline lives in the filter step. A team that rates all 47 capabilities and then tries to raise every one to 5 has mistaken the assessment for the goal. The assessment exists to find the handful of gating gaps worth funding now.

Each of the six perspectives gets its own deep-dive lesson later in this series — for example the Business perspective, the People perspective, the Governance perspective, and the Security perspective — where every capability in that perspective is rated in detail.

How AWS CAF relates to Well-Architected and MAP

Newcomers routinely confuse AWS CAF with two neighbours: the Well-Architected Framework and the Migration Acceleration Program (MAP). They operate at different altitudes and are complementary, not competing.

The naming-collision trap you must not fall into. People often say “AWS WAF” as shorthand for the Well-Architected Framework — but AWS WAF is also the name of a completely different product, the AWS Web Application Firewall. They are unrelated: one is a design-review framework, the other is a Layer-7 firewall that inspects and filters HTTP(S) requests to protect web apps. In this course the CAF lessons always mean the framework when they say “Well-Architected,” and when we mean the firewall we write “AWS WAF (Web Application Firewall)” in full. The safest habit is to say “Well-Architected” out loud for the framework and never abbreviate it to “WAF,” which removes the ambiguity entirely.

How the three interlock in practice. CAF’s Align phase says “you have a workload-design capability gap” → you close it by running Well-Architected reviews on your workloads with the Well-Architected Tool. CAF’s Envision/Launch phases say “migrate the estate” → the migration itself is executed as a MAP engagement (Assess → Mobilize → Migrate & Modernize), and MAP’s Assess phase feeds the same TCO evidence (from Migration Evaluator and Application Discovery Service) that CAF’s business case needs. Put simply:

CAF is the strategy and operating-model frame; MAP is the migration execution vehicle that runs inside it; Well-Architected is the quality bar for each individual workload the migration produces.

Get this altitude picture right and a whole class of pointless arguments disappears — you stop asking “should we use CAF or Well-Architected?” (you use both, at different levels) and start asking the real question: “which workloads need a Well-Architected review, and which capability gap in the CAF action plan does that close?”

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.

Going deeper

CAF is a graph, not a checklist. The single most common mistake experienced architects make is to read the 47 capabilities as 47 independent workstreams. They are a dependency graph. Identity and access management (Security) is consumed by platform engineering (Platform, which federates the IdP), by provisioning and orchestration (you cannot vend accounts without identity), and by cloud fluency (People — the certification labs need logins). Cloud financial management (Governance) depends on a tagging standard that platform architecture (Platform) has to design and enforce. When you sequence an action plan, you are effectively topologically sorting this graph: the capability that unblocks the most others goes first. That is why real programs almost always start with identity + landing zone + tagging, whichever outcome is loudest — those three sit upstream of nearly everything else.

Foundational vs. the full 47. AWS deliberately distinguishes a set of foundational capabilities — the ones most organisations need early in the journey — from the full catalogue. The guidance is explicit: do not try to mature all 47 at once. Early iterations concentrate on the foundational subset (identity, security governance, provisioning and orchestration, cloud financial management, observability, incident management, cloud fluency) that make the next set of capabilities possible. The remaining capabilities are more advanced or situational and are grown as the program earns the right to them. Treat “foundational” as “the floor you must stand on to reach the rest,” not “the easy ones.”

The Cloud Center of Excellence (CCoE) and operating-model choice. CAF’s Organization domain and People perspective quietly force one of the highest-leverage decisions in the whole program: what cloud operating model will you run? Three archetypes:

Most CAF engagements converge on the CCoE + guardrails model, which is exactly what a Control Tower landing zone (Organizations, SCPs, Account Factory, IAM Identity Center) implements in technology: paved roads and preventive guardrails that let teams move fast safely. The operating-model choice is a People/Organization decision that the Platform perspective then makes real — a clean example of a business-focused perspective driving a technology-focused one.

Benefits realization is a capability, not an afterthought. Governance’s benefits management capability is what separates a transformation from a hopeful migration. It requires that every Envision opportunity carry a baseline and a target in one of the Cloud Value Framework’s four dimensions, and that the Scale phase measure the actual against the target. In AWS terms this is the FinOps loop — Cost Explorer, Budgets, Cost Categories, the Cost and Usage Report (CUR), and Compute Optimizer for the cost dimension; CloudWatch and SLOs for resilience; deployment-frequency and lead-time metrics for agility. Programs that skip this lose executive trust the moment someone asks “so did we actually save the €6.2M?” and nobody can answer with a number.

Organizational change management (OCM) is the hidden critical path. The People perspective’s change acceleration and culture evolution capabilities are where most transformations actually stall — not on technology. AWS Prescriptive Guidance leans on established OCM methods (stakeholder mapping, a change-impact assessment, a communication plan, a champions network, and adoption metrics) precisely because a perfect landing zone that engineers refuse to use has delivered nothing. When you assess the People perspective, rate resistance honestly: a capability that is technically at 4 but culturally rejected behaves like a 1 in practice.

The data thread is deliberate, not redundant. Notice how “data” capabilities recur across perspectives: data science and data monetization (Business), data governance and data curation (Governance), data architecture and data engineering (Platform), data protection (Security). This is not duplication — AWS is signalling that a data-and-AI transformation cannot be owned by one team. The Business perspective wants to monetize data; Governance must govern it; Platform must engineer the lakehouse (S3 + Lake Formation + Glue + Redshift); Security must protect it. If your assessment rates these data capabilities in isolation, you will miss that they must move together, coordinated across four owners. This cross-perspective threading is the strongest argument for the Align phase’s dependency hunt.

Version note. The current framework is AWS CAF v3, which introduced the four transformation domains and the Envision → Align → Launch → Scale phases and settled the capability catalogue at 47 across the six perspectives. Older material — and some older certification questions — reflect earlier versions that described the six perspectives without the domains/phases layer, or with a different capability count. If you meet a “how many capabilities are there” question, anchor on the current 47 across 6 perspectives, but keep in mind that the framework evolves and the exact count matters far less than the structure: six perspectives, a business-vs-technical split, domains as a value chain, and phases as an iterative loop. Understanding the structure survives every revision; memorising the number does not.

Practice challenges

Work these in order; each solution is tucked inside an expandable block with a one-line why. No AWS account is needed — these are reasoning exercises, which is exactly how CAF is used in real engagements.

1. (Beginner) Sort the six perspectives. List the six AWS CAF perspectives and split them into the three that are business-focused and the three that are technology-focused.

<details> <summary>Show solution</summary>

Business-focused: Business, People, Governance. Technology-focused: Platform, Security, Operations.

Why: the business/technology split is the whole point of CAF — it forces the non-technical readiness (finance, culture, governance) to get owners, not just the servers. </details>

2. (Beginner) Place the capability. Which perspective owns each of these: cloud financial management, threat detection, cloud fluency, observability?

<details> <summary>Show solution</summary>

Cloud financial management → Governance. Threat detection → Security. Cloud fluency → People. Observability → Operations.

Why: naming the owning perspective is the reflex the Align phase needs — every gap must land on a named executive (Governance→CFO, Security→CISO, People→CIO, Operations→ops leaders). </details>

3. (Intermediate) Read the portfolio shape. A program has 8 Technology initiatives, 0 Process, 0 Organization, and 1 Product. Diagnose it in one sentence and prescribe the fix.

<details> <summary>Show solution</summary>

Diagnosis: a relocation with a bolted-on product bet — almost all Technology, no Process or Organization, so the single Product initiative has no value-chain floor beneath it. Fix: either stop calling it a transformation (it is a migration, measured on run-rate and cycle-time), or insert the missing Process and Organization initiatives the Product bet depends on.

Why: the four domains are a value chain — Product is enabled by Organization, enabled by Process, enabled by Technology — so ambition in an upper domain is ungrounded without the lower ones. </details>

4. (Intermediate) Name the phase. For each activity, name the CAF phase: (a) “we ranked 12 opportunities and tied each to a sponsor and an outcome”; (b) “we rated our capabilities and found the gating gaps”; © “the shipment MVP is serving two real customers in production”; (d) “we migrated the remaining 2,000 servers in waves and confirmed the savings.”

<details> <summary>Show solution</summary>

(a) Envision · (b) Align · © Launch · (d) Scale.

Why: the phases are a rhythm — opportunities + outcomes (Envision) → gaps + readiness (Align) → production pilots (Launch) → expand + realize benefits (Scale) — and naming the phase tells you what question the program should be answering right now. </details>

5. (Advanced) Run a mini-assessment. A retailer wants to launch a personalization product in six months. Discovery finds: accounts are hand-built in the console; there is no cost-allocation tagging; identity is a legacy on-prem Active Directory with no federation; and workloads have never had a design review. List the gating capability gaps with their perspective and owner, then say which one you sequence first and why.

<details> <summary>Show solution</summary>

Sequence identity / federation first — it blocks landing-zone account vending (Platform) and the auditable access the product needs (Security), so it is the upstream node in the dependency graph.

Why: an action plan is a topological sort of the capability graph; the capability that unblocks the most others (here, identity) is funded first, regardless of which outcome shouts loudest. </details>

6. (Advanced) Frame it for the board. A director says, “Let’s just run an AWS WAF review on the whole company and call it our cloud strategy.” Untangle the confusion, name the right frameworks, and turn the director’s vague goal “be more innovative” into a fundable objective.

<details> <summary>Show solution</summary>

Two problems. First, “AWS WAF” is ambiguous: it usually abbreviates the Well-Architected Framework (a per-workload design review) but is also the name of the Web Application Firewall product — say “Well-Architected” to be clear. Second, neither is a company-wide cloud strategy: that is the job of AWS CAF (org-wide, six perspectives, four phases). Well-Architected reviews individual workloads; the migration itself runs as a MAP engagement inside the CAF frame.

“Be more innovative” → push it through the Cloud Value Framework: dimension = business agility; metric = time-to-market for a new feature; baseline = 14 weeks; target = under 2 weeks. Now it is fundable, and it exposes the capability gaps (provisioning/orchestration, CI/CD) that Align must close.

Why: CAF (org), Well-Architected (workload), and MAP (migration) sit at different altitudes and interlock; and a benefit is only fundable once it is a measured metric in one of the four value dimensions. </details>

Common beginner mistakes

These are conceptual misunderstandings of the framework itself — distinct from the program-execution pitfalls listed above. Each is a misconception, then the mental model that replaces it.

• “CAF and Well-Architected are the same thing (or CAF is the firewall).” They are not. CAF is an organisation-wide adoption framework (six perspectives, capabilities, phases); Well-Architected is a per-workload design-review framework (six pillars). And “AWS WAF,” which sounds like the Well-Architected abbreviation, is also a separate product — the Web Application Firewall. Right model: CAF = whole company, Well-Architected = one workload, AWS WAF (Web Application Firewall) = a Layer-7 firewall. Three different things that happen to share letters.

• “CAF is a migration tool / a runbook for moving servers.” No — that is MAP and the 7 Rs. Right model: CAF operates above the migration; it asks whether the whole enterprise (finance, people, governance, security) is ready, and the actual server-moving happens as a MAP engagement inside the CAF frame.

• “The six perspectives are six new teams / a reorg.” They are an assessment grid, not an org chart. You rate capabilities against the perspectives; you do not create six new departments. The perspectives assign ownership of readiness gaps to executives who already exist (CFO, CISO, CIO, …).

• “We have to do all 47 capabilities.” The framework explicitly says do not. Right model: assess broadly, then filter ruthlessly to the handful of capabilities whose gap gates this iteration’s outcome, close those, and re-assess. The 47 is a catalogue to shop from, not a to-do list to complete.

• “The four phases are a waterfall — finish Envision, then start Align.” They are iterative, overlapping waves. While pilot #1 is in Launch, the next opportunities are already in Envision and Align. Right model: phases are a cadence you loop through, not stages you complete once and leave behind.

• “Technology domain done = transformation done.” Lifting servers into AWS is the Technology domain only. Right model: transformation is a value chain — Technology enables Process enables Organization enables Product — and stopping at Technology is a relocation, not a transformation.

• “A pilot in a sandbox proves we’re ready.” A pilot that never serves real traffic tests none of the things that actually break — chargeback, on-call, audit evidence, account vending. Right model: the Launch phase requires pilots in production, deliberately high-impact, with a “fail cheaply” boundary.

• “CAF is only for giant enterprises.” The vocabulary is enterprise-flavoured, but the loop — assess, prioritize a few gating gaps, close them, re-assess — scales down cleanly. A 40-person company still needs to know who owns cloud spend, who evidences security, and whether its pilot ran in production. Right model: CAF is a thinking tool first; you use as much of the 47 as your size warrants.

Glossary

• AWS Cloud Adoption Framework (AWS CAF) — AWS’s prescriptive, organisation-wide guidance for digitally transforming a business through the cloud, built from AWS’s experience with thousands of customers. Structured as six perspectives, 47 capabilities, four transformation domains, and four phases.
• Perspective — one of six lenses CAF uses to group readiness capabilities: Business, People, Governance (business-focused) and Platform, Security, Operations (technology-focused). Each has recognizable executive owners.
• Capability — an organisational ability to use people, process, and technology to produce a business outcome (for example cloud financial management). CAF v3 catalogues 47 capabilities across the six perspectives.
• Foundational capability — the subset of capabilities most organisations need early (identity, security governance, provisioning and orchestration, cloud financial management, observability, incident management, cloud fluency). You grow these first, not all 47 at once.
• Transformation domain — one of the four things that change: Technology → Process → Organization → Product, arranged as a value chain in which each domain enables the next.
• Value chain — the ordering rule for the domains: ambition in an upper domain (Product) is enabled by — and gated by — the domains beneath it (Organization, Process, Technology).
• Transformation phase — one of the four iterative stages that give a program cadence: Envision (opportunities + outcomes), Align (capability gaps + readiness), Launch (production pilots), Scale (expand + realize benefits). Run as overlapping waves, not a waterfall.
• CAF assessment — the repeatable activity of rating in-scope capabilities current-vs-desired, filtering to the gating gaps, assigning owners, and sequencing them into an action plan. Facilitated as a workshop or self-served via CART.
• AWS Cloud Adoption Readiness Tool (CART) — a free, self-service questionnaire that produces a cloud-readiness baseline across the perspectives, used to seed or sanity-check a CAF assessment.
• Action plan — the assessment’s real output: the prioritized, owned, dated, dependency-sequenced list of capability gaps to close this iteration (not a maturity report to admire).
• Cloud Value Framework (CVF) — AWS’s four dimensions for measuring cloud value: cost savings (TCO), staff productivity, operational resilience, business agility. Every benefit and benefits-realization metric maps to one of these.
• Well-Architected Framework — AWS’s per-workload design-review framework (six pillars: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, Sustainability). Complements CAF, which works at the org level. Assessed with the AWS Well-Architected Tool.
• AWS WAF (Web Application Firewall) — a different product from the Well-Architected Framework despite the similar abbreviation: a Layer-7 firewall that inspects and filters HTTP(S) requests to protect web applications. Say “Well-Architected” for the framework to avoid the collision.
• Migration Acceleration Program (MAP) — AWS’s funded migration program with three phases (Assess → Mobilize → Migrate & Modernize) and the 7 Rs disposition options. It is the execution vehicle for the migration that CAF frames.
• 7 Rs — the migration-disposition choices made per application: Retire, Retain, Rehost, Relocate, Repurchase, Replatform, Refactor.
• Cloud Center of Excellence (CCoE) — a central team that builds paved roads, guardrails, and a shared platform so product teams can self-serve safely; the mainstream cloud operating model that CAF engagements usually converge on.
• Landing zone — a well-architected, multi-account baseline (identity, guardrails, network, logging) that product teams build on; on AWS, implemented with Control Tower + Organizations + IAM Identity Center.
• Benefits realization — the Governance benefits-management capability: measuring the actual outcome against the Envision target (for example via Cost Explorer and Budgets), so savings and revenue are proven, not assumed.
• Organizational change management (OCM) — the People-perspective discipline (stakeholder mapping, communication, champions, adoption metrics) that gets people to actually use the new cloud capabilities. Often the real critical path of a transformation.
• Stakeholder alignment — binding every opportunity and every capability gap to a named senior sponsor and a measurable outcome, so accountability is explicit and traceable back to a business result.
• Cloud fluency — the People-perspective capability describing how confidently the workforce understands and uses cloud; low fluency (few certifications, no shared vocabulary) silently gates almost every other capability.

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.