Azure Migrate Dependency Analysis: Group Servers Before You Move

To decide which on-premises servers have to move in the same wave, use Azure Migrate dependency analysis to capture the real TCP connections between them, then group the servers that talk to each other so no live dependency is left stranded on the other side of the network. The current recommended method is agentless: it reads TCP connection data through the Azure Migrate appliance with no software installed on the guest, and it is generally available for VMware, Hyper-V, physical servers, and machines already running in AWS or GCP.

This article is about one narrow decision: how to build trustworthy move groups from dependency data before you schedule a wave. It is not a tour of the whole migration. If you get the grouping wrong, you find out at cutover, when an app server in Azure is still reaching back to a database that is now unreachable or slow across the link.

What Azure Migrate dependency analysis actually captures

Agentless dependency analysis works at the network layer. <cite index="7-3,7-4">Agentless dependency analysis works by capturing TCP network connection data from servers for which it's enabled, with no agents installed on the servers you want to analyze.</cite> <cite index="7-5">Connections between the source server and process, and the destination server, process, and port are grouped logically into a dependency.</cite>

The collection cadence matters when you plan how long to leave it running. <cite index="7-7,7-8">After discovery of dependency data begins, the Azure Migrate appliance polls TCP connection data from servers every five minutes to gather data.</cite> <cite index="7-9">The gathered data is processed on the Azure Migrate appliance and is sent to Azure Migrate every six hours.</cite>

Because the data is a periodic snapshot of active connections, a dependency that only fires at month-end, or a nightly batch job, will not appear unless the analysis is running while that traffic happens. Microsoft's own guidance is not to trust an afternoon of data. <cite index="8-8">Microsoft recommends waiting at least 24 hours to allow enough dependency data to be gathered for your servers to show in a visualization.</cite> For anything with a weekly or monthly cycle, leave it running across that cycle before you freeze your groups.

What you get out is a map or an export. <cite index="7-6">You can visualize captured dependency data in a map view, or export it as a CSV.</cite> The map is fine for eyeballing a handful of servers. For a real estate of hundreds, work from the CSV so you can pivot, diff, and attach the evidence to your wave plan.

Agentless or agent-based: which to use now

There are two implementations, and the choice is largely made for you by where Microsoft is heading. <cite index="6-0,6-1,6-2">Azure Migrate supports two approaches for dependency analysis: agentless and agent-based. Agentless gathers TCP connection data from servers without installing any agents on the guest operating systems, and the dependencies can be visualized at the project level across all servers or at the individual server level.</cite>

The agent-based path is heavier and on the way out. <cite index="6-3">Agent-based dependency analysis requires the installation of the Azure Monitor Agent and the Dependency agent on each guest server to gather dependency data, which is then visualized in a Log Analytics workspace associated with the Azure Migrate project.</cite> Two constraints make it a poor default for new work. <cite index="7-11,7-12,7-13">Agent-based dependency analysis is supported only in the classic view and isn't available in the new experience, and the classic view is scheduled for deprecation by the end of 2026.</cite> <cite index="7-14">Until then you can continue to access existing Log Analytics workspaces, but you can't onboard new servers for agent-based dependency analysis.</cite>

The visualization limits differ in a way that bites at scale. <cite index="9-0">With agent-based dependency analysis you can visualize dependencies for groups with up to 10 VMs, and for larger groups you have to split the VMs into smaller groups.</cite> Agentless removes that ceiling and gives you a longer window: <cite index="9-1">with agentless dependency analysis you can visualize dependencies in a multi-server visualization or export them to CSV for a duration of up to 30 days.</cite>

On the last row: <cite index="6-4,6-5">agent-based dependency analysis isn't available in Azure Government, and it is currently supported only in the classic Azure Migrate experience.</cite> Unless you are extending an existing agent-based deployment you already run, use agentless. The rest of this article assumes it.

What to check before you turn anything on

Dependency analysis is not free of prerequisites just because it installs nothing. The appliance still authenticates into each guest to read connection data, so credentials and permissions are the first thing to get right, not the last.

Credentials and guest permissions

You provide server credentials to the appliance, and they are per operating system family. <cite index="8-2">For Windows servers you need to provide a domain or nondomain local account with administrative permissions.</cite> Linux is more granular. <cite index="8-3">For Linux servers, provide a sudo user account with permissions to execute ls and netstat, or create a user account that has the CAP_DAC_READ_SEARCH and CAP_SYS_PTRACE permissions on the /bin/netstat and /bin/ls files.</cite> If you use sudo, do not skip the password flag. <cite index="8-4">Ensure NOPASSWD is enabled for the account so commands can run without prompting for a password each time.</cite>

If you prefer a least-privilege account over broad sudo, set the capabilities directly on the binaries:

# grant the dependency reader account the exact capabilities it needs
sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/ls
sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/netstat

You can sanity-check what the appliance will run, using the same commands it issues:

# what the appliance reads on a Linux guest
ps -o pid,cmd | grep -v ]$
netstat -atnp | awk '{print $4,$5,$7}'

Network path from appliance to source

For VMware, the appliance does not talk to the guest directly for this data; it pulls the output file through the ESXi host. That gives you a specific port to verify. <cite index="10-3">Port 443 is required to be open on ESXi hosts so the appliance can pull dependency data, and you can test TCP connectivity to the ESXi host from the appliance.</cite>

Test-NetConnection -ComputerName <ESXi-host-IP> -Port 443

If that fails, you will see servers stuck without dependency data and waste a day wondering why the map is empty. Fix the path before you start the clock on your 24-hour or 30-day collection window. Getting the appliance placement and network reachability right up front is exactly the kind of unglamorous groundwork our cloud migration engineers sort out before a discovery run so the assessment data is trustworthy the first time.

Know the appliance scale limit

Auto-enablement is not unlimited. <cite index="8-0">Dependency analysis couldn't be enabled where Azure Migrate reached its limit of 1,000 servers per appliance for automatic enablement.</cite> <cite index="6-6">In the new capability, dependency analysis automatically runs on up to 1,000 servers discovered by each Azure Migrate appliance that passes the prerequisite checks, so you don't enable it manually anymore.</cite> If you have a larger estate, plan multiple appliances, or disable analysis on servers you do not care about and target the ones you do using the PowerShell module.

Turning the map into move groups

The point of all this is a defensible answer to one question: what has to move together. Work from the exported CSV rather than the map once you are past a dozen servers.

Start from the systems you already know are a unit, an application and its database, and confirm the map agrees. Then look outward for the connections you did not expect: a monitoring agent reaching a collector, a domain controller, a licence server, a shared file server, an SFTP endpoint another team owns. Those cross-team edges are where migrations break, because nobody in the room owns both ends.

Be deliberate about noise. The new agentless experience trims connections it cannot fully resolve. <cite index="9-3,9-4">Unresolved connections between a discovered and an undiscovered server, or connections where application and process information could not be gathered from both ends, are omitted from the single-server and multi-server visualizations and from the exported CSV, to reduce noise.</cite> That is good for readability and a trap for planning: a dependency on a server outside your discovery scope, an on-prem appliance you are keeping, for example, simply will not show. Make sure your discovery scope covers everything a workload legitimately talks to, or reconcile the map against firewall logs and load balancer configs before you trust it.

Once groups are stable, they become your migration waves and, downstream, the shape of your target network. A group that chats constantly at low latency is a strong signal those servers belong in the same landing zone subnet or availability set, not split across regions. If you are still deciding how those target networks and subscriptions should look, that grouping feeds directly into landing zone and network design.

The trade-off, and what it costs later

Dependency analysis buys confidence, and it costs calendar time and honesty about its blind spots. The honest position: TCP connection sampling tells you what talked to what during the window you observed, at the granularity the tool could resolve. It does not tell you why, how often outside the window, or whether a connection is load-bearing or incidental.

Two failure modes follow from that. First, you cut the observation window short, miss a monthly job, and split a dependency across the migration boundary. The cost lands at cutover as timeouts and a rushed rollback. Second, you treat the map as complete, ignore the omitted unresolved connections, and discover an unmapped dependency in production. Both are cheaper to prevent than to debug live. Run the analysis across a full business cycle, reconcile against at least one independent source such as firewall or flow logs, and write down the dependencies you are choosing to sever on purpose. That short list, the deliberate cuts, is the most valuable artefact the exercise produces, and it is the one teams most often forget to create.

Frequently asked questions

How long should I run Azure Migrate dependency analysis before grouping servers?

Long enough to capture your slowest recurring dependency. <cite index="8-8">Microsoft recommends waiting at least 24 hours to gather enough dependency data to show in a visualization.</cite> Twenty-four hours covers daily traffic, but if you have weekly or month-end batch jobs, keep it running across that cycle. Agentless retains up to 30 days of data for visualization and export, so use that window rather than freezing groups after one afternoon.

Should I use agentless or agent-based dependency analysis?

Use agentless for any new work. <cite index="7-11,7-12">Agent-based analysis is supported only in the classic view and isn't available in the new experience, and that classic view is scheduled for deprecation by the end of 2026.</cite> Agentless also scales better, giving you multi-server maps instead of the ten-VM-per-group ceiling of the agent-based method, and it installs nothing on the guest. Only stay on agent-based if you already run it and need to finish an in-flight project.

Why are some servers missing from the dependency map?

The most common cause is a connection Azure Migrate could not fully resolve. <cite index="9-3,9-4">Unresolved connections, meaning a link to a server not discovered by Azure Migrate or a connection where application and process data could not be gathered from both ends, are omitted from the visualizations and the exported CSV.</cite> Widen your discovery scope so every dependency's far end is also discovered, and cross-check against firewall or flow logs. Also confirm credentials and, for VMware, port 443 reachability to the ESXi host, since a blocked path yields empty data.

Does agentless dependency analysis need any software on my servers?

No agent on the guest, but it does need credentials and permissions. <cite index="7-3,7-4">Agentless dependency analysis captures TCP connection data with no agents installed on the servers being analyzed.</cite> The Azure Migrate appliance authenticates into each server to read that data, so you supply a local administrator account on Windows and a sudo account, or an account with CAP_DAC_READ_SEARCH and CAP_SYS_PTRACE on ls and netstat, on Linux. The appliance itself must be deployed and registered first.