Design infrastructure solutions
CAF-Aligned Assessment and Migration Design
CoreUse Cloud Adoption Framework guidance, discovery evidence, dependency analysis, and workload-specific transfer tools to design migration waves and target platforms.
Aligned to the current AZ-305 study guide, skills measured as of April 17, 2026, verified August 25, 2026.
Why this matters
Migration success depends less on moving bytes than on choosing the right disposition, landing zone, dependency wave, validation, and operating model.
Must Know
- Base each workload disposition—rehost, replatform, refactor, replace, or retire—on business outcomes and discovery evidence.
- Use Azure Migrate, Database Migration Service, and Data Box for their distinct assessment, workload-migration, and offline-transfer roles.
- Compare online and offline transfer against network capacity, available time, data volume, and change rate.
- Prepare landing zones, dependency waves, synchronization, rollback, validation, and decommissioning before cutover.
Compare and Distinguish
- Rehost changes little; replatform adopts managed capabilities with limited redesign; refactor changes application architecture; replace moves to a different business capability; retire removes unneeded assets.
- Azure Migrate discovers, assesses, and coordinates server and workload migration; Database Migration Service supports database migration scenarios; Data Box handles offline bulk transfer.
- Online transfer minimizes physical handling but depends on network capacity and time; offline transfer can fit large datasets or constrained links but adds shipping and staging steps.
Scenario examples
- Scenario: A portfolio lacks reliable inventory and dependency data. Think: discover and assess before committing targets or waves.
- Scenario: A database must minimize downtime while moving to a managed target. Think: assess compatibility and select an online supported migration path.
- Scenario: Hundreds of terabytes sit behind a slow link. Think: compare Data Box with the available transfer window and change rate.
Exam traps
- CAF is not a single migration tool.
- A readiness score does not replace application-owner validation.
- Rehosting every workload preserves technical debt and may miss business goals.
Key takeaways
- Begin with business outcomes and evidence-based discovery.
- Select disposition and target per workload.
- Design dependencies, landing zone, validation, rollback, and operations before cutover.
How it works
- Azure Migrate gathers discovered inventory, utilization, configuration, and dependency evidence, then assessments apply target assumptions to report readiness, sizing, and cost guidance.
- For supported online migrations, replication or synchronization transfers an initial copy and then source changes; testing validates the target before cutover performs the final transition to the Azure workload.
- Database Migration Service coordinates supported database moves after compatibility assessment, while Data Box stages encrypted bulk data on an appliance for offline transport and later ingestion into Azure Storage.
Objects and administrative surfaces
- Strategy, plan, ready, adopt, govern, manage, and secure disciplines frame the broader cloud-adoption lifecycle.
- Discovery must cover utilization, dependencies, compatibility, licensing, security, availability, and business criticality.
- Migration waves need landing-zone readiness, rollback, data synchronization, cutover, validation, and decommissioning.
When to use it
- Use Azure Migrate discovery and dependency analysis before committing uncertain workloads to targets or waves.
- Use a supported online database migration path when compatibility is proven and downtime must be minimized.
- Use Data Box when approved physical transfer fits a bulk-data window that the available network cannot meet.
Security and governance implications
- Prepare landing-zone identity, policy, networking, logging, and key boundaries before the workload is cut over.
- Protect discovery data and migration credentials, and define ownership for rollback, retained source data, and secure decommissioning.
How to validate and revise the design
- When a wave fails, inspect omitted dependencies, address or DNS changes, identity, firewall rules, client configuration, and landing-zone policy.
- When cutover exceeds the window, measure residual change rate, synchronization, validation, routing changes, and rollback decision time.
More detail
- Dependency analysis can turn individually ready servers into one migration wave because moving only part of an application can introduce latency, reachability, or authentication failures.
- Assessment recommendations depend on collected utilization history and chosen sizing assumptions; stale inventory, an unrepresentative measurement window, or missing licensing constraints can produce a technically valid but poor target.
- Cutover downtime is governed by the remaining change rate, final synchronization, validation, DNS or routing updates, and rollback decision—not only by the speed of the initial bulk transfer.
Ready for the quiz?
- Which business outcome and discovery evidence support rehost, replatform, refactor, replace, or retire for this workload?
- Are inventory, utilization, dependencies, compatibility, licensing, security, and criticality reliable enough to form a migration wave?
- Does the transfer plan fit data volume, change rate, network window, cutover validation, and rollback?
Related objectives
- D4.3.S1 — Evaluate a migration solution that leverages the Microsoft Cloud Adoption Framework for Azure
- D4.3.S2 — Evaluate on-premises servers, data, and applications for migration
- D4.3.S3 — Recommend a solution for migrating workloads to infrastructure as a service (IaaS) and platform as a service (PaaS)
- D4.3.S4 — Recommend a solution for migrating databases
- D4.3.S5 — Recommend a solution for migrating unstructured data