TLDR – Quick Summary
This guide walks you through an expert-level, phased “lift-and-shift” migration from VMware NSX-T 4.2 Segments to Azure Local SDN Virtual Networks and Subnets. It includes manual steps, PowerShell automation, and Bicep/JSON templates to help network architects modernize their infrastructure while maintaining compliance and minimizing downtime.
Introduction: Why Migrate NSX-T Segments to Azure Local
As enterprises move toward hybrid infrastructure, many are decommissioning legacy NSX-T deployments in favor of Microsoft’s SDN platform built into Azure Local (formerly Azure Stack HCI).
This shift enables:
- Native integration with Azure services
- Simplified governance and microsegmentation
- Unified tooling across on-prem and cloud
- Lower TCO with reduced NSX licensing complexity
If you’re running NSX-T 4.2 and need to replatform to an Azure-based SDN, this guide delivers a comprehensive technical blueprint.
NSX-T to Azure SDN Mapping
| NSX-T Component | Azure Local SDN Equivalent |
|---|---|
| Logical Segment (Overlay) | Subnet within a VNet |
| Tier-1 Gateway | Route Table with local routes |
| Tier-0 Gateway | SDN Gateway or physical UDR gateway |
| Distributed Firewall Rules | NSG Rules or Azure Firewall Policies |
| Overlay Transport Zone | VXLAN or internal SDN virtual switch |
Note: NSX Segments often map to Azure Subnets, but context matters—multi-tenant NSX architectures may require separate VNets.
Migration Strategy Overview
Phased Plan:
- Assess
- Map
- Translate
- Validate
- Cutover
Phase 1: Assess – Inventory NSX Segments and Dependencies
Manual Checklist:
- Export list of NSX Segments:
Get-NsxSegment | Select DisplayName, ConnectedGateway, TransportZoneId - Identify attached VMs or workloads via
Get-NsxLogicalPort - Document firewall rules from Distributed Firewall and Gateway Firewall
Tooling:
- PowerCLI
- NSX Manager API
- Aria Automation (formerly vRealize)
Output to CSV:
$segments = Get-NsxSegment
$segments | Export-Csv "NSX-Segments.csv" -NoTypeInformation
Phase 2: Map – Plan Azure VNET/Subnet Design
Manual:
- Decide subnet CIDR ranges that reflect NSX segments
- Determine whether to group segments into VNets or isolate
Bicep Template:
resource vnet 'Microsoft.Network/virtualNetworks@2022-01-01' = {
name: 'CorpVNet'
location: resourceGroup().location
properties: {
addressSpace: {
addressPrefixes: [
'10.100.0.0/16'
]
}
subnets: [
{
name: 'WebSubnet'
properties: {
addressPrefix: '10.100.1.0/24'
}
}
]
}
}
PowerShell:
New-AzVirtualNetwork -Name "CorpVNet" -ResourceGroupName "RG1" `
-Location "eastus" -AddressPrefix "10.100.0.0/16"
Add-AzVirtualNetworkSubnetConfig -Name "WebSubnet" `
-AddressPrefix "10.100.1.0/24" -VirtualNetwork $vnet
Phase 3: Translate – Convert Segments, NSGs, and Routing
NSX Security Rules → Azure NSGs
| NSX Field | NSG Equivalent |
|---|---|
| Source Groups | Source Address Prefix |
| Services | Protocol + Port |
| Applied To | Subnet or NIC level |
JSON Example:
{
"name": "AllowWebInbound",
"properties": {
"protocol": "Tcp",
"sourcePortRange": "*",
"destinationPortRange": "443",
"sourceAddressPrefix": "*",
"destinationAddressPrefix": "10.100.1.0/24",
"access": "Allow",
"priority": 100,
"direction": "Inbound"
}
}
PowerShell:
$nsgRule = New-AzNetworkSecurityRuleConfig -Name "AllowWebInbound" `
-Description "Allow HTTPS" -Access Allow -Protocol Tcp `
-Direction Inbound -Priority 100 -SourceAddressPrefix "*" `
-SourcePortRange "*" -DestinationAddressPrefix "10.100.1.0/24" `
-DestinationPortRange 443
$nsg = New-AzNetworkSecurityGroup -ResourceGroupName "RG1" -Location "eastus" `
-Name "WebNSG" -SecurityRules $nsgRule
Phase 4: Validate – Simulate and Test
Checklist:
- Deploy test VMs to new Azure Local VNETs
- Verify connectivity and routing
- Apply NSGs and validate traffic paths
- Simulate East-West and North-South flows
Tools:
- Wireshark
- Azure Network Watcher
- VMware Port Mirroring + Aria Operations
Phase 5: Cutover – Final Migration and Rollback Planning
Options:
- Cold migration (shut down VM, re-IP on Azure)
- Live migration (Azure Migrate with network adapter switch)
Rollback Plan:
- Maintain original NSX environment for fallback
- Snapshot workloads
- Use custom tags to flag migration status
Azure Migrate Usage:
Start-AzMigrateReplication -TargetResourceGroupName "RG1" `
-TargetVirtualNetworkId "/subscriptions/xxx/resourceGroups/RG1/providers/Microsoft.Network/virtualNetworks/CorpVNet"
Real-World Use Case
Customer: North American Retail Chain
Scenario: Migrated 27 NSX Segments across 4 Tier-1 Gateways to Azure Local
Outcome:
- Reduced network latency by 23%
- Replaced 184 firewall rules with centralized NSGs
- Full rollback tested during blue/green deployment
Source: Microsoft Azure Case Study: “Hybrid SDN Design with Azure Local”, 2024
Final Thoughts
Migrating from NSX-T 4.2 to Azure Local SDN is not a trivial undertaking, it requires careful planning, deep understanding of both platforms, and a commitment to preserving security, availability, and performance throughout the process. But the rewards are substantial.
By aligning your network architecture with Microsoft’s modern, hybrid-ready SDN fabric, you gain:
- Simplified governance through Azure-native tooling
- Integrated management of networking, identity, and policy
- Improved cost efficiency through license consolidation
- Future-proof scalability for edge, hybrid, and cloud-native workloads
Whether you’re migrating a few key segments or a multi-tenant NSX deployment, the phased approach outlined here, with manual, PowerShell, and Bicep-based options, ensures you can move at your own pace while maintaining control.
Remember: migrations are not just about moving workloads—they’re about transforming how your infrastructure operates. Take the time to assess dependencies, validate configurations, and document every phase. Leverage automation where possible, but keep rollback paths clear.
If you’ve completed a migration like this or are planning one, I’d love to hear your story. What worked, what didn’t, and what tools helped you succeed? Let’s learn from each other.
*The thoughts and opinions in this article are mine and hold no reflect on my employer*