12.1 Migration Assessment: Cloud Adoption Framework & On-Premises Evaluation

Why This Topic Matters

AZ-305's Migrations subgroup opens with the two bullets that come before you pick any target service: "Evaluate a migration solution that leverages the Microsoft Cloud Adoption Framework (CAF) for Azure" and "Evaluate on-premises servers, data, and applications for migration." Exam scenarios in this area rarely ask "which VM size?" — they ask "what should you do first, before you touch a single resource in Azure?" Getting this wrong on the exam (and in practice) means recommending a migration tool before you have discovered what you actually have, sized it correctly, or built a business case a stakeholder will approve.

Cloud Adoption Framework: The Migrate Methodology

The Cloud Adoption Framework (CAF) is Microsoft's prescriptive methodology for moving to and operating in Azure. CAF organizes adoption into phases — Strategy, Plan, Ready, Adopt (which includes Migrate and Innovate), Govern, Manage, and Secure — with Migrate as the phase an AZ-305 architect owns most directly. Inside Migrate, CAF defines a repeatable loop:

1. Assess — inventory workloads, assess technical readiness, and estimate cost/effort.
2. Deploy (Migrate) — execute the move using the appropriate migration tooling.
3. Release (Optimize/Promote) — validate the workload in production, decommission the source, and optimize cost/performance.

The most heavily tested CAF artifact is the set of migration strategies, historically called the "5 Rs" and now commonly extended to six:

Exam trap: a question that says "migrate with no application changes and the shortest possible timeline" is asking for Rehost, even if PaaS would be "better" long-term — AZ-305 rewards matching the stated constraint, not the theoretically optimal architecture.

Azure Migrate: The Assessment Engine

Azure Migrate is the central hub for the Assess step and the tool AZ-305 expects you to name whenever a scenario needs discovery, sizing, or a business case:

• Discovery: an Azure Migrate appliance deployed on-premises connects to VMware vCenter or Hyper-V hosts for agentless discovery (no software installed inside each VM). Physical servers, other clouds (AWS/GCP), and scenarios needing deeper OS-level telemetry use agent-based discovery (Azure Migrate: Discovery and assessment agent plus the Dependency agent).
• Assessment sizing modes: "As on-premises" sizing matches the Azure VM SKU to the source server's configured specs (safe, but often over-provisions). Performance-based sizing uses actual CPU/memory/disk utilization history to right-size — this is the mode to recommend when a scenario emphasizes cost optimization.
• Dependency visualization: maps which servers talk to which, so you group interdependent workloads into the same migration wave — migrating a web tier without its database tier in the same wave breaks the application.
• Business case: compares multi-year on-premises TCO against Azure, factoring in Azure Hybrid Benefit, Reserved Instances, and right-sizing savings, using your actual discovered inventory rather than generic assumptions. This is the correct answer whenever a scenario asks for an executive-ready cost justification — a generic public TCO calculator uses estimated, not discovered, data.

Evaluating On-Premises Servers, Data, and Applications

Before recommending any target, an architect inventories four things: compute (OS version and support status — Azure Migrate flags servers on end-of-support OS like older Windows Server releases), applications (dependency mapping, licensing constraints), data (structured vs. unstructured, classification, compliance residency requirements), and network (available bandwidth, which determines whether an online transfer is even feasible within the maintenance window — a calculation you'll reuse in Section 12.4).

Exam Scenario

Contoso has 500 on-premises VMware VMs and wants a board-ready comparison of three-year on-premises costs versus Azure, including savings from right-sizing and existing Windows Server licenses. The correct recommendation is Azure Migrate: Discovery and assessment with the business case feature — not a standalone web TCO calculator, and not Azure Migrate: Server Migration (that tool executes moves; it doesn't build cost cases).

Key Takeaways

• CAF's Migrate methodology is Assess → Deploy (Migrate) → Release; Azure Migrate powers the Assess step.
• Match the migration strategy (Rehost/Refactor/Rearchitect/Rebuild/Replace/Retire) to the stated constraint, especially timeline and code-change tolerance.
• Use performance-based sizing (not as-on-premises sizing) when a scenario asks for cost optimization.
• The Azure Migrate business case feature — not a generic calculator — is the answer for discovered-inventory-based TCO comparisons.
• Dependency mapping determines migration wave grouping; never split tightly-coupled tiers across waves.