This chapter covers workload assessment and migration analysis for Azure, a critical skill for the AZ-305 exam. You will learn how to evaluate on-premises workloads, choose the right migration strategy (rehost, refactor, rearchitect, rebuild), and use Azure Migrate for discovery, assessment, and migration. Approximately 10-15% of exam questions touch this topic area, often appearing as scenario-based questions requiring you to recommend a migration approach based on business requirements and technical constraints.
Jump to a section
Imagine you are moving from a small apartment (on-premises data center) to a larger, more modern house (Azure). Before you can move, you must assess every single item you own: what is it, how old is it, does it still work, is it worth moving, or should you buy a new version? This is the workload assessment. You inventory servers (furniture), applications (appliances), and data (boxes). You decide which items to rehost (pack and move as-is), refactor (disassemble and reassemble with better parts), rearchitect (redesign the entire room layout), or rebuild (buy new). Migration analysis is like creating a detailed moving plan: which items go first (pilot migration), which go in the middle (bulk migration), and which are last (cutover). You also need to test that the new house's electrical wiring (networking) and plumbing (identity) work for your appliances. The Azure Migration and Modernization Program (formerly MAP) provides tools like Azure Migrate to discover, assess, and migrate, akin to a moving company that inventories, packs, and transports your belongings. Just as you wouldn't move fragile items without proper packaging, you must assess dependencies and performance baselines before migrating critical workloads. The analogy extends to cost: moving might save you money on rent (lower TCO) but requires upfront investment (migration costs).
What is Workload Assessment and Migration Analysis?
Workload assessment is the process of evaluating existing on-premises or other cloud workloads to determine their suitability for migration to Azure. It involves discovering assets, analyzing dependencies, assessing readiness, and estimating costs. Migration analysis builds on the assessment to plan the actual move, including sequencing, testing, and cutover. The goal is to minimize risk, downtime, and cost while maximizing performance and security post-migration.
Why It Exists
Organizations migrate to Azure for various reasons: cost savings, scalability, disaster recovery, or to adopt PaaS/SaaS services. However, a blind migration without proper assessment can lead to performance issues, security gaps, or unexpected costs. Azure provides a structured methodology and tools to ensure a successful migration.
The Azure Migration Framework
Microsoft's Cloud Adoption Framework (CAF) defines a migration methodology with four phases: Assess, Migrate, Optimize, and Secure & Manage. The Assess phase is where workload assessment and migration analysis occur. Key activities include:
Discovery: Identify all servers, applications, and data sources.
Dependency mapping: Understand inter-service dependencies.
Readiness assessment: Check compatibility with Azure services.
Cost estimation: Compare current vs. future costs.
Migration planning: Choose migration strategy and sequence.
Azure Migrate: The Primary Tool
Azure Migrate is a centralized hub for discovery, assessment, and migration. It supports:
**Discovery and assessment of servers running VMware, Hyper-V, physical servers, and other clouds (AWS, GCP).
Database assessment via Data Migration Assistant (DMA) and Azure Database Migration Service.
Web app assessment via Azure App Service Migration Assistant.
Virtual desktop assessment for Azure Virtual Desktop.
Data box for offline data transfer.
Azure Migrate uses a lightweight appliance (OVA or script) that collects server metadata, performance data, and dependency information. The appliance communicates with the Azure Migrate service via HTTPS (port 443).
Discovery Methods
There are two main discovery methods:
Agentless discovery: Uses VM snapshots and hypervisor APIs to collect metadata. No agents required. Supported for VMware and Hyper-V.
Agent-based discovery: Installs agents (Azure Monitor Agent or Dependency Agent) on each VM to collect deeper data, including running processes and network connections. Required for physical servers and dependency mapping.
Assessment Types
Azure Migrate provides two assessment types:
As-on-premises assessment: Sizes Azure VMs based on on-premises configuration (CPU, memory, disk) without considering performance. Useful for lift-and-shift.
Performance-based assessment: Sizes Azure VMs based on historical performance data (CPU utilization, memory usage, disk IOPS, network throughput). Typically more cost-effective.
Key parameters for performance-based assessment:
Performance history: Default 1 month, configurable up to 3 months.
Percentile utilization: Default 95th percentile, can be set to 50th or 99th.
Comfort factor: Default 1.2 (20% buffer), configurable from 1.0 to 2.0.
Readiness and Suitability Analysis
Each discovered server is assigned a readiness status:
Ready: Can migrate as-is.
Ready with conditions: Minor changes needed (e.g., unsupported OS version, small disk size).
Not ready: Major issues (e.g., incompatible OS, dependencies on unsupported features).
Readiness unknown: Azure Migrate cannot determine readiness (e.g., insufficient data).
Common readiness issues include:
Operating system: Windows Server 2008/2008 R2 extended support ended; Azure provides free extended security updates for three years after migration.
Disk size: Disks > 32 TB cannot be attached to Azure VMs (Azure managed disks max 32 TB for Ultra and Premium SSD v2).
Network: VMs with multiple NICs may need reconfiguration.
Licensing: SQL Server licenses may need Software Assurance for Azure Hybrid Benefit.
Migration Strategies: The 5 Rs
The exam expects you to know the five common migration strategies, often called the 5 Rs:
Rehost (Lift-and-shift): Move as-is with minimal changes. Fastest, lowest risk, but may not optimize for cloud. Use Azure Migrate and Azure Site Recovery.
Refactor (Lift and optimize): Make minor changes to leverage PaaS services (e.g., move from SQL Server to Azure SQL Database). Requires more effort but reduces management overhead.
Rearchitect (Modify architecture): Redesign applications to be cloud-native (e.g., break monolith into microservices, use containers). Highest effort, highest benefit.
Rebuild (Replace): Replace the application with a SaaS solution (e.g., replace custom CRM with Dynamics 365).
Retire: Decommission unused applications.
Migration Tools
Azure Site Recovery: For rehosting VMs and physical servers. Orchestrates replication, failover, and migration.
Azure Database Migration Service: For migrating databases to Azure SQL, Azure Database for MySQL/PostgreSQL, etc.
Azure App Service Migration Assistant: For .NET and PHP web apps to Azure App Service.
Azure Data Box: For large data transfers (up to 80 TB per device) when network is slow or expensive.
Azure Migrate: Server Migration: Agentless migration for VMware, Hyper-V, and physical servers.
Cost Estimation
Azure Migrate provides cost estimates based on:
Compute: VM size, number of instances, reserved instances vs. pay-as-you-go.
Storage: Managed disks (Standard HDD, Standard SSD, Premium SSD, Ultra Disk), backup costs.
Network: Data transfer egress (free inbound, paid outbound).
Licensing: Azure Hybrid Benefit for Windows Server and SQL Server.
Dependency Mapping
Dependency mapping helps identify which servers communicate with each other. Azure Migrate uses the Dependency Agent (installed on each VM) to collect network connection data. This is critical for planning migration groups (migrate together) and avoiding surprise outages.
Migration Wave Planning
After assessment, servers are grouped into migration waves:
Wave 0 (Pilot): Small number of low-risk servers to validate the process.
Wave 1 (Early adopters): A few more servers with moderate complexity.
Wave 2+: Bulk migration of remaining servers.
Wave N (Final cutover): Critical servers with complex dependencies.
Each wave includes test migration before final cutover.
Assessment of Non-Server Workloads
Databases: Use Data Migration Assistant (DMA) to check compatibility with Azure SQL Database, Azure SQL Managed Instance, or SQL Server on Azure VM. DMA identifies feature parity issues (e.g., CLR, linked servers).
Web apps: Use App Service Migration Assistant to assess .NET and PHP apps for Azure App Service. It checks for unsupported features (e.g., Windows authentication, custom modules).
Virtual desktops: Use Azure Virtual Desktop (AVD) assessment to evaluate remote desktop services and VDI environments.
Integration with Azure DevOps
For rearchitect or rebuild scenarios, Azure DevOps can be used to plan and track migration tasks. The assessment phase may include code analysis for refactoring.
Governance and Compliance
Assessment must consider regulatory requirements (e.g., data residency, encryption). Azure Policy can enforce compliance post-migration. Azure Blueprints can package resource templates and policies for consistent deployment.
Common Pitfalls
Overlooking dependencies: Migrating a server without its dependent servers can break applications.
Ignoring performance baselines: Sizing VMs based on on-premises configuration alone leads to overprovisioning or underprovisioning.
Underestimating network latency: Performance-sensitive applications may need ExpressRoute or proximity placement groups.
Skipping test migration: Always test before cutover to validate functionality and performance.
Exam Tips
Know the difference between agentless and agent-based discovery.
Understand when to use performance-based vs. as-on-premises sizing.
Remember the default performance history (1 month) and percentile (95th).
Be able to recommend a migration strategy based on business goals: rehost for speed, refactor for PaaS benefits, rearchitect for scalability, rebuild for cost savings.
Know that Azure Migrate is the primary assessment tool, but other tools like Azure Site Recovery and Azure Database Migration Service are used for actual migration.
Discover on-premises workloads
Deploy the Azure Migrate appliance (OVA for VMware, script for Hyper-V or physical). The appliance discovers servers by connecting to vCenter Server or Hyper-V host. For agentless discovery, it collects metadata (OS, disk, network) without installing agents. For agent-based discovery, install the Azure Monitor Agent and Dependency Agent on each server. Discovery runs continuously, collecting performance data (CPU, memory, disk IOPS, throughput) every 20 seconds for agentless, and every 5 minutes for agent-based. The data is sent to Azure Migrate project.
Assess readiness and dependencies
Create an assessment group in Azure Migrate. Select discovered servers and run an assessment. The assessment evaluates readiness based on OS version, disk size, network configuration, and other factors. For dependency mapping, install Dependency Agents and enable the feature in Azure Migrate. The agents report TCP connections every 5 minutes, creating a visual map of inter-server dependencies. Review the readiness report: 'Ready', 'Ready with conditions', 'Not ready', or 'Readiness unknown'. Identify servers that need remediation (e.g., upgrade OS, resize disks).
Choose migration strategy
Based on assessment results and business requirements, select a migration strategy from the 5 Rs. For rehost: use Azure Site Recovery or Azure Migrate Server Migration. For refactor: use Azure Database Migration Service for databases or App Service Migration Assistant for web apps. For rearchitect: redesign the application architecture, possibly using containers or serverless. For rebuild: replace with a SaaS offering. Document the strategy for each workload in the migration plan.
Plan migration waves
Group servers into migration waves based on dependencies and criticality. Start with Wave 0 (pilot): 2-3 low-risk servers to test the migration process. Wave 1: early adopters with moderate complexity. Subsequent waves: bulk migration. Plan the sequence: migrate dependent servers together in the same wave. Use Azure Migrate's grouping feature to create logical groups. Each wave should have a test migration phase to validate functionality before final cutover.
Execute migration and validate
For rehost, use Azure Migrate Server Migration to replicate VMs to Azure. Perform a test failover to a non-production Azure VNet to verify application functionality. After successful testing, run a planned migration (final cutover). For databases, use Azure Database Migration Service with online or offline mode. After migration, validate performance, connectivity, and security. Update DNS records and decommission on-premises servers. Monitor post-migration using Azure Monitor and Azure Advisor.
Enterprise Scenario 1: Large Financial Institution Migrating 5000 VMs
A global bank needed to migrate 5000 VMs from three data centers to Azure to reduce operational costs and improve disaster recovery. They used Azure Migrate for discovery and assessment. Agentless discovery was deployed for VMware environments, collecting metadata and performance data over three months. Dependency mapping was critical for their trading applications, which had complex inter-service dependencies. They discovered that 20% of servers had dependencies on mainframe systems that could not be migrated, so those were retired or replaced with SaaS. The bank chose a rehost strategy for most VMs to minimize risk, using Azure Site Recovery for migration. They used performance-based sizing with a comfort factor of 1.2 and 95th percentile. Cost estimation showed a 40% reduction in TCO over five years. The migration was executed in 10 waves over six months, with each wave including a test migration. Common issues included oversized disks (some VMs had 4 TB data disks with only 100 GB used) and outdated OS (Windows Server 2008 R2 needed free extended security updates). The bank used Azure Hybrid Benefit to save on Windows Server licenses. Post-migration, they used Azure Policy to enforce encryption and tagging.
Enterprise Scenario 2: E-Commerce Company Refactoring Web Applications
A mid-sized e-commerce company with 200 web applications running on-premises wanted to modernize. They used Azure App Service Migration Assistant to assess .NET and PHP apps. The assessment revealed that 30% of apps had dependencies on Windows authentication and custom IIS modules incompatible with Azure App Service. Those apps were rearchitected to use Azure AD and App Service Authentication. The remaining 70% were refactored to run on Azure App Service with minimal changes. The company used Azure Database Migration Service to migrate SQL Server databases to Azure SQL Database Managed Instance, leveraging the online migration mode to minimize downtime. Performance assessment showed that most databases had low CPU utilization, so they chose the General Purpose tier. The migration was completed in three months, and the company saw a 50% reduction in infrastructure management overhead. They used Azure DevOps for CI/CD and Azure Monitor for performance tracking.
Common Issues and Misconfigurations
Skipping dependency mapping: One enterprise migrated a critical CRM server without its dependent SQL Server database, causing the CRM to fail. They had to roll back and migrate both together.
Overprovisioning VMs: Using as-on-premises sizing for a server with 16 vCPUs but average 5% utilization led to high costs. They should have used performance-based sizing.
Ignoring network latency: A media company migrated a video rendering farm to Azure without using proximity placement groups, resulting in high latency between VMs. They later deployed VMs in the same availability set and used accelerated networking.
What AZ-305 Tests on This Topic (Objective 4.3)
The exam tests your ability to recommend appropriate migration strategies and tools based on business requirements. Key objective codes: 4.3.1 (Assess workloads for migration), 4.3.2 (Choose migration strategy), 4.3.3 (Plan migration waves). Questions are scenario-based, often presenting a company with specific constraints (e.g., minimal downtime, cost savings, lift-and-shift vs. modernization).
Common Wrong Answers and Why Candidates Choose Them
Choosing Azure Site Recovery for assessment: Candidates often confuse ASR (a migration/replication tool) with Azure Migrate (the assessment tool). ASR is for migration, not assessment. The correct tool for assessment is Azure Migrate.
Selecting as-on-premises sizing when performance data is available: Candidates may choose this because it's simpler, but the exam expects performance-based sizing for cost optimization. As-on-premises is only appropriate when performance data is unavailable or for compliance reasons.
Recommending rearchitect for all workloads: The exam tests cost-benefit analysis. Rearchitect is high effort and high reward, but not suitable for all workloads. Rehost is faster and cheaper for legacy apps that don't need modernization.
Ignoring dependency mapping: Many candidates forget to consider dependencies when planning migration waves. The exam will include scenarios where dependent servers must be migrated together.
Specific Numbers and Terms That Appear on the Exam
Default performance history: 1 month (can be set to 3 months).
Default percentile: 95th (can be 50th or 99th).
Default comfort factor: 1.2 (range 1.0 to 2.0).
Azure Migrate appliance: Supports VMware, Hyper-V, physical, and other clouds.
Dependency Agent: Required for dependency mapping; uses TCP connections every 5 minutes.
Data Migration Assistant (DMA): For database compatibility assessment.
App Service Migration Assistant: For .NET and PHP web apps.
Azure Site Recovery: For rehost migration (not assessment).
Azure Database Migration Service: Supports online (minimal downtime) and offline modes.
Migration waves: Wave 0 (pilot), Wave 1 (early adopters), etc.
Edge Cases and Exceptions
No performance data: If performance data is not available (e.g., new servers), use as-on-premises sizing.
Linux VMs: Azure Migrate supports Linux discovery and assessment. Some features like dependency mapping require agents.
Large data volumes: For datasets > 10 TB, consider Azure Data Box for offline transfer.
Government clouds: Azure Government has separate endpoints; Azure Migrate is available in those regions.
VMware vCenter version: Azure Migrate appliance requires vCenter Server 5.5, 6.0, 6.5, 6.7, or 7.0.
How to Eliminate Wrong Answers
If the question asks for assessment, eliminate any answer that mentions Azure Site Recovery or Azure Database Migration Service as the primary tool (those are for migration).
If the business requirement is to minimize downtime, choose online migration mode for databases (Azure DMS online) or Azure Site Recovery for VMs.
If the requirement is to minimize cost, look for performance-based sizing, Azure Hybrid Benefit, and reserved instances.
If the requirement is to modernize, consider refactor or rearchitect. If the requirement is to move quickly, choose rehost.
Azure Migrate is the primary tool for workload assessment and discovery.
Performance-based sizing uses historical data (default 1 month) and 95th percentile utilization with a comfort factor of 1.2.
The 5 Rs of migration: Rehost, Refactor, Rearchitect, Rebuild, Retire.
Dependency mapping is essential to avoid migration failures; use Dependency Agent for accurate maps.
Azure Site Recovery is for rehost migration, not assessment.
Azure Database Migration Service supports online (minimal downtime) and offline database migrations.
Migration waves: start with a pilot (Wave 0) to validate the process.
Azure Hybrid Benefit saves on Windows Server and SQL Server licenses if you have Software Assurance.
For large data transfers (>10 TB), use Azure Data Box for offline transfer.
Always perform a test migration before final cutover to validate functionality.
These come up on the exam all the time. Here's how to tell them apart.
Agentless Discovery
No agents installed on VMs.
Uses hypervisor APIs (vCenter, Hyper-V) to collect metadata.
Collects performance data every 20 seconds.
Supported for VMware and Hyper-V only.
Limited dependency mapping (requires separate agents).
Agent-Based Discovery
Requires installation of Azure Monitor Agent and/or Dependency Agent on each VM.
Collects deep data including running processes and network connections.
Collects performance data every 5 minutes.
Supported for physical servers, VMware, Hyper-V, and other clouds.
Full dependency mapping with visual maps of TCP connections.
Mistake
Azure Site Recovery is used for workload assessment.
Correct
Azure Site Recovery is a disaster recovery and migration tool, not an assessment tool. Assessment is done using Azure Migrate, which discovers and evaluates on-premises workloads.
Mistake
As-on-premises sizing is always more accurate than performance-based sizing.
Correct
Performance-based sizing uses actual utilization data (CPU, memory, disk IOPS) to right-size VMs, often leading to lower costs. As-on-premises sizing simply mirrors the on-premises configuration, which may be overprovisioned.
Mistake
Dependency mapping is optional and not needed for most migrations.
Correct
Dependency mapping is critical to identify inter-server dependencies. Without it, you risk migrating a server without its dependencies, causing application failures. It should be used for all but the simplest environments.
Mistake
You must use agent-based discovery for all VMware VMs.
Correct
Azure Migrate supports agentless discovery for VMware and Hyper-V VMs. Agent-based discovery is required only for physical servers, other clouds, or when you need deep dependency mapping.
Mistake
The comfort factor is always set to 1.0.
Correct
The default comfort factor is 1.2 (20% buffer). It can be configured between 1.0 and 2.0. A higher comfort factor increases the size of the Azure VM to ensure performance but also increases cost.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Azure Migrate is a discovery and assessment tool that helps you evaluate on-premises workloads for migration to Azure. It provides readiness, cost, and dependency analysis. Azure Site Recovery is a disaster recovery and migration tool that orchestrates replication and failover of VMs. For assessment, use Azure Migrate. For actual migration (rehost), you can use Azure Site Recovery or Azure Migrate Server Migration.
Use performance-based sizing when you have historical performance data (CPU, memory, disk IOPS) for at least a month. This typically results in more cost-effective sizing because it reflects actual usage. Use as-on-premises sizing when performance data is unavailable (e.g., new servers) or when you need to guarantee the same capacity as on-premises for compliance reasons.
The default comfort factor is 1.2, meaning Azure Migrate adds a 20% buffer to the performance data when sizing Azure VMs. For example, if the 95th percentile CPU utilization is 40%, the effective utilization used for sizing is 48%. This ensures the Azure VM can handle occasional spikes. You can set it between 1.0 (no buffer) and 2.0 (100% buffer).
It depends on the discovery method. For agentless discovery (VMware, Hyper-V), no agents are needed; the Azure Migrate appliance uses hypervisor APIs. For agent-based discovery (physical servers, other clouds, or deep dependency mapping), you need to install the Azure Monitor Agent and/or Dependency Agent on each VM.
Migration waves group servers into phases to manage risk and complexity. Wave 0 (pilot) includes a few low-risk servers to test the migration process. Subsequent waves migrate larger groups. Each wave includes test migration to validate functionality. This approach minimizes downtime and allows issues to be resolved before moving critical workloads.
Azure Hybrid Benefit allows you to use your on-premises Windows Server and SQL Server licenses with Software Assurance to pay a reduced rate on Azure VMs and Azure SQL databases. During migration assessment, Azure Migrate can estimate savings. You need to enable the benefit when provisioning Azure resources.
Online migration uses continuous data replication to minimize downtime; the source database remains operational during migration. Offline migration takes the source database offline, copies the data, and then brings the target online. Online is preferred for production systems requiring minimal downtime, while offline is simpler and faster for non-critical systems.
You've just covered Workload Assessment and Migration Analysis — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?