Migrating Classic NSX to VPCs in VCF 9 Part 1: Architecture and Strategy
First in a series on moving an existing NSX estate onto the VPC model in VCF 9.x. This part covers the constructs, how old and new coexist, and how to decide what moves. Parts 2-4 are hands-on: building the landing zone, migrating a workload, decommissioning.
Almost everything written about NSX VPCs so far starts from an empty environment. That skips the hard part. If you run NSX in production today you have segments, Tier-1 gateways, NAT rules and firewall policy built up over years, and you want to know how to get from that to the VPC model without a disruptive cutover.
Before anything else, two things you should know. There is no in-place conversion: as of VCF 9.1 you cannot promote or convert a segment into a VPC subnet, so you will be building the new environment alongside the old and moving workloads into it. And classic constructs and VPCs run in the same NSX instance, on the same transport nodes, and can share northbound routing. The second point is what makes the first one tolerable. You are not planning a cutover weekend. You are standing up a landing zone next to the estate you already have, and the two stay routable to each other for as long as you need.
The constructs, mapped
The data path barely changes between the two models. What changes is who operates the objects. In the classic model the network team builds everything: segments, T1s, NAT, DFW policy, IP allocation. In the VPC model those objects still exist, but the platform creates and manages them, and what you hand to an application team is the VPC itself: a container with a CIDR, an automatically created gateway, and subnets they carve out themselves.
If you know NSX, the mapping is close to one-to-one:
Some notes on the rows that matter for design work.
The VPC gateway is a Tier-1. Same data path you run today. The difference is lifecycle: the platform creates it with the VPC and sizes it, and no administrator ever configures it directly. The per-app drift you see on hand-managed T1s goes away because there is nothing to log in to.
External Connections abstract the Tier-0. As the provider you define them as named paths to the physical network. Transit Gateways attach to them, and tenants steer traffic without ever seeing the T0 or the VLANs underneath. VCF 9.1 added three things here worth knowing about: remote networks, which let a TGW use different external connections for different destination prefixes (datacentre traffic one way, internet another); private IP blocks, which let private subnets talk to the datacentre on their real addresses instead of being SNATed; and provider-managed outbound SNAT.
Projects are the tenancy boundary, and they aren’t new: NSX has had Projects since 4.1, and if you weren’t using them you were probably faking tenancy with a T1 per tenant and careful RBAC. What changes in VCF 9 is what a project contains. The default project exists out of the box, has a pre-created Transit Gateway, and is where VPCs created through vCenter land. User-defined projects each get their own TGW and become the container your VPCs live in.
Transit Gateways come in centralized (Edge-based) and distributed forms. In 9.1 the distributed form gained stateful services through the Virtual Network Appliance (VNA), including NAT and VKS without an Edge cluster or a T0. I’m assuming centralized TGWs for this series because they behave predictably next to an existing Edge estate. If your environment is close to greenfield, look at the distributed option before you commit.
Inside a VPC there are three subnet types. Public subnets are advertised northbound and reachable on their real addresses, so they behave like the routed segments you have now. Private (Transit Gateway) subnets route VPC-to-VPC across the TGW without NAT, and need translation to be reached from outside. Private (VPC-only) subnets route only among the VPC’s own subnets. There is also one feature I want to flag now because it does a lot of work in Part 3: you can assign an external IP to an individual VM on a private subnet, and it gets advertised northbound as a /32 via 1:1 NAT. That is how you keep a published endpoint on its existing address while the workload behind it moves.
Coexistence
Both models terminate on the same Tier-0: directly in the classic case, through an External Connection in the VPC case. So once the landing zone exists, a VM on a classic segment reaches a VM in a VPC through ordinary routing. No bridging, no tunnels, nothing temporary that has to be unpicked later.
Building the landing zone is provider-side work and touches nothing in the existing estate. Your T1s and segments carry on exactly as before. After that, workloads move in whatever increments you’re comfortable with, and there is no architectural reason the migration ever has to finish. A segment that resists migration can sit there for years without affecting the VPCs around it. I keep repeating this because it changes the risk conversation with management completely: the scary version of this project does not exist.
Deciding how each network moves
Since nothing converts in place, each network takes one of three paths. In practice you make this decision per application, because applications span networks and the application is what you migrate.
The default path is re-IP and move incrementally. If the application tolerates readdressing, and with DNS-based service discovery most do (whatever the app owner tells you at first), you create a subnet in the target VPC, move VMs over in small groups, and cut over with DNS. The application runs split across old and new while this happens, because everything is routed. Blast radius is one application, and in the early stages you can simply move the VMs back.
If readdressing is truly impossible — hard-coded addresses, licensing tied to an IP — you recreate the same CIDR as a private subnet in the VPC and cut the whole network over in one window. The old segment and the new subnet can’t both be routable at once, so rollback means another window. Save these for late in the project, when the runbook has been through a few waves.
The third path is to not move it. Coexistence has no expiry date, so leaving a network on classic segments is a decision, and sometimes the right one. Nothing about the VPCs next door degrades because of it.
Sequencing follows from that:
Phase 0 is inventory: segments, T1s, NAT and firewall rules, mapped per application. Phase 1 builds the landing zone — projects, TGW, External Connections, IP blocks, profiles — with no workloads involved. Phase 2 takes one low-stakes application through the whole runbook; the point of the pilot is the runbook, and you should expect to revise it. Phase 3 is the waves, application by application through the decision tree, DNS doing the cutovers, external IPs holding any addresses that must not change. Phase 4 is deleting empty segments and the T1s above them, which is the most satisfying part of the whole project.
What’s next
Part 2 builds the landing zone in detail: project and TGW design, centralized versus distributed (and where VNA fits), External Connections, IP block sizing, and the profile decisions that are expensive to change later. Part 3 runs the incremental runbook against a real application, including the DNS handling and external IPs. Part 4 covers the awkward cases: whole-CIDR cutovers, firewall policy translation, decommissioning.
The diagrams in this series are Excalidraw files. Take them and adapt them for your own designs and runbooks.
Written against VCF 9.1. Check the Broadcom documentation for your versions; the VPC feature set changes noticeably between releases.