What is the Azure Cloud Adoption Framework?

Microsoft's answer to the question every company asks after the first credit card gets attached to a subscription: now what? The CAF is the map from "we want Azure" to an estate that will pass an audit.

New to cloud? CAMPUX is a free, build-first course. Start here →

The Azure Cloud Adoption Framework (CAF) is Microsoft's opinionated set of guidance, reference architectures, and tooling for taking an organization from "we want to use Azure" to a governed, secure, well-run estate. It is organized around six phases — Strategy, Plan, Ready, Adopt, Govern, and Manage — and its most concrete output is the landing zone: a pre-built, pre-governed environment your workloads deploy into.

That is the definition. Here is the honest version. CAF is what stops the thing I have watched happen at three different companies: someone spins up a subscription, deploys fast, wins a demo, and eighteen months later there are forty ungoverned subscriptions, nobody knows what is public, and the security team is finding storage accounts by accident. CAF is the discipline that would have prevented that, written down and turned into deployable templates. It is not a product you buy. It is a way of not making the expensive mistakes in a predictable order.

Where CAF sits — and what it is not

People confuse two Microsoft frameworks constantly, so clear this up first. The Cloud Adoption Framework is organization-scoped. It answers "how does this whole company get onto Azure cleanly." The Well-Architected Framework is workload-scoped — it grades one specific application against five pillars (reliability, security, cost, operational excellence, performance). CAF builds the neighborhood; WAF inspects one house. You use CAF to stand up the estate and WAF to pressure-test the app running inside it. They are complementary, not competing.

CAF is also not a certification, not a single tool, and not something you deploy in one command. It is a body of guidance on Microsoft Learn, plus a set of reference implementations — most importantly the landing zone accelerator — that turn that guidance into Bicep and Terraform you can run.

The six phases, one sentence each

The phases are not a strict waterfall. Strategy and Plan happen once up front; Ready and Adopt are where you build; Govern and Manage run forever in the background from the day the first workload goes live. Do not picture a finish line. Picture two setup steps, two build steps, and two things that never stop.

• Strategy — decide why you are moving to the cloud and what business outcome justifies it, so every later decision has something to point back to.
• Plan — turn that motivation into a real backlog: an inventory of what you have, what moves first, and an honest look at whether your people have the skills yet.
• Ready — build the landing zone, the pre-governed foundation of identity, networking, management groups, and policy that everything else deploys into.
• Adopt — migrate existing workloads or build new ones inside that foundation, which is the phase people wrongly think is the whole thing.
• Govern — keep the guardrails on: policy, cost controls, and compliance that hold the estate in shape as it grows.
• Manage — operate what you built — monitoring, reliability, incident response — so it keeps running after the launch excitement fades.

Adopt is the loud phase. Govern and Manage are the phases that keep you employed.

What a cloud engineer actually touches in each phase

Strategy and Plan are mostly not your job — that is architects, finance, and leadership deciding direction and money. Your fingerprints start at Ready and never really leave. This is the table worth memorizing, because it maps the framework onto the buttons you press.

The landing zone, in plain terms

If you take one concrete thing from CAF, take this. A landing zone is the environment a workload "lands" in, built and governed before anyone deploys an app into it. Instead of handing a team an empty subscription and hoping, you hand them a subscription where identity is already wired to Entra ID, networking follows a hub-and-spoke pattern, RBAC roles are scoped, a handful of Azure Policies are already denying the obvious mistakes, and every resource logs to a central workspace. The guardrails exist on day zero, not after the auditor shows up.

The structural backbone is management groups — a hierarchy that sits above subscriptions so you can assign policy and access once, at the top, and have it inherit downward. A common layout has a top-level group, then children for Platform (shared services), Landing Zones (where workloads live), Sandbox (safe experimentation), and Decommissioned. Policy applied to "Landing Zones" hits every workload subscription under it automatically. That inheritance is the whole point: govern by structure, not by remembering to configure each subscription by hand.

The gap nobody puts on the slide

Here is where I earn the byline. If you are studying for AZ-900 or AZ-104, the exam wants you to name the phases and know that CAF is organizational while WAF is per-workload. You can pass that with a flashcard. The multiple-choice question is "which phase includes building the landing zone" and the answer is Ready. Fine.

The job wants something the exam cannot test: it wants you to stand up a landing zone that passes an audit. That means deploying the accelerator, then discovering the reference implementation does not match your company's reality, and adapting it — reworking the management group hierarchy, writing the specific policies your compliance team demands, fixing the naming convention the template assumed, untangling why a policy assignment is blocking a legitimate deployment. Nobody hands you a clean greenfield. You inherit forty existing subscriptions and have to retrofit governance onto a moving system without breaking what already runs.

That distance — between reciting "Strategy, Plan, Ready, Adopt, Govern, Manage" and being trusted to design a management group hierarchy for a real org — is the entire reason "certified, still not hired" is a phrase. The framework is genuinely good. Knowing its vocabulary is table stakes. Being able to open a Bicep file and produce a governed subscription that a security reviewer signs off on is the skill that gets paid.

How to learn it

Read the CAF documentation on Microsoft Learn for the shape and the vocabulary — it is free and it is the source of truth. But do not stop at reading, because that is the trap that produces people who can define a landing zone and have never built one. Build the pieces by hand at a small scale: create a management group, put a subscription under it, assign one real Azure Policy, apply a tagging standard, and route your logs somewhere central. Then break it and fix it. That is CAF at lab size, and it is the same thinking the enterprise accelerator automates — just small enough that you understand every line instead of trusting a template you cannot read.

Common questions