What Is Azure Migrate? How It Works, What It Costs, and When to Use It

• Last updated: 12 November 2026
• Azure
• Written by Editorial Team

Most Azure migrations do not go wrong at cutover. They go wrong months earlier, when someone sizes the target environment from a spreadsheet, a guess, or the specifications of a server bought years ago for a workload that has since changed. Azure Migrate exists to replace that guesswork with data.

Azure Migrate is Microsoft’s free hub for discovering, assessing and migrating servers, databases, web apps and virtual desktops to Azure. It watches how your machines actually behave, tells you whether they are ready for Azure and what they would cost, and then moves them with replication, test migrations and a controlled cutover.

This guide explains what Azure Migrate is, how the appliance and assessments work, the two migration methods, what it costs, how it differs from Azure Site Recovery, and where it falls short. If you are new to the platform itself, start with our primer on what Azure is and how it works.

Key Takeaways

In this guide:

• What is Azure Migrate?
• The Azure Migrate workflow
• Discovery and the appliance
• Assessments, sizing and the business case
• Migration: agentless, agent-based, test and cutover
• Databases, web apps, desktops and offline data
• How much Azure Migrate costs
• Azure Migrate vs Azure Site Recovery
• The Azure Copilot migration agent
• Common mistakes
• When Azure Migrate is not the right tool
• A practical migration plan
• How Apps4Rent helps
• Frequently asked questions

What Is Azure Migrate?

Azure Migrate provides a central place to track the discovery, assessment and migration of your on-premises applications and workloads, and of VMs running in other private and public clouds. It supports VMware VMs, Hyper-V VMs, physical servers, other virtualized servers, databases, web apps and virtual desktops. The important word is hub. Azure Migrate is not one program. It bundles its own tools with Microsoft tools for specific workloads and with optional third-party tools, so one project can track a whole estate even when different workloads move in different ways.

Tool	What it does	Use it for
Discovery and assessment	Inventories servers and the workloads on them, then assesses readiness, size and cost	Planning every migration
Migration and modernization	Replicates servers to Azure and runs test migrations and cutover. Older documentation calls it Server Migration	VMware, Hyper-V, physical servers and VMs from other clouds
Data Migration Assistant	Assesses SQL Server databases for Azure SQL targets	Database readiness checks
Azure Database Migration Service	Moves databases to Azure SQL Database, SQL Managed Instance or SQL Server on Azure VMs	Database cutovers
App Service Migration Assistant	Assesses and migrates .NET and PHP web apps to Azure App Service	Web apps
Azure Data Box	Moves large amounts of data offline	Bulk data where bandwidth is limited

The two Azure Migrate tools you will use most are discovery and assessment, which answers “what do we have and what will it cost,” and migration and modernization, which does the moving. Everything else in the table is a specialist you call in for a particular workload.

The Azure Migrate Workflow

A migration with Azure Migrate follows four steps, and the order matters because each one feeds the next.

You discover what you have, assess it against Azure, migrate it in planned waves, and then optimize once it has landed. Teams that skip straight to step three are the ones who discover dependencies at cutover and oversized servers on the first invoice. Before any of it starts, it helps to have a foundation to land in, meaning the networking, identity and policy structure that migrated servers will sit inside.

Step 1: Discovery and the Azure Migrate Appliance

Discovery is done by the Azure Migrate appliance, a lightweight virtual machine you deploy in your own environment. It connects to your VMware vCenter, Hyper-V hosts or physical servers, performs agentless discovery, and sends metadata and performance data to your Azure Migrate project. Nothing is installed inside the servers being inspected. When you register the appliance, the resource providers it needs are registered on the subscription you choose.

The appliance does more than list machines. It can also discover the workloads running on them, including SQL Server instances and databases, ASP.NET web apps, and MySQL, PostgreSQL and MongoDB instances, which is what lets assessments cover databases and web apps and not just virtual machines. The appliance is the most common route, but it is not the only one.

Discovery method	Needs a connection to Azure	Performance-based sizing	Can run the migration	Best for
Appliance	Yes	Yes	Yes	Most projects
Collector	No, discovery is offline	Yes	No	Environments not yet connected to Azure
Import (CSV or RVTools)	Not applicable	No	No	A quick estimate from an inventory you already have

The collector suits environments that are not yet connected to Azure, because it gathers inventory offline. Importing an inventory from a CSV file or an RVTools export is the fastest way to get a rough view, but without performance data it cannot support performance-based sizing. Discovery based on Azure Arc is also available in preview.

Before deployment day, line up the basics: an Azure subscription where you can create resources, capacity to host the appliance, read access to your virtualization platform, and network paths from the appliance to Azure and to the servers it will inspect. Two practical points then save weeks. First, check those network paths and permissions in advance, because appliance setup has real prerequisites and they are the most common source of delay. Second, let the appliance collect data long enough to cover your real peaks, such as month-end or quarter-end processing. Sizing recommendations are only as good as the usage history behind them.

Step 2: Assessments, Sizing and the Business Case

An assessment evaluates your discovered workloads for migration to a specific Azure target. The main assessment types are:

• Azure VM: servers hosted on-premises or in other clouds, assessed for Azure virtual machines
• Azure SQL: SQL Server instances, assessed for Azure SQL Database, SQL Managed Instance or SQL Server on Azure VMs
• Azure App Service: web apps, assessed for App Service, Azure Spring Apps or Azure Kubernetes Service
• Azure VMware Solution: VMware servers, assessed for running on that service

Every assessment answers three questions: whether each workload is ready for Azure, what size it should be, and what it will cost per month once it is there. On sizing, you choose between two approaches. As-is sizing mirrors the server’s current configuration. Performance-based sizing recommends a size from the CPU and memory the server actually used, which often points to smaller, cheaper targets because most servers are bought for a peak they rarely reach. A comfort factor lets you add a buffer for seasonality.

Here is why sizing method matters, as an illustration. Take a server provisioned with 8 vCPUs that never needs more than 4 at its busiest. As-is sizing points to a D8s v5, which lists at $280.32 a month in East US. Performance-based sizing points to a D4s v5 at $140.16, a difference of $140.16 a month for that one server, or about $1,682 a year. Across 20 servers like it, that is about $2,803 a month. These are East US Linux list prices on 730 hours a month, and Windows adds licensing unless Hybrid Benefit applies.

Assessments also let you model how you will pay. Pricing options such as reservations and Azure Hybrid Benefit change the estimate, and for Windows and SQL Server estates the difference is large, so it is worth reading how Hybrid Benefit eligibility works before you build the assessment. The assessment also tells you which workloads suit which treatment. Our guide to deciding whether to rehost, refactor or retire each workload covers that decision.

Dependency analysis

Servers rarely work alone. Dependency analysis shows which machines talk to which, so you can migrate connected systems together instead of splitting an application across two locations and watching latency break it. The agentless option is the usual choice, and it gathers data by polling, so very short-lived connections can be missed. Agent-based dependency analysis is also available, but since July 2024 it incurs standard Log Analytics charges, which is another reason Microsoft steers customers toward the agentless version.

The business case

A business case builds on your discovery data to compare what you spend today with what the same workloads would cost in Azure. It exists to remove guesswork from cost planning, and it gives a finance team something firmer than a rule of thumb. Treat it as an estimate that is only as good as the assumptions you set. It is not a quote, and it should be revisited as those assumptions change.

Step 3: Migration, Agentless, Agent-Based, Test and Cutover

The migration and modernization tool offers two ways to replicate servers to Azure, and the right one depends on where the server lives.

	Agentless	Agent-based
Works for	VMware and Hyper-V VMs	VMware, Hyper-V, physical servers, AWS, GCP and other platforms
What you deploy	The Azure Migrate appliance for VMware, or a replication provider for Hyper-V	A replication appliance, plus an agent on each server
How it replicates	Uses the hypervisor’s snapshot and change-tracking features	An agent inside each server sends changes to the replication appliance
Watch out for	Snapshots consume storage IOPS and bandwidth	More to install and maintain on each server

Agentless is simpler where it applies, because nothing has to be installed on each server. The appliance compresses and encrypts data before uploading it, and for VMware it can replicate VMs even while they are powered off. Agent-based is the answer for everything agentless cannot reach, and for environments where storage IOPS are already tight, since agentless replication leans on snapshots.

Whichever you choose, the sequence is the same:

• Group by dependency. Replication groups let you move servers that belong together at the same time.
• Replicate. Data is copied to Azure while the source keeps running.
• Run a test migration. Azure starts a copy of the replicated VM in an isolated network without touching production or interrupting replication, so you can check boot, connectivity and application behavior.
• Cut over. Schedule the final sync, switch users to the Azure copy and retire the source.

Two planning details are easy to miss. The target region is locked once replication starts, so choose it deliberately, and use separate Azure Migrate projects when you need more than one region. Eligible VMs also migrate as Trusted Launch VMs by default, which adds secure boot and a virtual TPM at no extra cost.

The source type decides the details. For the specifics, see our step-by-step guides to moving physical servers, moving VMware workloads and moving virtual machines out of AWS. If you manage migrations for several customers, migrating at scale across customer tenants explains how Azure Lighthouse fits.

Databases, Web Apps, Virtual Desktops and Offline Data

Servers are only part of most estates. For databases, the Data Migration Assistant assesses SQL Server readiness and Azure Database Migration Service performs the move, which we cover in our guide to moving databases. Web apps use the App Service Migration Assistant, which handles .NET and PHP sites, and VMware-hosted ASP.NET web apps can be migrated at scale to App Service. Virtual desktop environments can move too, and many organizations use the move to start delivering desktops to remote staff from Azure instead of from on-premises hardware. Where bandwidth is the constraint, Azure Data Box moves large data sets offline.

How Much Does Azure Migrate Cost?

The short answer is that the tooling is free and the project is not. Microsoft lists Azure Migrate and its tools at no additional charge, but a few items do bill, and the table below shows which.

Item	What you pay	Note
Azure Migrate hub, discovery and assessments	No additional charge	The appliance runs on capacity you already own
Server migration	Free for 180 days per machine, then $25 a month per replicated instance	Cut over inside the window and the fee never applies
Replication storage, transactions and data transfer	Standard Azure rates	Billed even during the free window
Test migration compute	Standard Azure compute rates	Short-lived if you shut the test copies down
Agent-based dependency analysis	Standard Log Analytics charges	The agentless option avoids this
Third-party tools	The vendor’s pricing	Optional, through the Azure Migrate hub

Pricing as listed on Microsoft’s Azure Migrate pricing page, checked November 2026. Terms can change, so confirm them before you plan around them.

The 180-day window deserves attention. It is generous for most projects, but a server left replicating for a full year would incur about six months of the monthly fee, roughly $150 for that one machine, so plan to cut over inside it. Replication storage, data transfer and test compute bill from day one, so shut test copies down when you finish with them.

The tooling cost is small next to the cost that matters, which is the target environment itself. Our guide to what the target VMs will cost has verified list prices across sizes, regions and disks. To price a design before you commit, use our free AI Azure calculator, and see an example estimate built from a plain description for what it produces. Then compare the assessment against the first full invoice after cutover. Real usage rarely matches the plan exactly.

Azure Migrate vs Azure Site Recovery

The two are often confused because they share replication technology. Azure Migrate supports the migration scenarios that Site Recovery supports and adds an agentless option for VMware VMs, and it wraps them in discovery, assessment and wave planning. Use Azure Migrate when the goal is to move a workload and be done. Azure Site Recovery is for the ongoing need: keeping workloads replicated so you can fail over when something breaks, which is the subject of recovering after an outage. Backup is a third, separate need, and how backup and Site Recovery fit together explains how the pieces divide the work.

The Azure Copilot Migration Agent

The newest addition to Azure Migrate is an AI layer. The Azure Copilot migration agent sits inside Azure Migrate, reached through its Accelerate migration experience, and works on top of your discovery data. It can build business cases and assessments, tag discovered servers, and generate deployable landing zone templates from plain-language prompts. It can also hand application code questions to GitHub Copilot’s modernization tools.

What it cannot do is run the migration. Replication, test migrations and cutover still happen in Azure Migrate itself, so treat the agent as a planning accelerator and not a replacement for the workflow above. It also needs the agents preview enabled in Azure Copilot, and Microsoft has changed the status of these features more than once, so check the current availability before you plan around them. A companion collector supports offline inventory for environments without direct Azure connectivity.

Common Mistakes

• Discovering for too short a time. A few days of data misses month-end peaks and leads to undersized targets.
• Treating the assessment as a quote. It is an estimate under your assumptions. Revisit it when those assumptions change.
• Migrating before the landing zone exists. Servers that land in an unstructured subscription are expensive to reorganize later.
• Ignoring dependencies. Moving one half of a connected application strands it across two environments.
• Skipping the test migration. Cutover is the wrong moment to learn a server does not boot in Azure.
• Lifting and shifting everything. Some workloads should be rebuilt, replaced or retired, and the assessment is where to find them.
• Forgetting licensing. Windows and SQL Server licenses you already own can lower the bill, but only if you apply Hybrid Benefit.
• Leaving migrated servers unprotected. Backup and recovery do not come with the move, so plan protecting migrated servers with cloud backup as part of the project.
• Choosing the target region by accident. It locks when replication starts, so decide before you begin.

When Azure Migrate Is Not the Right Tool

Azure Migrate is the right starting point for most server moves, but it is not the answer to every problem, and it is better to know where it stops.

• Software as a service and cloud-native apps. There is nothing to discover or replicate, so the work is configuration and data import, not migration.
• Data-only moves. Files and object storage move more simply with tools such as AzCopy, or with Azure Data Box when bandwidth is limited.
• Applications that need code changes first. An assessment will flag compatibility issues, but fixing them is development work, and the tool will not do it for you.
• Ongoing disaster recovery. That is an Azure Site Recovery job, covered above.
• Very small moves. If you are moving one or two servers, standing up an appliance and a project may cost more effort than moving them by hand.

A Practical Migration Plan

• Step 1: Decide what and why. Settle the goals, then finish the pre-migration steps worth completing first.
• Step 2: Build the landing zone. Networking, identity, policy and monitoring come before the first server.
• Step 3: Deploy the appliance and discover. Let it run across a full business cycle.
• Step 4: Assess and build the business case. Review readiness, sizes, dependencies and cost, and choose a treatment for each workload.
• Step 5: Pilot a wave. Pick a low-risk group, run a test migration and fix what it reveals.
• Step 6: Migrate in waves. Move by dependency group, validating each wave before the next.
• Step 7: Optimize and protect. Right-size, apply reservations and Hybrid Benefit, set up backup and recovery, and put monitoring in place.

How Apps4Rent Helps with Azure Migrations

Apps4Rent is a Microsoft Solutions Partner and Tier-1 Cloud Solution Provider, SOC 2 Type II certified, serving over 10,000 businesses since 2003. We handle planning and running the move end to end: discovery and assessment, the landing zone, migration in planned waves with test migrations, and cutover. Afterward, our team handles running it after cutover, including backup, security, monitoring and cost control, with Microsoft-certified engineers available by phone, chat and email around the clock. If you want a second opinion before you commit, an independent assessment before you commit will pressure-test the plan, the sizes and the sequence.

Frequently Asked Questions

1. What is Azure Migrate?

   Azure Migrate is Microsoft’s central hub for discovering, assessing and migrating on-premises servers, databases, web apps and virtual desktops, as well as VMs from other clouds, to Azure. It includes tools for discovery and assessment, for server migration, and for specific workloads such as databases and web apps.

2. Is Azure Migrate free?

   Microsoft lists Azure Migrate and its tools at no additional charge. Server migration is free for the first 180 days per machine, after which Microsoft’s pricing page lists $25 a month per replicated instance. You still pay normal Azure rates for replication storage, transactions and data transfer, and for compute used in test migrations. Third-party tools may carry their own fees.

3. What is the Azure Migrate appliance?

   The Azure Migrate appliance is a lightweight virtual machine you deploy in your own environment. It performs agentless discovery of servers and the workloads on them, sends metadata and performance data to your Azure Migrate project, and, for VMware, can also run agentless migration.

4. What is the difference between agentless and agent-based migration?

   Agentless migration works for VMware and Hyper-V VMs and uses the virtualization platform’s own snapshot and change-tracking features, so nothing is installed inside the VMs. Agent-based migration uses a replication appliance and an agent on each server, and it also covers physical servers and VMs from AWS, GCP and other platforms.

5. What can Azure Migrate migrate?

   Azure Migrate supports VMware VMs, Hyper-V VMs, physical servers, other virtualized servers and VMs running in other clouds, as well as databases, web apps and virtual desktops. Databases, web apps and bulk data use companion tools such as Azure Database Migration Service, the App Service Migration Assistant and Azure Data Box.

6. How is Azure Migrate different from Azure Site Recovery?

   Azure Migrate is built for one-time migrations and supports the migration scenarios that Site Recovery supports, plus an agentless option for VMware VMs. Azure Site Recovery is a disaster recovery service for keeping workloads replicated and ready to fail over, which is an ongoing need rather than a move.

7. How accurate are Azure Migrate cost estimates?

   They are estimates built on the data you collect and the assumptions you set, not quotes. Performance-based sizing is only as good as the usage history the appliance gathered, so let discovery run across a full business cycle, and revisit the assessment as assumptions such as reservations or Hybrid Benefit change.

8. Can Azure Migrate help with databases and web apps?

   Yes. Discovery can find SQL Server, MySQL, PostgreSQL and MongoDB instances and ASP.NET web apps, and assessments cover Azure SQL targets and web app targets such as App Service and Azure Kubernetes Service. The actual database and web app moves use companion tools such as Azure Database Migration Service and the App Service Migration Assistant.

9. What is the Azure Copilot migration agent?

   It is an AI agent inside Azure Migrate, reached through the Accelerate migration experience, that helps plan migrations from VMware, Hyper-V and physical servers. It can build business cases and assessments, tag discovered servers and draft landing zone templates, but it does not perform the migration itself. Availability depends on enabling Azure Copilot’s agents preview, so check Microsoft’s current status.

10. Can Apps4Rent help us plan and run an Azure migration?

    Yes. Apps4Rent is a Microsoft Solutions Partner and Tier-1 Cloud Solution Provider. We run discovery and assessment, build the landing zone, migrate in planned waves with test migrations, and manage the environment afterward, with Microsoft-certified engineers available 24/7 by phone, chat and email.