12.2 IaaS & PaaS Workload Migration Design

Why This Topic Matters

Once assessment is done, AZ-305 tests the execution decision: "Recommend a solution for migrating workloads to infrastructure as a service (IaaS) and platform as a service (PaaS)." This is where the architect chooses between minimum-change rehosting and platform-managed replatforming, and where Microsoft's actual migration tooling (not just the CAF theory from Section 12.1) gets exercised.

IaaS vs. PaaS: The Core Trade-off

Infrastructure as a Service (IaaS) gives you Azure Virtual Machines, managed disks, and virtual networks — you still patch the OS, manage runtime versions, and handle scaling configuration yourself. Platform as a Service (PaaS) — Azure App Service, Azure Kubernetes Service (AKS), Azure Functions, Azure SQL Database — shifts OS patching, runtime updates, and much of the scaling logic to Microsoft. The decision is rarely "which is better" in the abstract; it is "which fits this workload's constraints."

Executing the Move: Azure Migrate Server Migration

Azure Migrate: Server Migration is the execution-phase companion to the Discovery and assessment tool from Section 12.1:

• Agentless replication (VMware only) uses the same Azure Migrate appliance deployed for discovery to replicate VM disks directly to Azure, with no software installed inside the guest OS.
• Agent-based replication installs a Mobility service agent inside the VM — required for Hyper-V, physical servers, and VMs running in other clouds (AWS, GCP), and preferred when you need finer control over the replication process.
• Test migration: before cutover, Azure Migrate lets you spin up a replicated VM in an isolated test VNet with no impact on the still-running source or ongoing replication. Skipping this step is a common exam trap — a scenario emphasizing minimal risk and validation before cutover is asking for a test migration, not an immediate final migration.
• Cutover: after validation, you perform the final replication delta and cut traffic to the new Azure VM, decommissioning (or repurposing) the source.

For web workloads specifically, Azure Migrate: Web app migration discovers ASP.NET and Java applications running on IIS or Tomcat and recommends migrating directly to Azure App Service — a purpose-built replatform path that a scenario naming "web application, no custom OS dependency" should trigger instead of a generic VM rehost.

Cost Levers for IaaS Rehosts

A rehost to IaaS does not have to mean losing all cost efficiency. Two levers recur on the exam:

• Azure Hybrid Benefit: existing on-premises Windows Server and SQL Server licenses (with Software Assurance) can be applied to Azure VMs, cutting compute costs — commonly cited as up to roughly 40% savings on Windows Server VM costs and even more when SQL Server licensing is included.
• Reserved Instances / Savings Plans: committing to 1- or 3-year terms on stable, predictable workloads further reduces steady-state IaaS cost, complementing Hybrid Benefit rather than replacing it.

Planning Replication Bandwidth and Cutover Windows

Initial replication for Server Migration (the "seeding" of VM disk data to Azure) can itself saturate a limited hybrid connection, especially across many VMs at once. Azure Migrate lets you throttle replication bandwidth so migration traffic does not starve production hybrid connectivity (site-to-site VPN or ExpressRoute) during business hours, and — for very large or bandwidth-constrained estates — supports an offline initial seeding path using Azure Data Box before switching to incremental network-based replication for the final delta. This mirrors the online/offline trade-off you'll see again for unstructured data in Section 12.4: match the transfer method to available bandwidth, not just to the target platform. After cutover, validate the migrated workload using the logging and monitoring design from Chapter 2 (Azure Monitor, Application Insights) before decommissioning the source — a scenario that skips validation and immediately deletes the source server is describing an unnecessarily risky migration.

Exam Scenario

Contoso has 200 VMware VMs. One legacy line-of-business app requires a custom kernel-mode driver and only runs on an out-of-support OS version — it must be rehosted to an Azure VM, since no PaaS service exposes kernel-level access. A second, stateless ASP.NET front-end has no custom OS dependency and should instead be replatformed to Azure App Service, eliminating OS patching overhead for that tier while leaving the legacy tier as IaaS. A single "one tool fits all workloads" answer is a trap — different tiers of the same estate frequently take different migration strategies.

Key Takeaways

• IaaS retains OS-level control at the cost of ongoing patch/scale management; PaaS trades that control for Microsoft-managed operations.
• Azure Migrate: Server Migration executes moves via agentless (VMware) or agent-based (Hyper-V, physical, other clouds) replication.
• Always test migrate into an isolated VNet before cutover — scenarios emphasizing validation and minimal risk want this step named explicitly.
• Azure Hybrid Benefit and Reserved Instances/Savings Plans are the standard cost levers for IaaS rehosts and stack together.
• A single estate can mix strategies: rehost the tiers with hard OS dependencies, replatform the tiers that don't have them.