This chapter covers Azure Migrate and the various migration strategies (rehost, refactor, rearchitect, rebuild) for moving on-premises workloads to Azure. As a core objective under Domain 4 (Infrastructure), it typically appears in 10-15% of AZ-305 exam questions. You will learn how to plan, assess, and execute migrations using Azure Migrate, Azure Site Recovery, and Azure Database Migration Service, including the key considerations for each strategy.
Jump to a section
Imagine you're moving your entire household from one city to another. You have two options: you can pack everything into boxes, label them, and hire a moving truck to transport them to the new house, then unpack and arrange everything—this is like a rehost (lift-and-shift) migration. Alternatively, you could disassemble your furniture, rebuild it with new materials, and even redesign the layout—this is like a rearchitect migration. In Azure Migrate, the "moving truck" is the Azure Migrate appliance, which discovers and assesses your on-premises servers. The "packing" involves creating replicas of your VMs using Azure Site Recovery or Azure Database Migration Service. The "new house" is your target Azure environment. Just as you'd inventory your belongings and decide what to move, Azure Migrate assesses dependencies and performance to recommend the right Azure VM sizes and costs. The actual move uses replication—like taking incremental snapshots of your data—to minimize downtime. Finally, you "unpack" by testing the migrated resources and cutting over traffic from on-prem to Azure. If you skip assessment, you might bring unnecessary items (over-provisioned VMs) or miss dependencies, causing the move to fail—exactly like forgetting that your TV is bolted to the wall.
What is Azure Migrate?
Azure Migrate is a centralized hub for assessing and migrating on-premises servers, databases, web apps, and virtual desktops to Azure. It provides a unified platform that integrates with various Microsoft and third-party tools to support the full migration lifecycle: discovery, assessment, migration, and post-migration optimization.
Why Azure Migrate Exists
Organizations migrate to Azure for reasons like cost savings, scalability, disaster recovery, and end-of-life hardware. However, migration projects often fail due to lack of visibility into on-premises environments, incorrect sizing, or dependency issues. Azure Migrate solves this by offering automated discovery, dependency mapping, and right-sizing recommendations based on performance history.
How Azure Migrate Works Internally
Azure Migrate uses a lightweight appliance (OVA or script) deployed on-premises to discover servers. The appliance continuously collects metadata and performance data (CPU, memory, disk IOPS, network throughput) and sends it to Azure Migrate service. For VMware environments, it uses vCenter APIs; for Hyper-V, it uses WMI; for physical servers, it uses agentless discovery via SSH/WMI. The data is stored in an Azure Migrate project, which can then analyze and generate assessment reports.
Key Components
Azure Migrate Project: A logical container for discovery, assessment, and migration resources.
Azure Migrate Appliance: A lightweight VM or physical server that runs discovery. It can discover up to 10,000 VMware VMs, 5,000 Hyper-V VMs, or 1,000 physical servers per appliance.
Discovery: Agentless (for VMware/Hyper-V) or agent-based (for physical servers and some VMware). Agentless discovery collects metadata via hypervisor APIs; agent-based uses installed agents to collect performance data.
Assessment: Uses collected data to recommend Azure VM sizes (based on on-premises performance) and estimate costs. Supports three criteria: as-on-premises, performance-based, and as-on-premises with reserved instances.
Dependency Analysis: Agentless (using network traffic logs) or agent-based (using Microsoft Monitoring Agent) to map dependencies between servers. This helps identify which VMs must be migrated together.
Migration Strategies (The 4 Rs)
The exam focuses on four primary strategies: 1. Rehost (Lift-and-Shift): Move VMs as-is to Azure IaaS. Fastest, least risky, but may not optimize for cloud. Tools: Azure Site Recovery, Azure Migrate Server Migration. 2. Refactor (Lift-and-Optimize): Make minor changes to run on PaaS (e.g., move a SQL Server to Azure SQL Database). Balances speed and optimization. Tools: Azure Database Migration Service, App Service Migration Assistant. 3. Rearchitect: Modify the application architecture to use cloud-native features (e.g., break a monolith into microservices, use Azure Functions). Higher effort, but maximizes cloud benefits. 4. Rebuild: Rewrite the application from scratch using cloud-native technologies (e.g., .NET Core on Azure). Highest effort, but full cloud optimization.
Assessment Settings and Defaults
Assessment criteria: Performance-based (default) uses 95th percentile performance data to right-size. As-on-premises maps directly to equivalent Azure VM.
Sizing: Based on CPU utilization, memory utilization, disk IOPS, and throughput. Default performance history: 1 month. Default percentile: 95th.
Comfort factor: Default 1.2 (buffer to avoid undersizing). Can be set from 1.0 to 2.0.
Currency: Assessments can be in USD, EUR, GBP, etc.
Discount: Can apply Azure Hybrid Benefit and reserved instances.
Migration Process Using Azure Site Recovery (ASR)
Enable replication: Configure ASR to replicate on-premises VMs to Azure. Choose target region, storage type (managed disks), and replication policy (default: 5-min frequency, 24-hour retention).
Initial replication: The first full copy of data is transferred to Azure. Time depends on data size and network bandwidth.
Ongoing replication: Changes are replicated every 5 minutes (default) to Azure storage.
Test failover: Perform a non-disruptive test to validate migration. Uses an isolated test network.
Failover: Stop replication, fail over to Azure, and cut over traffic. Can be planned or unplanned.
Complete migration: Finalize the migration to stop replication and remove on-premises resources.
Database Migration Using Azure Database Migration Service (DMS)
DMS supports online (minimal downtime) and offline migrations for SQL Server, MySQL, PostgreSQL, and MongoDB to Azure SQL Database, Azure Database for MySQL/PostgreSQL, or Azure Cosmos DB. - Online migration: Uses continuous replication to sync changes. Requires a premium SKU. - Offline migration: Takes a full backup and restores. Lower cost but more downtime. - Pre-migration assessment: DMS checks for compatibility issues and recommends fixes.
Interaction with Other Azure Services
Azure Site Recovery: Primary tool for rehost migration. Integrates with Azure Migrate for orchestration.
Azure Database Migration Service: For database migrations, integrated into Azure Migrate hub.
Azure App Service Migration Assistant: Assesses and migrates .NET and PHP web apps to Azure App Service.
Azure Data Box: For offline data transfer when network bandwidth is limited. Used for large data volumes (>10 TB).
Azure DevOps: Used for rearchitect and rebuild scenarios to deploy CI/CD pipelines.
Command Examples
To create an Azure Migrate project via CLI:
az migrate project create --name MyProject --resource-group MyRG --location eastusTo view assessments:
az migrate assessment list --project-name MyProject --resource-group MyRGTo enable replication with ASR:
az site-recovery replication-protected-item create --fabric-name MyFabric --protection-container MyContainer --name MyVM --policy-name MyPolicy --protected-item-type HyperVVirtualMachine --source-site-id ...Trap Patterns
Confusing Azure Migrate with Azure Site Recovery: Azure Migrate is the assessment and migration hub; ASR is the replication engine for rehost. Many exam questions describe a scenario and ask which tool to use—if it's about assessment, pick Azure Migrate; if about replication, pick ASR.
Assuming rehost is always best: The exam tests that rehost is fastest but may not be cost-effective. For example, a SQL Server VM might be better refactored to Azure SQL Database to reduce licensing costs.
Overlooking dependency analysis: Without it, you might migrate a VM that depends on another on-premises VM, causing application failure. Always use dependency mapping for multi-tier apps.
Ignoring performance-based sizing: The default recommendation uses performance data, but the exam may ask when to use as-on-premises sizing (e.g., when you need exact match for compliance).
Summary of Migration Strategies Comparison
Rehost: Least effort, minimal changes, no optimization. Best for quick wins and DR scenarios.
Refactor: Moderate effort, some optimization (e.g., move to PaaS). Best for reducing management overhead.
Rearchitect: High effort, significant optimization. Best for modernizing legacy apps.
Rebuild: Highest effort, full cloud-native. Best for strategic new development.
Post-Migration Optimization
After migration, use Azure Advisor to identify right-sizing opportunities, Azure Cost Management to track spending, and Azure Monitor to monitor performance. Consider using Azure Reserved Instances or Azure Hybrid Benefit to reduce costs.
Discover On-Premises Servers
Deploy the Azure Migrate appliance (OVA for VMware, script for Hyper-V/physical). The appliance connects to vCenter or Hyper-V host to collect inventory and performance data. For agentless discovery, it uses APIs to gather metadata like VM name, OS, disk size, and performance counters (CPU, memory, disk IOPS, network throughput). Data is sent to the Azure Migrate project every 15 minutes. For agent-based discovery, install agents on each server to collect more detailed data like running processes and network connections.
Assess and Right-Size VMs
Create an assessment group based on discovered servers. Choose assessment criteria: performance-based (default) uses 95th percentile of CPU/memory utilization over the past month to recommend Azure VM sizes. You can adjust percentile, history duration (1 day to 3 months), and comfort factor (1.0 to 2.0). The assessment outputs a list of recommended Azure VM SKUs, estimated monthly costs, and storage type (SSD, HDD). Dependency analysis can be added to group VMs that must migrate together.
Choose Migration Strategy
Based on assessment, decide on rehost, refactor, rearchitect, or rebuild. For rehost, use Azure Site Recovery to replicate VMs. For refactor, use Azure Database Migration Service for databases or App Service Migration Assistant for web apps. For rearchitect, design a new architecture using Azure Functions, Logic Apps, etc. For rebuild, start from scratch using Azure DevOps. The exam tests that you select the strategy that best meets business requirements (speed, cost, optimization).
Replicate and Migrate
For rehost: Enable replication in Azure Site Recovery. Specify target region, storage account (or managed disk), and replication policy (default: 5-minute sync interval, 24-hour recovery point retention). Initial replication copies all data; ongoing replication syncs changes. Perform a test failover to validate. When ready, execute a planned failover (minimal data loss) or unplanned failover. After failover, commit the migration to stop replication and finalize. For refactor: Use DMS to migrate databases online or offline. For offline, take a backup, copy to Azure, and restore. For online, set up continuous replication and cut over.
Cut Over and Optimize
After migration, redirect traffic from on-premises to Azure. Update DNS records, change connection strings, and decommission on-premises resources. Use Azure Traffic Manager or Azure Front Door for seamless cutover. Post-migration, use Azure Advisor to optimize costs (e.g., right-size VMs, use reserved instances). Monitor with Azure Monitor and set up alerts. For databases, implement geo-replication for DR. For web apps, configure auto-scaling and staging slots for deployments.
Enterprise Scenario 1: Large Financial Institution Migrating 500 VMs
A bank needed to migrate 500 on-premises VMs (Windows and Linux) to Azure within six months. They used Azure Migrate for discovery and assessment, which revealed 30% of VMs were over-provisioned. They chose rehost for 400 VMs using Azure Site Recovery, and refactor for 100 SQL Server VMs to Azure SQL Database to reduce licensing costs. Dependency analysis identified that 50 VMs had interdependencies, so they were grouped into a single migration wave. During replication, they used Azure Data Box for initial sync of 10 TB of data due to limited WAN bandwidth. The test failover revealed a network misconfiguration (missing NSG rules), which was fixed before production cutover. Post-migration, they used Azure Cost Management to track spending and reserved instances to save 40% on compute costs.
Enterprise Scenario 2: E-commerce Company Modernizing a Legacy Web App
A company with a monolithic .NET Framework web app on IIS and SQL Server wanted to modernize. They used Azure App Service Migration Assistant to assess compatibility, which found that the app needed minor changes (e.g., update connection strings, remove local file storage). They refactored the web app to run on Azure App Service (Windows) and migrated the database to Azure SQL Database using DMS online migration (minimal downtime). The app was then rearchitected to use Azure Cache for Redis for session state and Azure Blob Storage for file uploads. Post-migration, they implemented CI/CD pipelines with Azure DevOps and scaled out to multiple instances. The migration reduced operational overhead and improved scalability.
Common Pitfalls
Incorrect sizing: Using as-on-premises sizing without performance data leads to over-provisioning and high costs. Always use performance-based sizing with a comfort factor of 1.2.
Missing dependencies: Migrating a front-end without its back-end database causes application failure. Always run dependency analysis for multi-tier apps.
Network bottlenecks: Insufficient bandwidth for initial replication can cause long migration timelines. Use Azure Data Box for large data volumes (>10 TB) or implement bandwidth throttling.
Data loss during cutover: Failing to sync final changes before cutover can lose transactions. Use planned failover with final sync for minimal data loss.
What AZ-305 Tests on This Topic (Objective 4.3)
The exam focuses on your ability to recommend an appropriate migration strategy and tool based on business requirements. Key areas: - Migration strategies: Differentiate rehost, refactor, rearchitect, rebuild. Know when each is appropriate (e.g., rehost for speed, refactor for cost savings on databases, rearchitect for modernization). - Azure Migrate vs. ASR vs. DMS: Understand that Azure Migrate is for assessment, ASR for rehost migration, DMS for database migration. A common question: "You need to assess on-premises VMs for migration to Azure. What should you use?" Answer: Azure Migrate. - Assessment settings: Know default values: performance history 1 month, percentile 95th, comfort factor 1.2. The exam may ask what to adjust if you want more conservative sizing (increase comfort factor). - Dependency analysis: Know the two types: agentless (uses network logs) and agent-based (requires Microsoft Monitoring Agent). The exam might ask which to use for a specific scenario (e.g., agentless for VMware, agent-based for physical servers). - Replication frequency: ASR default replication interval is 5 minutes. For critical apps, you can reduce to 30 seconds (Premium). - Data Box: Used for offline data transfer when bandwidth is low or data volume >10 TB.
Common Wrong Answers and Why
Choosing Azure Site Recovery for assessment: Candidates confuse ASR with Azure Migrate. ASR does not assess; it replicates. If the question asks for assessment, the answer is Azure Migrate.
Selecting rehost for a SQL Server workload when refactor is better: The exam often presents a scenario where a SQL Server VM is expensive on-premises. Rehosting keeps licensing costs; refactoring to Azure SQL Database reduces them. The correct answer is refactor.
Ignoring dependency analysis: A question may describe migrating a web app without mentioning dependencies. The correct answer should include dependency analysis to ensure the backend database is also migrated.
Using performance-based sizing when as-on-premises is required: If the requirement is to match on-premises exactly (e.g., for compliance), use as-on-premises sizing. Performance-based might recommend a smaller VM.
Edge Cases and Exceptions
Physical servers: Can be discovered using agentless discovery (SSH/WMI) or agent-based. The exam may ask which tool to use for physical servers: Azure Migrate with agent-based discovery.
Linux VMs: Azure Migrate supports Linux discovery. For dependency analysis on Linux, use agent-based with Microsoft Monitoring Agent.
Government clouds: Azure Migrate is available in Azure Government, but some features may be limited.
Hyper-V without SCVMM: Azure Migrate can still discover Hyper-V hosts directly.
How to Eliminate Wrong Answers
If the question mentions "assessment" or "discovery", eliminate any option that only does replication (like ASR).
If the question says "minimize downtime" and the workload is a database, look for online migration (DMS online) rather than offline.
If the question says "reduce costs" for a SQL Server, look for refactor to Azure SQL Database rather than rehost.
If the question says "quickest migration", rehost is likely correct, but verify that the workload doesn't require optimization.
Azure Migrate is the assessment hub; use it for discovery, dependency mapping, and right-sizing before migration.
The four migration strategies are rehost, refactor, rearchitect, and rebuild; choose based on business goals: speed (rehost), cost optimization (refactor), modernization (rearchitect), or full cloud-native (rebuild).
Azure Site Recovery is the primary tool for rehost migration; it replicates VMs with a default 5-minute sync interval.
Azure Database Migration Service supports online (minimal downtime) and offline migrations for databases to Azure PaaS.
Dependency analysis is critical for multi-tier apps; use agentless (VMware) or agent-based (physical) mapping.
Performance-based assessment uses 95th percentile utilization over 1 month with a 1.2 comfort factor by default.
Azure Data Box is for offline data transfer when network bandwidth is limited or data volume exceeds 10 TB.
Post-migration optimization includes right-sizing, reserved instances, and Azure Hybrid Benefit to reduce costs.
These come up on the exam all the time. Here's how to tell them apart.
Azure Site Recovery (ASR)
Replicates entire VMs (OS + data) for rehost migration.
Supports VMware, Hyper-V, and physical servers.
Replication interval default 5 minutes, can be 30 seconds premium.
Test failover allows non-disruptive validation.
Best for moving workloads as-is with minimal changes.
Azure Database Migration Service (DMS)
Migrates databases (SQL, MySQL, PostgreSQL, MongoDB) to Azure PaaS.
Supports online (minimal downtime) and offline migrations.
Online migration uses continuous replication (CDC).
Pre-migration assessment checks compatibility.
Best for refactoring databases to managed services.
Mistake
Azure Migrate and Azure Site Recovery are the same service.
Correct
Azure Migrate is a hub for assessment and migration orchestration; it uses Azure Site Recovery as one of its replication engines for rehost migrations. Azure Site Recovery is primarily a disaster recovery service that can also be used for migration.
Mistake
Rehost (lift-and-shift) is always the best migration strategy.
Correct
Rehost is fastest but may not optimize costs or performance. For example, moving a SQL Server VM to Azure IaaS still requires SQL Server licensing; refactoring to Azure SQL Database can reduce licensing costs and management overhead.
Mistake
Dependency analysis is optional and can be skipped.
Correct
Skipping dependency analysis can lead to migration failures when interdependent VMs are migrated separately. Azure Migrate's dependency mapping (agentless or agent-based) is critical for multi-tier applications.
Mistake
Azure Data Box is used for online data transfer.
Correct
Azure Data Box is an offline data transfer device for large volumes (10-80 TB) when network bandwidth is insufficient. For online transfers, use Azure Site Recovery or Azure Database Migration Service.
Mistake
Performance-based sizing always recommends the cheapest VM.
Correct
Performance-based sizing uses the 95th percentile of utilization to recommend a VM that can handle peak loads, which may be larger than the average. To get cheaper recommendations, you can lower the percentile or reduce the comfort factor.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Azure Migrate is a centralized hub for discovery, assessment, and migration orchestration. It helps you evaluate on-premises servers and plan migration. Azure Site Recovery (ASR) is a replication engine used for disaster recovery and rehost migrations. ASR can be integrated with Azure Migrate to perform the actual replication of VMs. In short, Azure Migrate assesses, ASR migrates.
Use rehost (lift-and-shift) if you want the fastest migration with minimal changes, but you'll still pay SQL Server licensing costs. Use refactor if you want to reduce costs and management overhead by moving to Azure SQL Database (PaaS). Refactor requires minor changes (e.g., connection strings) and may involve using Azure Database Migration Service for online migration with minimal downtime.
Default settings: performance history of 1 month, percentile used is 95th, comfort factor is 1.2. These settings recommend an Azure VM size that can handle peak loads with a 20% buffer. You can adjust these to be more conservative (higher comfort factor) or more aggressive (lower percentile, shorter history).
Yes. For physical servers, you can use agentless discovery (via SSH for Linux or WMI for Windows) or agent-based discovery. For migration, you can use Azure Site Recovery with agent-based replication. Azure Migrate supports physical servers running Windows and Linux.
Online migration uses continuous replication (change data capture) to keep the source and target in sync, allowing minimal downtime. Offline migration takes a full backup, transfers it to Azure, and restores it, requiring more downtime. Online is recommended for production systems with low tolerance for downtime; offline is simpler and cheaper but involves longer downtime.
Agentless dependency analysis (for VMware) collects network traffic data from the hypervisor to identify connections between VMs without installing agents. Agent-based dependency analysis requires installing Microsoft Monitoring Agent on each VM to collect process and network data. The exam tests that agentless is simpler but less detailed, while agent-based provides richer data.
Azure Data Box is a physical device (up to 80 TB) for offline data transfer. Use it when network bandwidth is limited or when you have large datasets (>10 TB) that would take too long to transfer online. For example, initial replication of 20 TB of data over a 10 Mbps link would take months; Data Box can do it in days.
You've just covered Azure Migrate and Migration Strategies — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?