Recommend a Solution for Migrating Workloads to IaaS and PaaS — Lesson

A bank's migration team has just finished assessing 400 workloads. The CTO walks in and asks one question: "Which of these should we lift-and-shift, and which should we modernise?" The architect's answer determines whether the migration finishes in 12 months or stretches to 30. Choose lift-and-shift for everything, and the cloud bill stays high while operational toil persists. Modernise everything, and the migration never finishes. The right answer is a workload-by-workload decision using the migration strategy ladder: rehost, replatform, refactor, rearchitect, rebuild, retire, retain. This lesson is about applying that ladder deliberately — using Azure Migrate Server Migration for IaaS lifts, App Service Migration Assistant for web replatforms, and App Containerization for container modernisation — and avoiding the most common architecture review failure: picking one strategy and applying it to every workload.

We will work through Azure's migration-strategy story the way the AZ-305 exam expects you to: the 5 Rs (or 7 Rs with retire / retain), tooling for each, and how to sequence waves of mixed strategies. Reference: the AZ-305 exam study guide, particularly Chapter 4 Skill 4.3 on workload migration.

Why This Matters

Migration strategy is the difference between cloud-as-cost-centre and cloud-as-business-platform. Lift-shift everything and the post-migration estate runs the same legacy patterns at higher cloud cost, just on cloud invoices instead of on-prem invoices. Refactor where it pays off and the platform delivers operational and cost benefits that compound for years. The AZ-305 exam tests this LO because the strategy choice is the single biggest determinant of post-migration outcomes — and it is also the choice most-frequently driven by ideology rather than workload fit.

The career payoff is concrete: every workload review, every "should we lift or modernise?" debate, every TCO defence touches this LO. If you can match a workload to one of the 7 Rs, pick the right Azure target (VM / App Service / Container Apps / AKS / Functions), and pair it with the right tooling, you will pass this slice of the exam and design migrations like a senior architect — making sequenced, evidence-based recommendations that satisfy both the cutover deadline and the long-term roadmap.

Prerequisites

Make sure you can answer each prompt below in one or two sentences.

• The 5/7 Rs. Can you list them: rehost, replatform, refactor, rearchitect, rebuild, retire, retain? — Self-check: which is the lightest-touch?
• Azure IaaS vs PaaS. Are you familiar with the boundary? — Self-check: which is Azure SQL DB?
• Azure Migrate Server Migration. Have you seen the agent-based and agentless modes? — Self-check: which one writes to managed disks?
• App Service / Container Apps. Do you know the basic deployment models? — Self-check: which one runs Kubernetes underneath but hides it?
• CAF migration phase. Where does workload migration sit? — Self-check: which CAF methodology covers it?

If any of these feels shaky, pause and review the migration intro modules in Unit 4 of the AZ-305 guide and re-read LO-40 (CAF) and LO-41 (assessment) before continuing this lesson.

Learning Objectives

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

1. Analyse a workload (technical debt, performance, business value) and translate it to one of the 5 Rs.
2. Evaluate trade-offs between rehost, replatform, refactor, rearchitect, rebuild for a given workload.
3. Recommend the right Azure target service for each migrated workload (VM, VMSS, App Service, Container Apps, AKS, Functions).
4. Design a migration wave plan that mixes strategies — fast rehost first, replatform second, refactor for high-value workloads.
5. Select the right tool — Azure Migrate Server Migration, App Service Migration Assistant, App Containerization — for each strategy.
6. Recognise anti-patterns — modernise-everything, lift-shift-everything, refactor-without-roadmap — and rewrite them.

Building Blocks

Rehost (lift-and-shift) — Move the workload with minimal change. VM stays a VM, just in Azure. Like moving a building from one block to another. Formally, replication and cutover via Azure Migrate Server Migration (or Azure Site Recovery). Fastest path; preserves all existing operational concerns. It matters when speed is the dominant factor (datacenter exit, regulatory deadline).

Replatform (lift-and-improve) — Move with modest changes that unlock platform benefits. E.g., on-prem IIS web app $\to$ App Service. Like renovating during a move. Formally, often automated by tools (App Service Migration Assistant); preserves code but changes the host. It matters when modest investment yields large operational savings (no OS patching, easier scaling).

Refactor — Change code to fit cloud-native patterns without changing functionality. Formally, code-level changes (e.g., move session state out of memory, replace local file I/O with Blob Storage) to enable PaaS deployment. It matters because some workloads are blocked from PaaS by one or two anti-patterns; targeted refactoring unblocks them.

Rearchitect — Significantly restructure architecture, often splitting a monolith. Formally, deeper redesign — domain decomposition, async messaging, event-driven flows. It matters when a workload's architecture is the bottleneck rather than its hosting platform.

Rebuild — Throw away and rewrite using cloud-native services. Formally, ground-up new implementation. It matters when the existing workload's technology is so dated (VB6, ColdFusion, Lotus Notes) that any other R is more expensive than starting over.

Retire — Decommission the workload. Formally, identify workloads with no business value and remove them rather than migrate them. Surprisingly common: typical estate has $10{-}30\%$ retireable workloads.

Retain — Keep the workload where it is (on-prem). Formally, defer migration indefinitely. It matters for workloads with regulatory constraints, vendor lock-in, or remaining hardware amortisation cycles. Pair with Azure Arc to extend Azure management to retained workloads.

Azure Migrate Server Migration — The supported tool for rehosting VMs (and physical servers). Formally, agentless (vCenter / Hyper-V) or agent-based (everything else) replication + cutover. Replicates to managed disks; cutover swaps DNS. It matters because this is the canonical rehost path.

App Service Migration Assistant — A downloadable tool that assesses ASP.NET sites on IIS and migrates them to App Service. Formally, walks site config, identifies blockers, and performs the move (with manual blocker resolution). It matters because it is the canonical replatform-to-App-Service tool.

App Containerization — An Azure Migrate feature that containerises an existing app for AKS deployment. Formally, generates a Dockerfile + base image + Helm chart from an existing ASP.NET / Java workload. It matters when the customer wants to modernise without a code rewrite — containerisation is in between replatform and refactor.

Deep Dive

1. The 7 Rs ladder

[!TIP] A useful rule: always prefer the lowest-effort R that delivers the required business outcome. Re-architect only when rehost / replatform cannot meet the goal.

2. Rehost with Azure Migrate Server Migration

The flow: ongoing replication keeps Azure in sync; at cutover, the source is stopped, the last delta replicates, and the Azure VM boots from the managed disks. Typical RTO at cutover: $\sim 15{-}30$ minutes.

[!IMPORTANT] Always run a test migration first. The test boots a clone into an isolated VNet; you validate functionality and then run the actual cutover when ready. Skipping the test migration is the canonical cutover-day surprise.

3. Replatform — App Service Migration Assistant

App Service Migration Assistant is the modernise-fast tool for ASP.NET / Java web apps. Run it on the on-prem IIS server; it analyses, surfaces blockers, and migrates to App Service in minutes for clean cases.

[!NOTE] When the migration tool flags a blocker (e.g., COM components, GAC dependencies), the choice is to refactor (remove the blocker) or move to App Service for Containers / AKS via containerisation.

4. Refactor — fixing one or two anti-patterns

Common refactor patterns the exam tests:

A typical refactor takes weeks rather than months and unlocks PaaS deployment.

5. Rearchitect and rebuild — the deep end

Both involve substantial engineering investment.

Rearchitect keeps the same business capabilities but redesigns the implementation: split a monolith into microservices, replace synchronous calls with async messaging, externalise state. Often pairs with Container Apps or AKS as the new runtime.

Rebuild starts from a blank page. Modern stack: Functions for event-driven, Cosmos DB for NoSQL, AI Foundry for ML, Container Apps for stateless services. The choice when no other R is feasible.

6. PaaS-target decision matrix

Once you've decided on Replatform / Refactor / Rearchitect / Rebuild, the next question is which PaaS target. The decision is driven by the workload shape and the team's modernisation appetite.

The "smaller is simpler" rule applies: pick the smallest PaaS abstraction the workload's design tolerates. Replatforming a 4-tier web app to App Service is cheaper than re-architecting to AKS — provided App Service can host the app.

[!TIP] Refactor often takes more time than replatform but lets you reach a smaller / cheaper / more managed PaaS target. Quantify the trade-off in the architecture review: cost of refactor effort vs cost saved over 3 years, and discount future savings honestly so the comparison reflects real value rather than wishful thinking.

7. Wave planning — mixing strategies

Most enterprise migrations mix several strategies. A typical wave plan:

7. Cutover-day mechanics

Cutover is the moment when the source workload stops and the Azure target takes over. The exam tests recognising the steps and the pitfalls.

[!WARNING] The most common cutover failure is missing dependency reachability. The Azure VM boots fine, but a downstream service (DB, file share, AD) is unreachable from its new network position. Validate this in the test migration before the real cutover.

8. Tooling deep dive: agentless vs agent-based replication

Azure Migrate Server Migration has two flavours. Knowing which to pick is exam-tested.

Most enterprises use agentless for the vCenter estate (covers 80% of VMs) and agent-based for the remainder.

9. Hybrid cutover patterns

Some workloads cannot be cut over in a single window. Patterns:

9. Cost optimisation during migration

Migration is the ideal moment to reset cost behaviours: right-size VMs based on Azure Migrate's performance-based recommendations rather than the on-prem allocation, apply Azure Hybrid Benefit to Windows / SQL workloads, purchase Reserved Instances for steady fleets, and put non-prod onto auto-shutdown schedules.

Stacking these levers can drop the migrated workload's monthly cost by half to two-thirds compared to a naive lift-shift baseline.

10. Post-cutover stabilisation

A migration is not "done" at cutover. Plan a $7{-}30$-day stabilisation period for monitoring, performance tuning, and addressing surprises that didn't surface in test migration. Track: VM CPU / memory utilisation, dependent service errors, customer-reported incidents, and cost actuals against assumptions. Many teams skip stabilisation; the right teams budget for it.

11. The "App Modernization" continuum

A useful mental model is the modernisation continuum from least-touch to most-touch:

Each step right delivers more cloud benefit but costs more upfront. The architect's job is to pick the rightmost step that is still cost-justified. Customers who pick "too far left" miss benefits; customers who pick "too far right" stall on engineering work.

The architecture review questions to ask:

• What is the workload's 3-year roadmap? (Sunset $o$ rehost; growth $o$ replatform+; foundational $o$ refactor / rearchitect.)
• What is the team's modernisation appetite? (Honest answer drives realistic strategy.)
• What is the cutover deadline? (Tight deadline pushes left on the continuum.)
• What is the operational cost-saving target? (Larger savings justify rightward moves.)

[!IMPORTANT] The R choice is per-workload, not per-organisation. A single migration plan typically mixes all 7 Rs across its workload backlog.

Worked Examples

Easy — pick the strategy

Problem. A workload is a Windows Server 2019 VM running a vendor app with no source code access. Recommend a migration strategy.

Solution. Rehost. No source access means no refactor / rebuild option. Replatform to App Service is also blocked. Use Azure Migrate Server Migration to lift to an Azure VM (and pay for the OS via AHB).

Medium — replatform candidate

Problem. A team owns an ASP.NET Framework web app on IIS with no custom modules, using SQL Server backend. Recommend.

Solution. Replatform: deploy via App Service Migration Assistant to App Service Windows; replatform SQL to Azure SQL Managed Instance (full T-SQL surface, since the app might use cross-database queries). Move session state to Azure Managed Redis if it currently lives in IIS in-memory.

Hard — mixed-strategy plan

Problem. A retailer has 200 workloads: 50 legacy VB6 desktop apps with no roadmap; 80 ASP.NET web apps; 40 SQL Server backends; 30 "we're not sure what these are doing".

Solution. Wave 0: investigate the 30 unknown workloads — likely retire candidates. Wave 1: rehost the 50 VB6 apps (no other R is feasible). Wave 2: replatform the 80 ASP.NET apps to App Service. Wave 3: assess the 40 SQL Server backends; most go to Azure SQL DB or MI; a few legacy ones go to SQL on VM. Plan in CAF Ready before any wave.

Visual Explanations

Figure 1 — Strategy decision flow

Figure 2 — Replication topology for Server Migration

Figure 3 — Target service map

Common Mistakes

❌ Myth: "Modernise everything — lift-shift is wasted effort." ✅ Reality: Modernising everything stalls migrations indefinitely. Rehost first for low-value workloads; modernise where the investment pays off. Why it's tricky: Cloud-native marketing favours modernisation; deadlines favour rehost.

❌ Myth: "Once it's in Azure, we can modernise later." ✅ Reality: Post-migration modernisation is real but commonly deprioritised once the workload is "stable in Azure". Plan modernisation as part of the migration, not after. Why it's tricky: "Later" reliably becomes "never" for non-burning issues.

❌ Myth: "Rebuild is the cheapest option for legacy." ✅ Reality: Rebuild has the highest upfront cost. Use it only when no other R works (e.g., VB6 desktop apps). For most legacy web/data workloads, replatform / refactor is cheaper. Why it's tricky: Engineers favour rebuild for technical satisfaction; total cost rarely favours it.

❌ Myth: "Refactor and rearchitect are the same." ✅ Reality: Refactor preserves architecture; rearchitect changes it. The cost gap is one order of magnitude. Why it's tricky: Both involve code changes; the architecture-vs-code line is the boundary.

Practice Exercises

🟢 Exercise 1. A Java app on Tomcat runs internal HR processes for 100 users. Code is in source control and the team owns it. Recommend.

▶💡 Hint

Replatform-friendly stack.

▶✅ Solution

Replatform to App Service Linux Tomcat. Use App Service Migration Assistant to move the WAR. Move session state to Redis if it currently uses Tomcat in-memory.

🟡 Exercise 2. A VB6 desktop app has no source code and no roadmap but is still used. Recommend.

▶💡 Hint

No source; vendor-bound.

▶✅ Solution

Rehost the underlying server to Azure VM if the app runs server-side; if it's purely a desktop app, deploy via Azure Virtual Desktop. Retire when the business stops using it.

🟡 Exercise 3. An ASP.NET app uses session state in IIS memory. The team wants App Service. Recommend.

▶💡 Hint

One refactor unlocks PaaS.

▶✅ Solution

Refactor session state to Azure Managed Redis (or distributed session via SQL). After this single change, replatform to App Service is straightforward.

🔴 Exercise 4. A team is months into a rebuild of a workload from .NET Framework to .NET 8 on Linux. Halfway in, the cutover deadline is now 90 days. Diagnose.

▶💡 Hint

Rebuild was the wrong R for the timeline.

▶✅ Solution

Pivot to replatform — package the existing .NET Framework as a Windows container via Azure Migrate App Containerization and deploy to AKS Windows node pool. Finish the rebuild in parallel for the long-term roadmap, but ship the containerised version now to meet the deadline.

🔴 Exercise 5. 50 Windows VMs need to move in 30 days. Recommend a tooling and process.

▶💡 Hint

Parallel replication waves.

▶✅ Solution

Use Azure Migrate Server Migration with agentless replication from vCenter. Group VMs into 5 waves of 10, replicate all in parallel for $\sim 2$ weeks, run test migrations, then cutover one wave per day for 5 days. Reserve the last week for stragglers and post-cutover monitoring. Apply AHB to Windows VMs in Azure to cut licensing cost.

🟢 Exercise 6. True or false: Azure Migrate App Containerization rewrites .NET Framework code to .NET Core.

▶💡 Hint

Containerisation packages, doesn't rewrite.

▶✅ Solution

False. App Containerization packages the existing code into a Windows or Linux container with the appropriate base image. The code itself is unchanged. Rewriting to .NET Core / .NET 8 is a rebuild, not containerisation.

🟡 Exercise 7. Design a wave-1 plan for 30 lift-shift Windows VMs.

▶💡 Hint

Group, test, cutover.

▶✅ Solution

Day $1{-}3$: deploy Azure Migrate appliance; start replication for all 30 VMs concurrently. Day $4{-}10$: replication stabilises. Day $11{-}12$: test migration of 3 representative VMs. Day 13: review test results and remediate. Days $14{-}18$: cutover 6 VMs per day during change-window. Day $19{-}21$: monitor, address issues, complete the wave.

Summary & Concept Map

• Seven Rs: Retire, Retain, Rehost, Replatform, Refactor, Rearchitect, Rebuild.
• Match strategy to workload, not ideology. Lift-shift for speed; replatform for PaaS benefits; refactor for blocked workloads; rebuild only when nothing else fits.
• Azure Migrate Server Migration is the canonical rehost tool. Run a test migration first.
• App Service Migration Assistant replatforms web apps.
• App Containerization modernises without code rewrite — bridges between replatform and refactor.
• Mix strategies in waves. Retire, rehost, replatform first; refactor / rearchitect later.