NSX-T Enterprise Network Deployment: From Blank Slate to Production in 6 Weeks
We recently deployed VMware NSX-T at a 1,200-user financial services company in Metro Manila. The data center was a traditional VLAN-based environment with hardware firewalls at every segmentation point. The goal was to move to a software-defined network without disrupting trading operations. Here is the exact 6-week plan we used.
Week 0: Discovery and Design
Before touching NSX-T Manager, we documented the current state:
- Physical topology: Two core switches, four TOR switches, two hardware firewalls
- VLAN inventory: 47 VLANs across production, DMZ, management, and storage
- East-west traffic patterns: Which application tiers talk to each other
- North-south bandwidth: 2 x 10Gbps internet uplinks, 4 x 10Gbps WAN links
- Security zones: PCI scope, corporate network, guest Wi-Fi, development
We chose an overlay-only design with the existing physical network left as an IP transport underlay. This minimized changes to the switching team and let us rollback quickly if needed.
Key design decisions: - T0 gateway: Active-Active ECMP with BGP peering to the physical core - T1 gateways: One per security zone (Production, DMZ, Management, Development) - Segments: Mapped to existing VLANs during migration, then decoupled - DFW rules: Replaced hardware firewall rules for east-west traffic - Edge cluster: Two Edge nodes in Active-Active mode for stateful services failover
Week 1: Build the Foundation
Day 1-3: Deploy NSX-T Manager cluster (3 nodes) on a dedicated management vSphere cluster.
Day 4-5: Configure compute manager (vCenter), transport zones, and host transport nodes.
Critical validation: - Verify VTEP VMkernel adapters on each ESXi host - Confirm MTU is 9000 or higher across the underlay - Test VXLAN encapsulation between hosts in different racks
Week 2: Routing and Edge Services
- Configure T0 and T1 gateways
- Establish BGP sessions with the physical core
- Advertise/accept only necessary prefixes
- Deploy NAT, load balancing, and VPN services on Edge nodes
Lesson learned: we initially advertised all overlay prefixes to the core and caused a route-leak into the WAN. We fixed this with route maps and prefix lists, limiting redistribution to /24 summaries per zone.
Week 3: Segment Migration — Non-Production First
We moved the Development zone first. Steps for each segment:
- Create NSX segment with matching subnet
- Place test VMs on the segment
- Verify default gateway and DFW rules
- Migrate remaining VMs using vMotion
- Decommission the original VLAN
The Development migration surfaced a DNS issue: VMs could not resolve internal names because the new segment used a different DHCP relay. We updated the DHCP helper address and documented the requirement.
Week 4: Security Policy Cutover
This was the highest-risk week. We translated hardware firewall rules into Distributed Firewall (DFW) policies.
Our rule structure: - Section 1: Emergency allow/block (top) - Section 2: PCI isolation - Section 3: Application tier micro-segmentation - Section 4: Default deny (bottom)
We used NSX tags and groups instead of IP addresses wherever possible. For example, a group called app-web-prod included all production web servers by tag, so new VMs inherited policy automatically.
Before enabling the default deny rule, we ran NSX Policy Manager in simulation mode for 72 hours to identify missing rules. This caught 14 legitimate flows that were not documented.
Week 5: Production Migration
We followed the same segment migration process for production, but in smaller batches: - Batch 1: Management tier (low traffic) - Batch 2: Application tier - Batch 3: Database tier (during a scheduled maintenance window)
Each batch had a rollback window of 2 hours. We used vMotion snapshots and maintained the original VLAN for 48 hours after each cutover.
Week 6: Hardening and Handover
- Enabled logging on all DFW rules and sent logs to the SIEM
- Configured NSX backup to NFS and verified restore procedure
- Created runbooks for common tasks: adding a segment, changing a rule, troubleshooting overlay connectivity
- Trained the network operations team for two days
- Documented known limitations: hardware firewall still handled north-south DDoS protection; NSX IDS/IPS was planned for Phase 2
What Worked
- Overlay-only design reduced underlay changes and risk
- NSX Policy simulation prevented application outages during DFW cutover
- Tag-based groups made policy scalable
- Non-production first migration caught DNS and DHCP issues early
What We Would Do Differently
- Start route filtering earlier. Route leaks delayed Week 2 by two days.
- Inventory east-west flows with NetFlow first. Some application dependencies were undocumented.
- Assign a firewall rule owner. Without ownership, rule cleanup never happens.
6-Week Timeline Summary
| Week | Focus | Key Output |
|---|---|---|
| 0 | Discovery and design | Architecture document, IP plan |
| 1 | NSX-T foundation | Manager cluster, transport nodes |
| 2 | Routing and edges | BGP peering, Edge services |
| 3 | Non-prod migration | Development zone on NSX |
| 4 | Security cutover | DFW rules, simulation validation |
| 5 | Production migration | All tiers migrated |
| 6 | Hardening and handover | Runbooks, training, backups |
When NSX-T Is Worth It
NSX-T makes sense when: - You need micro-segmentation at scale - Hardware firewall refresh is approaching - Multi-site or cloud extension is on the roadmap - You want policy automation via Infrastructure-as-Code
It is overkill when: - Your network is small and stable - Your team has no virtualization or routing expertise - The primary need is only VLAN provisioning
Bottom Line
A 6-week NSX-T deployment is realistic for a mid-size enterprise if you design the underlay carefully, migrate non-production first, and validate firewall behavior before cutting over production. The biggest risk is not the technology — it is undocumented traffic flows and poor route hygiene.
Want to go deeper? Explore VMware alternatives, Run infrastructure services, or platform comparison.