From VMware NSX-T to Azure Local SDN: Migration Planning and Gotchas

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

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

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*