Azure Migrate: Fix Setup, Assessment & Migration Errors
Why This Is Happening
You've decided to move your on-premises infrastructure to Azure. You've heard Azure Migrate is the right tool , a single hub that handles discovery, assessment, and the actual migration of servers, databases, web apps, and virtual desktops. You set up the project, deploy the appliance, and then… something breaks. The appliance won't connect. The assessment keeps failing. The dependency map shows nothing. Or worse, migration finishes but your VMs land in Azure with zero network connectivity.
I've seen this exact scenario on dozens of enterprise projects. The frustration is real , especially when your business case is already signed off and the clock is ticking on your datacenter contract.
Here's the honest truth: Azure Migrate is genuinely powerful, but it has several moving parts that need to align perfectly. The Azure Migrate appliance, a lightweight virtual machine you deploy in your own datacenter, has to talk to both your on-premises environment and Azure endpoints simultaneously. That means firewall rules, proxy settings, DNS resolution, and Azure account permissions all have to be correct at the same time. One misconfigured rule and the whole pipeline stalls.
The most common root causes I run into are:
- Insufficient Azure role assignments, The Azure account running the project doesn't have the right built-in roles to create projects, run discovery, or execute migrations. Microsoft is explicit about this: specific built-in roles are required at each phase of the migration journey.
- Appliance registration failures, The appliance can't reach Azure endpoints because of outbound firewall blocks or TLS inspection stripping certificates.
- Assessment errors tied to stale performance data, The appliance hasn't collected enough performance history yet, so right-sizing recommendations come back wildly off.
- Agent installation failures on Hyper-V hosts, Provider agents for Hyper-V migration require specific Windows versions and can silently fail on non-English OS locales.
- Replication appliance misconfigurations, For physical server and agent-based VMware migrations, the replication appliance setup has its own set of port and account requirements separate from the discovery appliance.
Microsoft's error messages in the Azure portal are notoriously vague at the point of failure. You get a spinner, then a red "X", then a message that says something like "Discovery failed, check appliance connectivity." That's it. No error code. No log path. It tells you what failed but never why.
This guide walks through every layer, from Azure account permissions down to network-level appliance connectivity, so you can get your Azure Migrate project running correctly and finish your migration with minimal downtime and risk.
The Quick Fix, Try This First
Before you spend an hour digging through logs, run this fast permission audit. The single most common reason Azure Migrate projects fail, especially when you're seeing errors on project creation or when discovery silently stops, is that the account running the operation is missing the right Azure built-in role assignments.
Open the Azure portal and navigate to Subscriptions → [Your Subscription] → Access control (IAM) → Role assignments. Find the account you're using for Azure Migrate and verify it has at least Contributor role on the subscription, or a combination of Owner on the resource group you're using for the project.
If you're running discovery and assessment only, Contributor at the resource group level is usually sufficient. But if you're executing the actual migration, moving VMs, replicating disks, you need permissions to create resources like storage accounts, managed disks, and network interfaces in the target resource group. Microsoft's official documentation is clear: there are specific built-in roles required at each phase. Don't assume that a developer or reader role will get the job done.
Once you've confirmed roles, go to your Azure Migrate project in the portal: Azure Migrate → Servers, databases and web apps → [Your Project]. Click Refresh on the discovery status tile. If the appliance was registered correctly and only the permission was blocking assessment creation, this will often immediately resume the pipeline.
If the status still shows an error, check that your appliance VM can reach the following endpoint over port 443:
*.portal.azure.com
*.blob.core.windows.net
*.servicebus.windows.net
*.vault.azure.net
management.azure.comA quick PowerShell test from inside the appliance VM confirms this:
Test-NetConnection -ComputerName management.azure.com -Port 443If TcpTestSucceeded comes back False, your outbound firewall is the problem, not the Azure Migrate configuration itself.
https://[appliance-name]:44368) and let it complete the prerequisite checks before you attempt registration. Skipping past the green checkmarks on proxy and connectivity, even if things look fine, almost always causes a silent registration failure that only surfaces 30 minutes later when discovery never starts.
This is step zero for every Azure Migrate problem I troubleshoot. Open the Azure portal and go to Subscriptions → Access control (IAM). Click Check access, search for the account or service principal running your migration, and confirm which roles are assigned.
Microsoft requires specific built-in roles depending on what you're doing. For project creation and running discovery and assessments, you need at minimum Contributor on the target resource group. For executing actual migrations, replicating VMware VMs, migrating Hyper-V VMs, or migrating physical servers, you'll additionally need permissions to write storage accounts and managed disks in the target subscription.
If you're in a large enterprise environment, it's common for an IT admin to create the Azure Migrate project but then hand off migration execution to a different team account, and that second account may have had its role scoped too narrowly. Check both the account that created the project and any accounts tied to the appliance registration.
To assign the correct role in the portal: Subscriptions → [Your Subscription] → Access control (IAM) → + Add → Add role assignment → Contributor → [Select your account] → Review + assign.
After saving the role assignment, allow up to 5 minutes for Azure RBAC propagation. Then go back to your Azure Migrate project and retry the operation that was failing. If you're on a tightly scoped service principal, you may need your Azure AD admin to grant the change, in that case, open a ticket with them rather than guessing at permissions.
Once the role check passes, you should be able to create an assessment or start a discovery run without the portal returning a generic authorization error.
If your Azure Migrate discovery has been "in progress" for more than 2 hours or shows a stale "last heartbeat" timestamp, the appliance registration is likely broken. This happens most often after a network change, proxy reconfiguration, or a Windows update on the appliance VM that rotated certificates.
Log into the appliance VM directly (RDP works fine) and open the Appliance Configuration Manager at:
https://[appliance-hostname]:44368On the dashboard, look at the Azure Migrate service connectivity section. A red or yellow status there tells you the appliance can't reach Azure. Before you re-register, fix connectivity first, re-registration over a broken connection will just fail again.
If connectivity shows green but discovery is still stuck, scroll to Step 3: Register with Azure Migrate on the same page and click Re-register. You'll be asked to authenticate with the Azure account that has Contributor permissions on the project. Use device code authentication if your appliance doesn't have a browser, the manager will give you a code to enter at microsoft.com/devicelogin from any machine.
After successful re-registration, the service will push a new set of credentials to the appliance. Go back to your Azure Migrate project in the portal, navigate to Servers, databases and web apps → Discovery, and click Refresh. Within 15–30 minutes you should see discovery counts start populating.
If re-registration fails with an error mentioning "KeyVault," that's a sign the appliance can't reach *.vault.azure.net, add that to your firewall allowlist and retry.
Azure Migrate assessment errors frustrate me more than most because they often show up late, you've waited days for discovery to complete, you finally kick off an assessment, and it comes back with wildly unrealistic VM sizes or a "not ready" status on servers that are clearly fine.
The most common cause: the appliance hasn't collected enough performance data. Azure Migrate assessments use collected CPU, memory, and disk performance data to right-size Azure VM recommendations. If the appliance was just deployed, it may only have a few hours of data, not the 1-day, 7-day, or 30-day window you selected in the assessment settings.
To check: in the Azure portal, go to Azure Migrate → Servers → Assessments → [Your Assessment] → Assessment properties and look at the Performance history setting. If you selected 30 days but the appliance has only been running for 2 days, every VM will be either over-provisioned (using peak values) or flagged as "not ready."
Fix this by editing the assessment: click Edit properties, change Performance history to 1 day or As on-premises for now, then click Recalculate. The "as on-premises" option skips performance-based sizing entirely and just mirrors your current server specs, useful when you need a quick migration plan and can right-size later in Azure.
For a production assessment you'll want to run the appliance for at least 7 days before generating your final migration plan. Mark a calendar reminder and come back to it, the quality of your business case depends on accurate utilization data.
For Hyper-V migrations, Azure Migrate doesn't use the same appliance approach as VMware. Instead, it installs provider agents directly on your Hyper-V host servers. These agents handle the replication traffic from the host to Azure. When they fail to install or won't register, you're stuck before you can replicate a single VM.
The most common failure mode: the provider installer runs, shows "Setup complete," but then the agent never appears as registered in the Azure Migrate portal. To investigate, open Event Viewer on the Hyper-V host: Event Viewer → Applications and Services Logs → Microsoft → AzureSiteRecovery. Look for Event IDs in the 4000–4999 range, these are the Azure Site Recovery provider log events that the Hyper-V migration agent uses under the hood.
Common errors you'll find there:
Event ID 4048, Certificate validation failed
Event ID 4032, Service endpoint unreachable
Event ID 4071, Proxy authentication requiredFor Event ID 4048, the fix is almost always a corporate TLS inspection proxy that's re-signing Azure endpoint certificates. You need to either bypass TLS inspection for *.windowsazure.com and *.backup.windowsazure.com, or import your corporate CA certificate into the Hyper-V host's Trusted Root Certification Authorities store.
For Event ID 4071, configure proxy credentials in the provider: open Microsoft Azure Site Recovery Provider Setup from Control Panel, go to Proxy Settings, and enter your proxy credentials explicitly. The provider won't inherit Windows proxy credentials automatically.
After fixing the underlying issue, run the provider registration again from the portal: Azure Migrate → Servers → Replication → Discover machines → Are your machines virtualized? Yes, with Hyper-V, and follow the re-registration flow.
When you're migrating physical servers, or VMware VMs using agent-based migration, you need a separate replication appliance, distinct from the discovery appliance. This is a common point of confusion. The replication appliance runs a configuration server, a process server, and a mobility service agent on each source machine. If any of these three components can't communicate, replication stalls.
First, confirm the replication appliance's configuration server is healthy. In the Azure portal: Azure Migrate → Servers → Migration tools → Replication servers. The configuration server should show a green "Connected" status. If it's red or shows "Not connected," the replication appliance can't reach Azure, return to the appliance and run the same connectivity tests from Step 2 above.
For mobility service installation failures on the source servers, open PowerShell on the replication appliance and check the push-install log:
C:\ProgramData\ASRSetupLogs\ASRUnifiedAgentInstaller.logCommon errors here include:
- WMI access denied, The account used for push installation doesn't have local admin rights on the source server. Fix: add the account to the local Administrators group, or use an explicit domain admin account during setup.
- Firewall blocking port 135 or 445, Push installation uses WMI (135) and SMB (445). Add an inbound firewall rule on the source server:
netsh advfirewall firewall add rule name="AzureMigrate-WMI" protocol=TCP dir=in localport=135 action=allow
netsh advfirewall firewall add rule name="AzureMigrate-SMB" protocol=TCP dir=in localport=445 action=allowAfter mobility service installs successfully on the source machine, go back to Azure Migrate → Replication → Replicate and add the machine. Initial replication typically takes several hours depending on disk size, a 500 GB disk over a 100 Mbps link will take roughly 12 hours. Plan your cutover window accordingly.
Advanced Troubleshooting
If the step-by-step fixes above didn't resolve your Azure Migrate issue, you're likely dealing with something at the network, enterprise policy, or Azure service level. Let me walk through the deeper investigations I use when the obvious stuff has already been ruled out.
Azure Migrate Appliance Diagnostic Logs
The appliance writes detailed logs that the portal never surfaces. RDP into the appliance VM and look here:
C:\ProgramData\Microsoft Azure\Logs\AzMigrate_*.logThese logs include timestamped entries for every heartbeat, discovery cycle, and registration attempt. Grep (or use Notepad's Find) for ERROR or WARN strings. A line like ERROR HttpClientHandler: SSL certificate error for endpoint *.blob.core.windows.net tells you immediately that TLS inspection is interfering, even when your firewall team insists "nothing has changed."
Business Case and Cost Estimation Not Generating
After discovery completes, some users find that the Build business case option is greyed out or returns an error. This typically happens when discovered server count is below the threshold needed for the business case engine (usually at least 1 discovered server with 24+ hours of performance data). It can also occur when your Azure Migrate project was created in an unsupported region. Check that your project is in a supported Azure geography, not all regions support all Azure Migrate features at the same time as global rollouts happen.
Dependency Analysis Showing No Data
Azure Migrate dependency analysis has two modes: agentless (using the same appliance) and agent-based (using the Log Analytics MMA/AMA agent). Agentless dependency analysis works by capturing network connection data via the appliance, but it requires the appliance to have vCenter read permissions at the datacenter level for VMware environments, or Hyper-V host credentials with access to all VMs. If your vCenter permissions are scoped to a specific cluster only, VMs on other clusters won't appear in the dependency map at all. Fix this in vCenter by elevating the Azure Migrate vCenter account to Read-only at the datacenter root object, with propagation enabled.
ASP.NET Web App Assessment Failures
If you're assessing ASP.NET web apps for migration to Azure App Service, the appliance needs to be able to reach your IIS servers and collect web app metadata via WMI. A common enterprise blocker is that the IIS servers are in a different network segment from the appliance, with WMI (port 135 + dynamic RPC range) blocked between segments. Work with your network team to open the required ports, or consider the agentless discovery approach which uses existing vCenter/Hyper-V credentials rather than direct machine connections.
SQL Server Assessment Errors
SQL Server assessments can fail when the discovery account doesn't have VIEW SERVER STATE and SELECT permissions on SQL Server system databases. Run this on each SQL instance:
USE master;
GRANT VIEW SERVER STATE TO [azure_migrate_account];
GRANT SELECT ON sys.databases TO [azure_migrate_account];Then return to the Azure Migrate portal and trigger a new discovery cycle from the appliance manager.
If you've verified permissions, appliance connectivity, and agent health, and Azure Migrate is still failing with a 5xx error in the portal or the appliance shows a "registration failed" status even after re-registration, it's time to escalate. Open a support ticket at Microsoft Support and include: your Azure Migrate project resource ID, the appliance name, the exact error message text, and the AzMigrate_*.log file from the appliance. Without those four pieces of information, the first support response will just ask you for them anyway, save yourself a day by attaching them upfront.
Prevention & Best Practices
Getting Azure Migrate to work once is satisfying. Getting it to work reliably across a multi-wave migration program, where you're migrating hundreds of servers over several months, requires treating the tool like any other production system. Here's what separates smooth migration programs from the ones that get stuck in fire-fighting mode.
Prepare your Azure accounts before deploying the appliance. The most time-wasting pattern I see is teams deploying the appliance first and then scrambling to get permissions sorted afterward. Do it in reverse: set up your Azure Migrate project, assign the right roles to all relevant accounts, and validate endpoint connectivity from a test VM in the same network segment, before you even download the appliance OVA or VHD. This catches network and permission issues in a low-stakes environment.
Run the discovery appliance for a full 7 days before generating your official assessment. Azure Migrate uses performance history to generate right-sized VM recommendations. A 7-day baseline captures weekly workload patterns, things like end-of-week batch jobs, monthly report runs, and nightly backup peaks. Assessments generated from 24 hours of data are almost always inaccurate, leading to either over-provisioned VMs (wasted cloud spend) or under-provisioned VMs (performance issues post-migration).
Document your dependency map before planning migration waves. The dependency analysis feature in Azure Migrate is genuinely useful for identifying which servers need to be migrated together. Before you plan your migration waves, spend time in the dependency visualization, looking specifically for servers that have active connections to databases or middleware in other planned waves. Splitting an application across migration waves, where the app tier goes to Azure in Wave 1 but its database stays on-premises until Wave 2, causes latency spikes and can break connection string assumptions baked into older apps.
Test-migrate before the real cutover. Azure Migrate supports a Test migration feature that spins up replicated VMs in an isolated Azure VNet without impacting replication or the source machine. Use it. Every time. I've seen test migrations reveal missing firewall rules, broken DNS configurations, and licensing activation issues that would have been catastrophic during a live cutover window.
- Assign Azure Migrate roles and validate endpoint connectivity from the target network segment before deploying the appliance, saves hours of backtracking.
- Keep the appliance VM running continuously for at least 7 days before running performance-based assessments, data gaps cause inaccurate right-sizing.
- Run a test migration in an isolated Azure VNet at least 48 hours before your live cutover window, catches network and DNS issues early.
- Use the business case feature to build a year-over-year cost comparison before committing to migration scope, it helps justify the project to stakeholders and identify which workloads actually benefit from moving to Azure vs. those that are cheaper on-premises.
Frequently Asked Questions
What is Azure Migrate and what does it actually do?
Azure Migrate is a free Microsoft service that gives you a single hub for discovering, assessing, and migrating your on-premises workloads to Azure. It supports servers (VMware, Hyper-V, physical), databases (SQL Server), web apps (ASP.NET to Azure App Service), and large-scale offline data migration via Azure Data Box. The service itself is free, you only pay for the Azure resources you create as part of the migration. Think of it as a project management and tooling layer that sits on top of your migration, pulling together Microsoft's own tools and a marketplace of partner migration tools in one place.
What's new in Azure Migrate, are there recent features I should know about?
As of early 2026, Microsoft has added the Azure Copilot migration agent (currently in preview), which brings a planning-focused AI experience into the migration workflow. It helps you visualize workloads, estimate cost savings, and build high-fidelity migration plans through a conversational interface rather than manually clicking through assessment configuration. MySQL database migration assessment is also in preview, if you have MySQL workloads destined for Azure Database for MySQL, you can now assess them directly from the Azure Migrate hub. Azure Spring Apps assessment is another recent addition for teams running Java-based microservices. Check the "What's new in Azure Migrate" page in official documentation for the latest, since the feature cadence is fast.
How do I know if my on-premises servers are ready for migration to Azure?
Azure Migrate assessments generate an explicit "Azure readiness" status for each discovered server: Ready, Ready with conditions, Not ready, or Readiness unknown. To get accurate readiness data, deploy the Azure Migrate appliance in your datacenter, let it run discovery for at least 24 hours, then create a Server Assessment from the Azure Migrate hub. The assessment checks OS version support, boot type (BIOS vs. UEFI compatibility), disk count and size limits, network adapter compatibility, and whether the workload has any known migration blockers. "Ready with conditions" servers will still migrate, but you'll need to take action on the flagged item first, for example, installing the Azure VM agent before migration.
What's the difference between agentless and agent-based migration in Azure Migrate?
For VMware environments, agentless migration uses the same lightweight appliance you deployed for discovery, it reads VM data directly from vCenter and ESXi without installing anything on the source VMs. This is the recommended path for most VMware migrations because it's lower overhead and easier to set up. Agent-based migration, by contrast, installs a mobility service agent on each source VM and uses a separate replication appliance. Agent-based migration supports a wider range of source configurations, including physical servers, VMs on other clouds, and VMware VMs where agentless isn't supported, and gives you more granular control over replication. For Hyper-V migrations, there's no agentless option; provider agents are always installed on the Hyper-V host.
My Azure Migrate appliance shows "heartbeat not received", how do I fix it?
A missing heartbeat means the appliance VM has lost contact with the Azure Migrate service. Start by confirming the appliance VM is actually running (check Hyper-V Manager or vCenter). If it's running, RDP in and open the Appliance Configuration Manager at https://[appliance-name]:44368, check the Azure Migrate service connectivity status. If connectivity is red, test outbound access to management.azure.com on port 443 using Test-NetConnection -ComputerName management.azure.com -Port 443 in PowerShell. If the TCP test fails, work with your network team to open outbound 443 to the required Azure endpoints. If connectivity shows green but heartbeat is still missing, try re-registering the appliance from Step 3 of the Configuration Manager, this forces a fresh credential exchange with the Azure Migrate service.
Does Azure Migrate cost money to use?
The Azure Migrate service itself, including discovery, assessment, and business case generation, is completely free. You don't pay for running the appliance or generating assessments, no matter how many servers you discover. What you do pay for: Azure resources created during migration (storage accounts for replication data, managed disks, compute for test VMs) and any partner migration tools you add from the Azure Migrate hub marketplace. Partner tools have their own licensing and pricing, always check before adding one to your project. After migration, you pay standard Azure compute and storage pricing for your migrated workloads. The business case feature in Azure Migrate is specifically designed to help you estimate those post-migration costs before you commit.