You Can't Use Azure Migrate to Move Between Tenants (Even if you Try to Run it in Azure)
- Shannon
- Dec 4, 2025
- 4 min read
Tis the season! Customers always ask the most interesting questions about cloud capabilities. This one isn't documented well and you have to sort of piece it together by "reading the tea leaves" (my least favorite).
A customer asked me a question that sounded simple enough:
“Can we stand up Azure Migrate in our brownfield tenant, run dependency mapping there, and then use Azure Migrate to migrate workloads into our new greenfield tenant?”
If you’ve ever led a large-scale migration, that probably sounds logical. Dependency mapping is essential. You want to know which workloads talk to each other before you start moving anything. Azure Migrate has “dependency mapping” built into its product, so it feels like the right choice.
Except it’s not.
Azure Migrate can’t perform dependency mapping inside Azure. It’s built for external discovery, not in-cloud visibility. Once your workloads already live in Azure, you need a different approach.
Why Azure Migrate Won’t Work Inside Azure
Azure Migrate is designed for moving workloads into Azure, not for inspecting what’s already there. The tool relies on a small appliance you deploy in the source environment. That appliance gathers performance data, network flow information, and metadata, then reports back to the Azure Migrate project for analysis.
Even if you install that appliance on an Azure virtual machine, it still treats that VM as if it were an external server. It doesn’t connect through the Azure control plane, it doesn’t query Azure Resource Graph, and it doesn’t have access to platform telemetry.
In short, Azure Migrate lives in Azure but doesn’t operate like other Azure-native services. It’s hosted there, but it doesn’t see what Azure itself can see.
So when a team tries to use it for dependency mapping inside a brownfield tenant, it won’t return anything meaningful. The appliance can’t inventory or map connections between Azure resources that already exist in the platform.
The Right Way to Map Dependencies in Azure
If your workloads are already in Azure and you need dependency visibility, you have two native options that work well: Azure Monitor Agents and Azure Resource Graph.
Azure Monitor and the Dependency Agent
Azure Monitor, combined with the Azure Monitor Agent (AMA) and the Dependency Agent, provides the same kind of visibility that many people assume Azure Migrate will give them. When you enable VM Insights, Azure Monitor can collect process and connection data directly from each virtual machine.
The Dependency Agent records inbound and outbound connections, shows which ports are used, and identifies interdependencies between systems. This information is then visualized through Service Map in the Azure portal or surfaced through Log Analytics queries.
Unlike Azure Migrate, this approach runs natively inside Azure. It’s fully tenant-aware, secured through Azure RBAC, and integrated with other monitoring and governance features.
Documentation: Azure Monitor Agent overview and VM Insights Dependency Agent
Azure Resource Graph
For higher-level relationships, Azure Resource Graph is your friend. It lets you query your entire Azure environment to see how resources connect and depend on each other. You can ask questions like which subnets your VMs are using, which public IPs are attached, or which resources share a virtual network.
These queries can be run directly in Resource Graph Explorer, through Azure CLI or PowerShell, or integrated into custom dashboards. I love these queries...they're fast, accurate, and fully cloud-native.
Documentation: Azure Resource Graph overview
The Tenant Boundary Problem
The second issue my customer faced was moving workloads to a new tenant. Microsoft Entra ID (formerly Azure AD) creates a hard separation between tenants. Each has its own identity boundary, its own role assignments, and its own service principals.
Microsoft’s documentation states:
“The move operation doesn’t support moving resources to new Microsoft Entra tenant. If the tenant IDs for the source and destination subscriptions aren’t the same…”— Move Azure resources to a new resource group or subscription
That means you can’t “move” Azure resources directly between tenants. Azure Migrate can’t cross that line either, because its authentication model is tenant-scoped.
If you’re trying to migrate to a greenfield tenant, you have two real choices:
Transfer the subscription to the new tenant, which moves everything under a single directory.
Rebuild the environment in the new tenant using ARM, Bicep, or Terraform templates and then migrate data separately with tools like AzCopy, Data Factory, or Database Migration Service.
Why This Matters
Azure Migrate is often misunderstood because it looks like an Azure-native service in the portal. It’s easy to assume it works like Log Analytics, Policy, or Monitor. The difference is that those services live inside the Azure control plane, while Azure Migrate orchestrates migration activities from the outside.
If your workloads are already running in Azure, rely on Azure-native observability and governance tools instead. They understand the platform’s structure, respect tenant boundaries, and give you richer, real-time insight.
Wrapping Up
If you’re planning a move from a brownfield tenant to a greenfield one, don’t reach for Azure Migrate to map your dependencies. It won’t see what’s inside Azure. Use Azure Monitor Agents and Service Map for connection-level visibility, and Azure Resource Graph for relationship-level insight. Those tools were built for exactly this scenario and work natively across your Azure subscriptions.
Azure Migrate still has its place for moving workloads into Azure. Once you’re already there, the platform gives you MUCH better ways to understand how everything connects.