Site icon Digital Thought Disruption

Lift and Shift: Migrating NSX Segments to Azure Local VNETs and Subnets

Paul Bryant

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:

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 ComponentAzure Local SDN Equivalent
Logical Segment (Overlay)Subnet within a VNet
Tier-1 GatewayRoute Table with local routes
Tier-0 GatewaySDN Gateway or physical UDR gateway
Distributed Firewall RulesNSG Rules or Azure Firewall Policies
Overlay Transport ZoneVXLAN 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:

  1. Assess
  2. Map
  3. Translate
  4. Validate
  5. Cutover

Phase 1: Assess – Inventory NSX Segments and Dependencies

Manual Checklist:

Tooling:

Output to CSV:

$segments = Get-NsxSegment
$segments | Export-Csv "NSX-Segments.csv" -NoTypeInformation

Phase 2: Map – Plan Azure VNET/Subnet Design

Manual:

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 FieldNSG Equivalent
Source GroupsSource Address Prefix
ServicesProtocol + Port
Applied ToSubnet 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:

Tools:

Phase 5: Cutover – Final Migration and Rollback Planning

Options:

Rollback Plan:

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:

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:

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*

Exit mobile version