Azure Migrate Dependency Analysis: Map Before You Move
Title: Azure Migrate Dependency Analysis: Map Before You Move
Before you move a single server to Azure, run agentless dependency analysis in Azure Migrate for long enough to see a full business cycle, then build your migration groups from the actual TCP traffic rather than from a spreadsheet someone wrote two years ago. The dependency you cannot see is the one that breaks at cutover: a batch job that reaches back to an on-premises database, a licence server nobody documented, a monitoring agent that stops reporting. Azure Migrate captures those connections without touching your guests, and the cost of skipping this step is a rollback in the maintenance window.
This article covers how Azure Migrate dependency analysis works, what to check before you trust it, how to turn the map into migration waves, and the right-sizing decision that rides alongside it.
What Azure Migrate dependency analysis actually collects
Agentless dependency analysis works by capturing TCP connection data from the servers you have discovered, with no agent installed on the guest OS. The appliance polls each server every five minutes and sends a combined data point to Azure every six hours. For each connection it records the source server and process, the destination server, process and port, then groups those into a logical dependency you can view as a map or export to CSV.
How it reaches the guest depends on the source. For VMware, the appliance connects through vCenter Server using the VMware APIs; for Hyper-V VMs and physical servers it connects directly, using PowerShell remoting on port 5985 (HTTP) for Windows and SSH on port 22 for Linux. That matters for two reasons: the appliance needs network reachability to those ports, and it needs credentials with enough privilege to read process and connection tables.
The Microsoft-hosted experience changed recently, so check what you are looking at. The new agentless dependency experience was released on 30 September 2025, and in it dependency analysis runs automatically on up to 1,000 servers per appliance that pass the prerequisite checks, rather than being enabled server by server. If your project predates that, you upgrade from the dependencies view before the auto-enablement applies.
The honest limits
Process capture is best effort, not guaranteed. When the source and destination server names and the destination port are captured but the process at either end cannot be resolved, it is recorded as "Unknown process", and on Linux this usually means the credentials you supplied did not have the privilege needed. If you have added least privileged credentials, some network attributes might be missing from the visualisation, so if the map looks thin, check what the appliance was allowed to read before you conclude the traffic is not there.
There are hard scale numbers worth planning around. Agentless analysis covers up to 1,000 servers per appliance, and for the map view you can visualise dependencies for groups of up to 10 servers, so larger groups need to be split. For the underlying discovery, a single appliance handles up to 10,000 VMware VMs, 5,000 Hyper-V VMs, or 1,000 physical servers, per the appliance FAQ.
What to check before you trust the map
The single most common cause of a bad dependency map is not waiting long enough. The appliance batches data on a six-hour cadence, so a map generated an hour after discovery is meaningless. Microsoft's guidance is to wait at least 24 hours to allow enough dependency data to gather before you read the visualisation. Twenty-four hours is the floor, not the target. If a workload has a weekly close, a nightly ETL run, or a monthly billing job, you have to keep discovery running until that window has passed at least once, or the connection simply will not appear.
Run this list before you draw any conclusions:
- Credentials are elevated enough. If the Dependencies column shows "Credentials not available" or you see a spread of "Unknown process", fix privileges first. Thin data is not the same as no dependency.
- The right servers are actually discovered. Unresolved connections to servers Azure Migrate has not discovered are filtered out of the default map to reduce noise, so a dependency on an undiscovered on-premises host can be invisible. You can switch to the classic experience to see unresolved connections, including those to undiscovered servers when you need the full picture.
- The observation window covers a business cycle. You can export dependencies to a CSV file for a duration of up to 30 days, and the single-server map covers a duration between one hour and 30 days. Pick a window that contains your longest recurring job.
- Nothing is powered off. A server that is down during discovery contributes no data, which corrupts both the dependency map and the sizing that comes next.
Agentless or agent-based: the trade-off
Most teams should default to agentless. Agent-based analysis exists and gives you a longer, richer connection history, but it means installing and maintaining software on every guest you want to map, plus a Log Analytics workspace to hold the data. That is real operational weight to carry for a step you run once before migrating.
| Factor | Agentless | Agent-based |
|---|---|---|
| Guest software | None | Dependency agent plus a monitoring agent on each server |
| Setup effort | Appliance and credentials only | Per-server install, plus a Log Analytics workspace |
| Data retention for the map | Up to 30 days | Longer, held in Log Analytics |
| Blast radius on the source | Low, read-only polling | Higher, agents running in the guest |
| Best for | Most pre-migration mapping at scale | Cases needing long history or process detail agentless cannot resolve |
The trade-off you are making with agentless is history for simplicity. If you need to prove a dependency that only fires quarterly, 30 days will not cover it and you either extend agent-based collection or reason about it from application knowledge. For a standard wave-planning exercise ahead of a lift-and-shift, agentless is enough and the concepts page documents both paths if you need to escalate.
Turning the map into migration waves
The point of the map is to decide what moves together. Two servers with a live, high-frequency dependency should be in the same wave, because splitting them across a cutover means one of them is talking across the WAN back to the datacentre you are trying to exit, adding latency and a hard dependency on hybrid connectivity you may not want to keep.
Work outward from each application's front door. Tag the servers you have identified into an application group inline in the new visualisation, then check the map for connections that leave the group. Every edge that crosses the boundary is a decision: move it into the wave, accept a temporary hybrid link with a plan to remove it, or confirm it is a shared service (DNS, AD, monitoring) that will exist on both sides during transition. Because the map view caps at 10 servers, break a large estate into application-sized groups rather than trying to render everything at once. This grouping work is exactly where a clean landing zone pays off, and it is worth aligning with your cloud architecture and landing zone design before the first wave moves.
Size the target while you are here
Dependency mapping and right-sizing use the same performance data, so do them together. Azure Migrate's performance-based assessment gives each result a confidence rating, and that rating is a direct signal of whether you profiled for long enough. The rating runs from one star (lowest) to five (highest) and reflects the availability of the data points needed to compute the assessment: CPU and RAM utilisation, disk IOPS and throughput per disk, and network I/O per adapter. Miss any of those and the size recommendation is a guess.
The failure mode is the same as with dependencies. If you set a performance duration of one week you have to wait a week after discovery starts for the data points to collect; if you cannot wait, shorten the duration and recalculate. A one-star assessment recalculated at five stars a week later can change every VM SKU in the plan.
Two levers control the sizing itself. The assessment sorts your performance samples and picks a percentile, 95th by default, then multiplies by a comfort factor to add headroom for spikes. Set these deliberately. Too tight and you throttle the workload after cutover; too loose and you pay for cores you will never use, month after month. Getting the assessment and the dependency map right before you touch anything is the whole job of a well-run cloud migration, and it is far cheaper than discovering the gaps in production.
Frequently asked questions
How long should I run Azure Migrate dependency analysis before migrating?
At least 24 hours to get any usable visualisation, but that is the floor. Run it long enough to capture a full business cycle for the workload, which means covering the longest recurring job: a weekly close needs at least a week, a monthly batch needs a month. The export and single-server map support up to 30 days, which is the practical maximum for agentless collection.
Does agentless dependency analysis install anything on my servers?
No. It captures TCP connection data by polling through vCenter for VMware, or directly over PowerShell remoting (port 5985) and SSH (port 22) for Hyper-V and physical servers, with no agent in the guest. You do need credentials with enough privilege to read process and connection information, or you will see "Unknown process" entries and missing network attributes.
Why are some dependencies showing as "Unknown process"?
Because process capture is best effort, and the appliance could identify the servers and destination port but not the process at one or both ends. On Linux this is almost always a credential privilege problem. Check that the account on the appliance has the required rights, then let discovery run again before you read the map.
What is a confidence rating and why is mine low?
It is a one-to-five-star score on a performance-based assessment that reflects how much of the required utilisation data was actually collected. A low rating usually means you did not profile for the full assessment duration, or some servers were powered off during the window. Wait out the duration and recalculate, or shorten the performance duration if you cannot wait.
Should I use agentless or agent-based dependency analysis?
Default to agentless for pre-migration wave planning, because it needs no per-server software and scales to 1,000 servers per appliance. Reach for agent-based only when you need connection history longer than 30 days or process detail that agentless cannot resolve, and accept the cost of installing agents and maintaining a Log Analytics workspace.
