Azure Migrate: Agentless or Agent-Based? What You Actually Need to Know
- Shannon
- 4 minutes ago
- 3 min read
What's interesting is there are still customers I work with who are considering a full blown datacenter migration to cloud. This is why I've loved my job at AHEAD because I'm back in the mix of actually solving unique challenges for customers and migrating to the cloud is still one of the most compelling challenges customers face. Given I seem to work a lot with Azure based customers, I figured it might be good to put together the current pre-requisites and considerations for running Azure Migrate. Turns out even my knowledge was a bit outdated from the current proverbial "rules of the road." Getting started with Azure Migrate may feel overwhelming. I know I get asked these questions a lot, so let's outline them here:
Do I need agents?
Can I do everything agentless?
What happens if I want to move SQL Servers?
Is discovery enough, or do I need dependency mapping too?
I wanted break it all down in an easy to consume way so you know exactly what to use, when, and why.
What is Azure Migrate?
Azure Migrate is Microsoft’s centralized platform for assessing and migrating workloads into Azure. As a tool, it handles everything from discovery and assessment to dependency mapping and the actual move itself.
Before you start, you’ll need to deploy an Azure Migrate appliance in your environment. That appliance becomes your hub for discovery, assessments, and even migrations, without needing to install agents in most cases.
When Agentless is Enough
Agentless is great when you want fast insights with low friction. If you're working in VMware or Hyper-V environments, you can do quite a bit without installing anything inside your servers. Many of my customers love this aspect, as getting agent installations tackled almost takes a proverbial act of God.
Supported agentless activities:
Task | Agentless Support |
Discovery and inventory | Yes |
Performance-based assessment | Yes |
SQL Server instance discovery | Yes |
Basic dependency mapping | Yes |
Agentless migration (VMware only) | Yes |
Use agentless when:
You are using VMware or Hyper-V.
You want to avoid installing software inside each server.
You need a quick way to understand what you have and how it’s performing.
You want to migrate VMware VMs without agents.
When You Need Agents
Agent-based migration and discovery is required when your use case or source environment falls outside what agentless can do.
Common agent-required scenarios:
Scenario | Why Agents Are Needed |
Physical servers or non-VMware cloud (AWS, GCP) | Appliance cannot connect directly to these |
Hyper-V migration | No agentless option for Hyper-V migration |
Deep dependency mapping (process-level) | Requires the Dependency Agent inside the VM |
Migration with custom policies or non-supported guest OS | Only possible with the Mobility agent |
What About SQL Server Discovery?
Note, you do not need an agent to discover SQL Server instances. Azure Migrate uses the appliance to connect over WMI and PowerShell (for Windows) and can gather:
SQL Server version and edition
Installed features
Configuration settings
As long as you provide valid Windows admin credentials and allow WMI/PowerShell traffic, no extra agent is required.
Summary: Agentless vs Agent-Based
Task | Agentless | Agent-Based | Notes |
VMware discovery and assessment | Yes | Optional | Use appliance and credentials |
Hyper-V discovery | Yes | Optional | Migration requires agents |
Physical/AWS/GCP | No | Yes | Agent required inside the server |
SQL Server discovery | Yes | No | Uses remote WMI and PowerShell |
Dependency mapping (network-level) | Yes | No | Uses netstat and remote access |
Dependency mapping (process-level) | No | Yes | Requires Dependency agent |
Migration (VMware) | Yes | Optional | Agentless works unless you need advanced features |
Migration (Hyper-V, physical, AWS, GCP) | No | Yes | Agent is required |
Final Thoughts
If you're in a VMware or Hyper-V environment, start with agentless. It gives you a low-effort way to discover, assess, and even migrate many workloads. For everything else (like physical servers or cloud-to-cloud migrations) agents are still your best bet.
Use Shannon's rule of thumb:
Do you want fast insights and zero server installs? Go agentless.
Do you need custom migrations, deeper telemetry, or non-VMware sources? Use agents.
Still not sure which mode is best for your scenario? Drop me a comment on this blog and I'll do my best to continue to assist related to overall understanding as you prepare for a cloud migration.