Evaluate a Migration Solution that Leverages the Microsoft Cloud Adoption Framework — Lesson

A retailer's CTO announces a "24-month cloud migration". Eighteen months later the project has burned $$18M$, migrated a quarter of the planned workloads, and lost two of its three architects. The post-mortem finds the same root cause everywhere: the team picked tools and migrated workloads before there was a strategy, a landing zone, or a governance baseline. Each migrated workload needed its own subscription, its own NSG design, its own logging — and each redesign created drift from the previous one. A neighbouring retailer ran a similar migration two years earlier using the Microsoft Cloud Adoption Framework (CAF). They spent the first three months on Strategy, Plan, and Ready phases before touching a single workload. The migration phase then took half as long, and the platform team finished with one governance model rather than seven. This lesson is about why that order matters — and how to apply CAF correctly.

We will work through the Microsoft Cloud Adoption Framework the way the AZ-305 exam expects you to: the six methodologies (Strategy, Plan, Ready, Adopt — including Migrate and Innovate, Govern, Manage, Secure), the Azure Landing Zone pattern, and how the CAF aligns with specific migration tools. Reference: the AZ-305 exam study guide, particularly Chapter 4 Skill 4.3 on migrations, and the Microsoft CAF documentation.

Why This Matters

CAF is the framework that lets architects sequence a cloud migration so it actually finishes on time. The AZ-305 exam tests this LO because the methodology decisions — what to do before you migrate anything, how to structure the landing zone, what governance to put in place — determine whether the migration succeeds. Getting them right is a strategic skill that organisations pay senior architects to provide.

The career payoff is concrete: every "we're moving to Azure" kickoff, every "our migration is stuck" rescue mission, every regulator's audit of cloud governance touches CAF. If you can map a customer's situation to the right CAF phase, recommend the appropriate Landing Zone reference architecture (or Azure Landing Zones), and pair CAF artifacts with downstream migration tools, you will pass this slice of the exam and lead cloud migrations like a senior architect.

Prerequisites

Before working through this lesson, make sure you can answer each prompt below in one or two sentences.

• Migration motivations. Can you list common motivations? — Self-check: name three "critical" motivations vs three "innovation" motivations.
• Management groups and subscriptions. Are you familiar with the Azure resource hierarchy? — Self-check: which level is the policy-inheritance root for the tenant?
• Landing zone concept. Have you encountered the term? — Self-check: what does a "landing zone" provide before workload deployment?
• Migration strategies. Are you familiar with the 5 Rs (or 7 Rs): rehost, replatform, refactor, rearchitect, rebuild, retire, retain? — Self-check: which one is the lightest-touch?
• Azure Policy. Do you know what it does at scale? — Self-check: name one policy you would assign at the management-group root.

If any feels shaky, review Unit 1 governance and Unit 4 migration modules.

Learning Objectives

By the end of this lesson, you will be able to:

1. Describe the six CAF methodologies and the artifacts each one produces.
2. Map a customer's situation (where they are in their cloud journey) to the right CAF phase and next action.
3. Recommend an Azure Landing Zone implementation (reference architecture, Azure Landing Zones IaC, or custom).
4. Identify the right CAF artifact for a given exam scenario (Strategy doc, Plan, Landing Zone, Operations baseline).
5. Pair CAF outputs with downstream tooling — Azure Migrate for assessment, Azure Policy for governance, Defender for Cloud for security.
6. Recognise anti-patterns — migrate-first-strategy-later, custom landing zone instead of Azure Landing Zones, ungoverned subscription vending — and rewrite them.

Building Blocks

Read this section as a glossary. Each term: analogy, formal definition, why it matters.

Cloud Adoption Framework (CAF) — Microsoft's playbook for cloud adoption, organised into six methodologies. Like the building code for a construction project. Formally, a published framework on learn.microsoft.com/azure/cloud-adoption-framework that bundles strategy templates, plans, reference architectures, and tools. It matters because CAF is the canonical Microsoft-recommended approach to cloud migration — exam questions on this LO route to its phases.

Strategy methodology — The first CAF phase. Define motivations, business outcomes, and the business case. Output: a strategy document. It matters because organisations that skip strategy migrate workloads without alignment and stall.

Plan methodology — Inventory current state, prioritise workloads, build a migration plan. Output: a migration plan and a skills-readiness plan. It matters because the plan converts strategy into a sequenced workload backlog.

Ready methodology — Build the foundational Azure environment (landing zones) before migrating anything. Output: an Azure Landing Zone (subscriptions, networks, identity, governance baseline). It matters because workloads landing in an unready environment create per-workload firefighting.

Adopt methodology — Two sub-methodologies: Migrate (move existing workloads) and Innovate (build new cloud-native workloads). Output: production workloads on Azure. It matters because Adopt is where the "doing" happens — but only after Strategy, Plan, Ready.

Govern methodology — Apply governance baselines: policy, compliance, cost, security postures, identity. Output: a governance disciplines baseline. It matters because governance applies during adoption, not after — retroactive governance is painful.

Manage methodology — Establish operations: monitoring, backup, DR, business-continuity. Output: an operations baseline. It matters because operations need to be ready before workloads go to production.

Secure methodology — Apply security baselines: Defender for Cloud, Zero Trust, network segmentation. Output: a security baseline. It matters because security is parallel to all other methodologies — not a phase to do last.

Azure Landing Zone (ALZ) — A reference implementation of the Ready methodology — management groups, subscriptions, networking, identity, monitoring, policy — deployable via Microsoft-supplied Bicep / Terraform IaC. Formally, the Azure/ALZ-Bicep and Azure/terraform-azurerm-caf-enterprise-scale reference implementations. It matters because most enterprise migrations should deploy ALZ as the foundation rather than building a custom one.

Subscription vending — A process that lets workload teams request a pre-configured subscription. Like a self-service kiosk for landing zones. Formally, an automated workflow that creates a subscription in the right management group, applies policy, assigns RBAC, and creates a VNet. It matters because subscription vending lets the platform scale to dozens of teams without manual setup.

Migration motivations — Drivers for moving to cloud. CAF groups them into "critical business events" (datacenter exit, M&A, end-of-life hardware), "migration motivations" (cost, agility, modernisation), and "innovation motivations" (new product capabilities, ML/AI, data democratisation). It matters because the motivation drives the migration strategy: critical event $\to$ rehost fast; innovation $\to$ refactor / rebuild.

Deep Dive

1. The six CAF methodologies — sequence and artifacts

[!IMPORTANT] Strategy $\to$ Plan $\to$ Ready is sequential; once Ready is established, Migrate and Innovate run in parallel; Govern, Manage, and Secure run in parallel with everything else. Skipping Strategy / Plan / Ready is the canonical anti-pattern.

2. Strategy and Plan — the inputs that shape everything else

The Strategy methodology produces a one-pager that names motivations and business outcomes. The exam tests recognising which motivations imply which migration approaches.

The Plan methodology takes the strategy and builds a workload backlog with priorities. Azure Migrate discovery (covered in LO-41) is the main input.

3. Ready methodology — Azure Landing Zones

A landing zone is the Azure foundation: management group hierarchy, subscription model, networking, identity, policy baseline, observability. The exam tests two implementation paths:

The ALZ reference includes:

[!TIP] Use the Microsoft-published Azure/ALZ-Bicep reference implementation as the starting point. Customising it is normal; building from scratch usually re-implements what ALZ already provides.

4. Subscription vending — scaling adoption

Once the landing zone exists, application teams need subscriptions. Subscription vending automates: create subscription in the right MG, apply baseline policy, assign RBAC, deploy networking, and report back to the requesting team. The exam tests recognising this pattern as the "Adopt" enabler.

5. Govern, Manage, Secure — the parallel baselines

[!IMPORTANT] Govern, Manage, and Secure are not phases that happen after migration — they are continuous practices applied from day 1. Many failed migrations applied them retroactively and spent months remediating drift.

6. The Adopt methodology — Migrate vs Innovate

Migrate moves existing workloads. The migration toolset includes Azure Migrate, Database Migration Service, Azure Site Recovery, Storage Mover, Data Box. Choose tools based on workload type (LO-41–LO-44 cover the details).

Innovate builds new cloud-native workloads. The toolset includes the modern Azure compute / data / AI services (Functions, Cosmos, AI Foundry, Container Apps).

The exam often tests recognising whether a workload is a Migrate scenario or an Innovate scenario. Typical signal: existing on-prem version vs greenfield design.

7. CAF artifacts vs Well-Architected Framework — when each fits

The exam occasionally tests the boundary between CAF (organisational adoption playbook) and Well-Architected Framework (WAF) (workload-level design principles).

CAF is the wide-angle lens; WAF is the per-workload microscope. They work together — a workload designed against WAF principles lands in a CAF-designed landing zone.

8. CAF tools and accelerators

CAF is not just a methodology — it's also a set of practical tools and accelerators Microsoft provides.

[!TIP] When a customer asks "what tool should we use for X?", map X to a CAF methodology first. The tool flows from the methodology — picking tools without knowing the methodology produces a toolchain that does not cohere.

9. Common migration paths through CAF

CAF expects different organisations to take different paths. Three common patterns the exam tests:

Path 1 — Datacenter exit. Strategy with hard deadline. Plan emphasises the critical-event workloads first. Ready deploys ALZ in one month. Migrate rehosts the majority. Innovate is deferred.

Path 2 — Innovation-led. Strategy with no fixed deadline. Plan emphasises a single innovative workload (often AI / analytics). Ready deploys a minimal landing zone. Innovate builds the new workload. Migration of existing workloads runs alongside or later.

Path 3 — Hybrid steady-state. Strategy says cloud is one of several platforms. Plan keeps most workloads on-prem and migrates only specific ones. Ready deploys a smaller landing zone scoped to the migrating workloads. Manage and Secure span on-prem and cloud (Azure Arc).

[!NOTE] The exam often presents one of these three shapes and asks for the right recommendation. Reading the customer's motivations is most of the answer.

Worked Examples

Easy — identify the right CAF phase

Problem. A customer says: "We've migrated 40 workloads from on-prem to Azure VMs, but our policy baseline is inconsistent — some subscriptions have it, others don't." Which CAF phase needs work?

Solution. Govern (and probably Ready). The lack of consistent policy at scale means the Ready phase did not produce a complete governance baseline, and Govern hasn't been applied uniformly. The fix is to deploy ALZ policy initiatives at the management-group root so all subscriptions inherit them.

Medium — sequencing recommendation

Problem. A new CTO inherits a half-done migration. There are 30 workloads in Azure (most rehosted), no landing zone, no central logging, and three different subscription models. They want to migrate 200 more workloads. Recommend a sequencing.

Solution. Pause migration. Run the Ready phase: deploy ALZ (or equivalent landing zone). Migrate the existing 30 workloads under the new landing zone structure (re-tag, re-policy, route logs to central Log Analytics). Then resume migration of the remaining 200 — each new workload lands in the governed environment. The order is non-negotiable: more workloads without Ready compound the existing problem.

Hard — choose the migration strategy mix

Problem. A retailer with a datacenter-exit deadline of 18 months has 400 workloads. Inventory shows 250 are legacy Windows Server apps with no roadmap; 100 are modern .NET services; 50 are decommission candidates. Recommend a CAF-aligned strategy.

Solution. Strategy phase: motivation is critical business event (DC exit). Plan phase prioritisation:

• Rehost the 250 legacy Windows apps (Azure Migrate Server Migration). Speed > optimisation.
• Replatform the 100 modern .NET services to App Service or Container Apps. Modest investment, large operational improvement.
• Retire the 50 decommission candidates before migration.

Run Ready (deploy ALZ) in parallel with the first wave. Migrate, Govern, Manage, Secure all run in parallel after Ready completes. The DC exit deadline drives speed; replatform investment delivers long-term value without delaying the deadline.

Visual Explanations

Before the figures, two more pattern notes that the exam mines:

CAF skills readiness. The Plan methodology also covers people: a skills-readiness plan identifies who needs to learn what (Azure fundamentals, IaC, security, FinOps) so the platform team is capable of operating what they deploy. The exam occasionally tests recognising the skills plan as a CAF deliverable — most candidates miss it because it isn't technical.

Innovation gates and learning loops. The Innovate sub-methodology is iterative — build, measure, learn — and CAF includes lean templates for hypothesis-driven feature development. Recognising this matters for exam questions where the customer says "we're experimenting with AI" — the right answer is Innovate (with measurement and small-batch iteration), not Migrate (lift-shift of known workloads).

Govern baseline as a continuous discipline. A common exam scenario shows an organisation that has applied policies once and forgot about them. The right CAF answer is that Govern is continuous: policy assignments need periodic review, exemptions need expiry dates, and Azure Advisor recommendations should feed back into the policy baseline. Govern is not a checkbox; it's a quarterly cadence.

Manage and Secure as parallel disciplines. Both span the entire adoption journey. Operations baselines (Manage) establish how incidents are detected, escalated, and resolved; security baselines (Secure) establish identity, segmentation, and continuous posture. Treat them as parallel rails rather than terminal phases.

Practical ALZ deployment shape. Most enterprise deployments use the published Azure/ALZ-Bicep reference and invoke it via a pipeline. The shape of a typical first commit:

The ordering matters: management-group hierarchy first, then policy definitions and assignments, then platform subscriptions, then connectivity and identity. Customisations apply at each step rather than after the fact.

Figure 1 — CAF methodology sequence

Figure 2 — ALZ management-group hierarchy

Figure 3 — Migration-strategy decision

Common Mistakes

❌ Myth: "Start migrating workloads — we can put governance in later." ✅ Reality: Retroactive governance is painful and never as complete. Ready / Govern / Secure baselines must be in place before workloads land. Why it's tricky: The "let's just ship" instinct accelerates the first few workloads and slows the next hundred.

❌ Myth: "We need a custom landing zone — our environment is special." ✅ Reality: Most enterprise landing-zone requirements are covered by Azure Landing Zones IaC. Customise it; don't rebuild it. Why it's tricky: Architects default to NIH (not-invented-here) for high-stakes work; ALZ has been hardened by thousands of deployments.

❌ Myth: "Innovate comes after Migrate." ✅ Reality: Migrate and Innovate are parallel sub-methodologies of Adopt. You can innovate on cloud-native services while migrating existing workloads. Why it's tricky: Linear thinking forces sequencing; CAF specifically allows parallel adoption tracks.

❌ Myth: "Secure is just a checklist applied at the end." ✅ Reality: Secure is a continuous methodology, parallel to Govern and Manage. Defender for Cloud, identity baselines, and segmentation start with Ready, not after Migrate. Why it's tricky: Many security checklists exist; treating them as a phase rather than a continuous discipline guarantees gaps.

Practice Exercises

🟢 Exercise 1. A customer says they have "started migrating" but cannot describe their motivations or business outcomes. Which CAF phase should they revisit?

▶💡 Hint

Motivations and outcomes are the Strategy artifact.

▶✅ Solution

Strategy. Without a clearly articulated motivation (datacenter exit? cost? innovation?) and business outcomes, the team cannot prioritise the Plan. They should run a one-day Strategy workshop with executive sponsors before further migration work.

🟡 Exercise 2. A regulated bank wants a landing zone. They are debating ALZ vs custom. Recommend.

▶💡 Hint

ALZ is opinionated but customisable.

▶✅ Solution

Deploy ALZ as the baseline and customise the policy initiative for the bank's regulatory requirements (PCI-DSS, ISO, local financial regulators). Custom from scratch is rarely needed; the customisation surface in ALZ covers most regulated-industry requirements while preserving Microsoft-tested defaults.

🟡 Exercise 3. A migration plan calls for 200 workloads to move in 6 months. Inventory shows only 30 have an owner identified. Recommend.

▶💡 Hint

Plan phase artifact: workload backlog with owners.

▶✅ Solution

Pause migration kickoff. Run a Plan-phase workshop: assign owners to all workloads, classify each by strategy (5 Rs), and prioritise. Without owners, 170 workloads will stall on questions only owners can answer. The 6-month timeline may need to extend or the scope reduce — both decisions belong to the sponsor.

🔴 Exercise 4. A team migrated 50 workloads to Azure but each one is in a different subscription model. The CFO asks for a consolidated cost report; it takes a week to produce. Diagnose at the CAF level.

▶💡 Hint

Naming / tagging / hierarchy is a Ready output.

▶✅ Solution

The Ready phase did not enforce a tagging standard or management-group hierarchy. Fix by retroactively applying CAF naming + tagging via Azure Policy (append/modify policies to add required tags), and grouping subscriptions under a consistent MG hierarchy. Build cost views by tag (Environment, CostCenter, Application) in Cost Management.

🔴 Exercise 5. A datacenter exit deadline is 9 months away. 300 workloads, 250 of which have no roadmap. Recommend a CAF-aligned plan.

▶💡 Hint

Time-critical exit favours rehost.

▶✅ Solution

Strategy: critical business event (DC exit) drives speed. Plan: rehost the 250 legacy workloads using Azure Migrate Server Migration. Run Ready in parallel (deploy ALZ during the first month) so workloads land in a governed environment. Retire workloads with no business value, retain (in DC or on hosted infrastructure) those with regulatory constraints that prevent move. Defer Innovate until after DC exit.

🟢 Exercise 6. True or false: the Manage methodology should start after all workloads are migrated.

▶💡 Hint

Operations need to be ready before workloads go live.

▶✅ Solution

False. Manage runs in parallel with Migrate — monitoring, backup, DR baselines must be in place before workloads handle production traffic, not after.

🟡 Exercise 7. Design the management-group structure for a single-tenant enterprise migrating to Azure for the first time.

▶💡 Hint

Use the ALZ default.

▶✅ Solution

Tenant Root $\to$ {Platform (Identity, Management, Connectivity), Landing Zones (Corp, Online), Sandbox, Decommissioned}. Place subscriptions under the appropriate MG. Apply baseline policy at Tenant Root; tighten policies at each child MG. This matches the published Azure Landing Zones default and serves 90% of enterprise scenarios.

Summary & Concept Map

• CAF has six methodologies. Strategy, Plan, Ready, Adopt (Migrate + Innovate), Govern, Manage, Secure.
• Strategy $\to$ Plan $\to$ Ready is sequential; Migrate and Innovate run in parallel; Govern, Manage, Secure are continuous.
• Azure Landing Zones IaC is the recommended Ready implementation. Customise; don't rebuild.
• Migration strategy is one of the 5 Rs (or 7 Rs): rehost, replatform, refactor, rearchitect, rebuild, retire, retain.
• Motivations drive strategy. Critical events favour rehost; innovation favours rebuild; cost favours replatform.
• Govern / Manage / Secure are parallel disciplines, not phases. Apply from day 1.