TL;DR – Quick Summary
- NSX-T’s complexity and licensing model drive many teams to reevaluate their SDN strategy.
- Azure Local SDN offers native Windows integration, simpler policy constructs, and automation with PowerShell/Bicep.
- Direct 1:1 mapping between NSX-T and Azure Local doesn’t always exist — architectural redesign is necessary.
- Common gotchas include NSG rule misinterpretation, lack of VRFs, and SLB misconfiguration.
- Strategic planning and phased cutover reduce migration risk.
Introduction: The SDN Shift Is Underway
In today’s cloud-first, software-defined datacenter landscape, network virtualization is no longer optional. VMware NSX-T has long been the go-to solution for enterprises seeking microsegmentation and programmable network constructs — but the landscape is changing fast. With recent licensing uncertainty following Broadcom’s acquisition of VMware and a stronger focus on Microsoft-native solutions, many organizations are exploring an exit strategy.
Enter Azure Local SDN (formerly Azure Stack HCI SDN) — a modern, integrated approach to software-defined networking that extends Azure consistency to on-prem datacenters. For enterprises running hybrid workloads or consolidating legacy infrastructure, migrating from NSX-T to Azure Local is a compelling strategy.
But it’s not a lift-and-shift. This article walks you through the key planning phases, architecture translation, and real-world “gotchas” to watch for.
NSX-T vs Azure Local SDN: Architecture Comparison
| Feature / Component | VMware NSX-T | Azure Local SDN |
|---|---|---|
| Control Plane | NSX Manager / Policy API | Network Controller (NC) |
| Data Plane | ESXi/vDS + N-VDS | Hyper-V Virtual Switch + SLB extensions |
| Tier-0 Gateway | Uplink/Edge Gateway | Software Load Balancer (external) |
| Tier-1 Gateway | Logical Router | Software Load Balancer (internal) |
| Distributed Firewall (DFW) | Microsegmentation at VM NIC | NSG (Subnet/VM Level) |
| Transport Zones | Overlay or VLAN-backed Zones | Virtual Networks + Subnets |
| Edge Nodes | Required for north-south traffic | Not Required — handled by SLB endpoints |
| VRF Support | Native | Not natively available (use vNet patterns) |
Note: Azure Local SDN lacks direct VRF equivalents — instead, use isolated vNets per tenant with custom routing tables and policy-based filtering.
Migration Planning: A 5-Phase Strategy
Phase 1: Inventory & Dependency Mapping
Start with an NSX-T environment inventory:
- Capture Tier-0 and Tier-1 topologies
- Audit all DFW rules and applied objects
- Identify NAT/SNAT policies
- Map network segments to virtual subnets
Use PowerCLI or API exports to automate NSX config extraction:
Get-NsxFirewallRule | Export-Csv -Path .\nsx-fw-export.csv
Phase 2: Network Policy Conversion
Map NSX-T’s microsegmentation rules to Azure NSGs:
- DFW rules → NSG rules (inbound/outbound by priority)
- Be aware of Azure NSG rule limits (1,000 rules per NSG)
- NSGs are stateless — define both directions when needed
Tip: Use Test-AzNetworkWatcherIPFlow to simulate flows before go-live.
Phase 3: Gateway & Routing Redesign
NSX-T Tier-0/1 doesn’t translate directly. Plan for:
- One SLB (external) per public-facing tenant/app
- Internal SLBs for app tiers or load distribution
- Route tables per subnet to define next-hop behavior
Sample Bicep snippet:
resource slb 'Microsoft.Network/loadBalancers@2021-05-01' = {
name: 'myInternalSLB'
location: resourceGroup().location
properties: {
frontendIPConfigurations: [...]
backendAddressPools: [...]
loadBalancingRules: [...]
}
}
Phase 4: Automation – Bicep, PowerShell & WAC
- Use Bicep for repeatable SDN deployments (NSGs, SLBs, Routes)
- PowerShell for operational tasks (e.g., Test-AzNetworkWatcherIPFlow)
- Windows Admin Center (WAC) with SDN Manager for GUI management
Phase 5: Validation & Cutover
Before switching traffic:
- Validate NSG rule behavior with logging
- Confirm routes via Network Watcher
- Use packet captures to simulate known workloads
- Consider blue/green or canary approach to cutover per subnet
Gotchas and Lessons Learned
| Gotcha | Description + Workaround |
|---|---|
| NSG Rule Order | Azure NSGs are processed by priority (lowest = highest priority) |
| No VRF Equivalent | Use separate VNets + UDRs for tenant isolation |
| NAT Rule Conversion | Azure Local supports DNAT/SNAT, but mappings differ — manual translation needed |
| SLB Misconfiguration | Internal vs External SLBs are separate objects — don’t overload a single resource |
| Policy Application Scope | NSGs apply at subnet or NIC level — no group-based tagging like NSX security groups |
| No DFW Logging by Default | Use NSG flow logs (via Network Watcher) for visibility |
| DHCP & DNS | Must integrate via Azure services or local DHCP/DNS relay manually |
Tools & Automation for the Migration
- PowerCLI – export rules and segment configurations from NSX
- Bicep – declaratively define and deploy SDN components
- WAC + SDN Manager – Azure Local SDN control plane GUI
- Aria Migration Hub – Map virtual machines and dependency graphs (formerly vRealize)
Final Thoughts: Design with the Future in Mind
The journey from VMware NSX-T to Azure Local SDN is more than a platform shift — it’s a transformation in how network infrastructure is designed, deployed, and governed. While NSX-T offered granular control and multi-tenancy through constructs like Tier-0/1 gateways and DFWs, Azure Local SDN pushes toward simplified, policy-driven design, tighter integration with native Windows Server, and declarative automation using tools like Bicep, PowerShell, and Windows Admin Center.
Organizations that succeed in this transition take a phased, validated, and automation-first approach, rethinking their network design instead of trying to replicate it 1:1. Embrace NSG-based microsegmentation, SLB tiering, and vNet isolation patterns as the foundation of your next-generation SDN.
Whether you’re facing licensing pressure, looking to consolidate platforms, or simply ready to modernize — Azure Local SDN offers a strategic, cost-effective path forward for your hybrid or on-prem datacenter.
Next Step: Run a pilot environment using a single application workload and test NSG, SLB, and routing constructs before broader migration.
*The thoughts and opinions in this article are mine and hold no reflect on my employer*