Why Azure Migrate's "Agentless" Discovery Fails in Enterprise Hybrid Environments

The Promise

Microsoft's pitch for Azure Migrate sounds perfect for enterprise cloud migrations:

"Official" Microsoft migration tool
Agentless discovery (no agents to install!)
Automated dependency mapping
Application inventory across your environment
Works in hybrid architectures

The documentation makes it look simple: deploy the appliance, add some credentials, click "discover," and watch it map your entire environment.

Except when you have multiple Active Directory domains in a hybrid environment with actual security policies, Azure Migrate's architecture becomes fundamentally incompatible with enterprise security and network design.

Here's the disaster Microsoft's documentation glosses over.

How Enterprise Migrations Actually Start

Almost every enterprise Azure migration begins the same way:

Hybrid architecture:
- On-premises Active Directory domains
- Azure AD Connect syncing identities
- ExpressRoute or VPN connectivity to Azure
- Dual environment for 12-18 months minimum
- Gradual workload migration

Multiple AD domains:
- Years of company growth
- Multiple acquisitions and mergers
- Regional domain structures
- Different forests or separate domains

Network segmentation by design:
- Domains isolated by firewalls
- Zero-trust network architecture
- Separate VLANs or network segments per domain
- Firewall rules between domains (intentional)

This isn't poor architecture. This is enterprise security best practice.

The Azure Migrate Architecture Assumption

Azure Migrate was designed for environments that look like this:

✅ Single AD domain
✅ Flat network topology
✅ No network segmentation
✅ Security team that "just lets you have credentials"
✅ Small scale (hundreds of VMs, not thousands)

Microsoft's documentation never explicitly says this, but the tool's behavior reveals these assumptions.

The "Agentless" Problem

Microsoft markets "agentless discovery" as a feature. In hybrid multi-domain environments, it's actually a massive liability.

What "Agentless" Really Means

For basic infrastructure discovery:
- Connects to vCenter on port 443
- Pulls VM inventory via VMware APIs
- Gets CPU, memory, disk from vCenter
- This part works fine

For application discovery and dependencies (what you actually need for migration):

The appliance needs direct network access to every VM:

Windows VMs require:
- Port 135 (RPC endpoint mapper)
- Ports 49152-65535 (dynamic high ports for WMI/DCOM)
- Port 5985/5986 (WinRM for PowerShell remoting)
- SMB access for file enumeration

Linux VMs require:
- Port 22 (SSH)

Microsoft's documentation mentions these requirements but never connects the dots on what this means in hybrid multi-domain environments.

The Credential Mapping Disaster

Microsoft's documentation says:

"After you've added credentials, appliance attempts to automatically map the credentials to perform discovery on the respective servers. The domain credentials added will be automatically validated for authenticity against the Active Directory of the domain."

Sounds reasonable. Here's what actually happens.

The Setup

You have:
- 500 VMs across multiple AD domains
- Hybrid architecture with on-prem and Azure
- Network segmentation between domains
- Azure Migrate appliance deployed

You add credentials:
- Domain A service account (local admin rights on Domain A servers)
- Domain B service account (local admin rights on Domain B servers)
- Domain C service account (local admin rights on Domain C servers)
- Non-domain credentials for workgroup servers
- SSH credentials for Linux VMs

What Microsoft Never Explains

How does the appliance know which credential to use for which server?

The documentation never says. Here's what appears to happen based on actual behavior:

Appliance discovers VM001 from vCenter
Appliance has no way to determine which domain VM001 belongs to
Appliance tries Domain A credentials → authentication fails
Appliance tries Domain B credentials → authentication fails
Appliance tries Domain C credentials → success
Appliance repeats for VM002, VM003... VM500

The math:
- 500 VMs across multiple domains
- Average 2-3 failed authentication attempts per VM (assuming randomish distribution)
- Result: 1,000-1,500 failed authentications across your environment

Why It Can't Work Better

The credentials you provide have local admin rights on target servers, not domain admin.

This means:
- ❌ Can't query Active Directory to determine domain membership
- ❌ Can't see which servers belong to which domain before authenticating
- ❌ Must brute-force authentication attempts
- ❌ Generates massive failed authentication volume
- ❌ Triggers account lockout policies
- ❌ Creates security alerts

With domain admin credentials, the tool could theoretically query AD to map servers to domains first. But then Security would never approve domain admin credentials for this use case.

It's an architectural catch-22.

The Firewall Nightmare

"Agentless" sounds great until you map it onto actual enterprise network architecture.

The Request

You: "We need to enable Azure Migrate for discovery and assessment."

Network Security: "Where's the appliance deployed?"

You: "In Azure, connected back to on-prem via ExpressRoute."

Network Security: "What does it need access to?"

You: "All 500 VMs across our on-premises environment."

Network Security: "What ports?"

You: "135, 49152-65535, 5985, 5986, and 22."

Network Security: "..."

The Problem

Your network was designed with segmentation:
- Domain A servers: 10.10.0.0/16
- Domain B servers: 10.20.0.0/16
- Domain C servers: 10.30.0.0/16
- Firewalls between segments
- Zero-trust network policies

Azure Migrate needs:
- Single appliance with direct L4 connectivity to all 500 VMs
- Dynamic high ports (49152-65535) - can't predict which ones
- Bidirectional access for WMI/WinRM/SSH
- Access across all domain network segments

This violates your entire network segmentation strategy.

What Security Actually Says

Network Security: "We spent years isolating these domains. You want to punch firewall holes through all of it for a discovery tool?"

You: "It's Microsoft's official migration tool..."

Network Security: "Then Microsoft didn't design it for segmented enterprise networks. Request denied."

The Battle No One Wins

This creates an impossible conversation between three teams:

Cloud Migration Team

"We need Azure Migrate to discover applications and dependencies. Microsoft says this is the right tool. It's agentless, which should make it easier. Why can't we just add the credentials and firewall rules?"

Information Security Team

"You want to store multiple domain service accounts with local admin rights on 500+ servers in a static appliance, have it brute-force authentication across domains, and accept 1,000+ failed auth attempts? That violates our security policies around credential management, least privilege, and audit trails."

Network Security Team

"You want a single appliance in Azure to have direct network access to 500 VMs across multiple network segments that we intentionally isolated with firewalls? That violates our network segmentation and zero-trust architecture. Not happening."

The Impasse

Cloud team can't proceed without discovery
Security teams won't approve the architecture
Microsoft documentation offers no alternative approach
Everyone is frustrated

What Microsoft's Documentation Doesn't Tell You

The Missing Context

Microsoft's Azure Migrate documentation was written for:
- Development/test scenarios
- Small-scale deployments
- Single-domain environments
- Flat network topologies
- Proof-of-concept migrations

It was not designed for:
- Post-merger environments with multiple domains
- Enterprise network segmentation
- Zero-trust architectures
- Hybrid environments at scale
- Actual security policies

The Documentation Gaps

Microsoft never explains:
- ❌ How credential mapping works across multiple domains
- ❌ Whether you can manually map credentials to specific servers
- ❌ How to prevent brute-force authentication attempts
- ❌ Firewall architecture for segmented networks
- ❌ Alternative approaches when "agentless" isn't viable
- ❌ How to handle credential rotation without breaking discovery

The docs assume if you follow the steps, it'll "just work." In enterprise hybrid environments with multiple domains, it fundamentally can't.

What Actually Happens

Option 1: Don't Use Azure Migrate for Deep Discovery

Use Azure Migrate only for basic infrastructure assessment:
- VM inventory from vCenter
- Compute/storage/network sizing
- Basic cost estimates

Skip the application discovery and dependency mapping entirely. Accept that you'll miss dependencies and need manual application discovery.

Tradeoff: Lose the dependency visibility Azure Migrate promises.

Option 2: Agent-Based Discovery Tools

Use agent-based alternatives:
- Deploy agents to VMs (requires management overhead)
- Agents authenticate locally and send data over HTTPS
- Eliminates credential brute-forcing
- Simpler firewall rules (VMs → collector, not collector → VMs)
- Each agent knows its own domain context

Tradeoff: Microsoft's official tool doesn't do this. Third-party tools or custom solutions required.

Option 3: Manual Discovery by Domain

Divide and conquer:
- Deploy separate Azure Migrate appliances per domain
- Each appliance only discovers its own domain's VMs
- Manually consolidate findings
- Reduces credential brute-forcing
- Still requires extensive firewall rules

Tradeoff: Significant operational overhead, multiple appliances to manage.

Option 4: Temporary Architecture Compromises

Some enterprises actually do this:
- Temporarily relax network segmentation
- Allow credential brute-forcing "just for migration"
- Accept the security risk as time-limited
- Clean up after migration completes

Tradeoff: You're compromising security architecture to accommodate a tool's limitations.

Lessons Learned

1. "Agentless" Isn't Always Better

Agentless works great for simple environments. In complex hybrid multi-domain architectures, agents can actually be simpler because:
- Local intelligence (agent knows its own domain)
- Outbound-only HTTPS (easier firewall rules)
- No credential brute-forcing
- Better audit trails

2. Microsoft's Tools Assume Simple Environments

Azure documentation and tooling often assume:
- Single domain
- Flat networks
- Public cloud-only
- Small scale

When you deviate from these assumptions, you're on your own.

3. The Real Migration Tool Is Excel

Despite all the automation promises, enterprise migrations still require:
- Manual application inventory
- Owner interviews
- Dependency mapping through discussion
- Business process documentation
- Risk assessment per application

Azure Migrate can't replace this work in complex environments.

4. Security Teams Aren't Being Difficult

When Security says "no" to Azure Migrate's requirements, they're not blocking progress. They're enforcing the policies that protect the business:
- Network segmentation reduces blast radius
- Credential management prevents lateral movement
- Audit trails enable forensics
- Least privilege limits damage

Azure Migrate's architecture conflicts with these fundamentals.

The Uncomfortable Truth

Microsoft built Azure Migrate for a scenario that doesn't match enterprise reality.

The tool works beautifully for:
- Single-domain environments
- Flat networks
- Greenfield migrations
- Proof-of-concepts
- Small deployments

It fails architecturally for:
- Multi-domain enterprises (common post-merger)
- Segmented networks (security best practice)
- Hybrid environments at scale (most enterprises)
- Zero-trust architectures (industry direction)

This isn't a configuration problem. It's not a "you're doing it wrong" problem. It's an architectural mismatch between the tool's design assumptions and enterprise reality.

If you're struggling to make Azure Migrate work in your environment, it's probably not you. It's the tool.

Discussion

Have you hit this problem? How did your organization handle Azure Migrate in multi-domain hybrid environments? I'd love to hear what actually worked (or didn't).