This section covers advanced migration modes that you can use to migrate specific parts of your NSX Data Center for vSphere environment without the need to deploy an extra hardware, such as separate compute clusters, in your destination NSX-T Data Center environment.

For example: Your organization might prefer to create a new NSX-T Data Center topology and configure the NSX-T Edges and other networking services manually without using the migration coordinator. For instance, you can deploy NSX-T Edge nodes on existing NSX-v hosts.

Your objective is to use the migration coordinator to migrate only the existing Distributed Firewall (DFW) configuration and NSX-v compute hosts to NSX-T. You want the workload VMs to continue running on the existing compute hardware with a minimal disruption to the east-west traffic security protection when migrating to the new NSX-T environment.

As you are doing an in-place migration of only the DFW configuration and compute hosts, the migration coordinator does not define the NSX-T topology. You have the flexibility to define your own NSX-T topology. In other words, the supported migration topologies that are explained in the End-to-End Migration of NSX Data Center for vSphere section of this Guide are not relevant for this in-place migration.

You can have vSphere High Availability (HA) enabled if the NSX-v environment has VDS 7.0 or later. If the NSX-v environment has VDS 6.5 or 6.7, and the vmkernel ports (vmks) are attached to VDSes, during an in-place migration, the hosts and VMs may lose network connectivity for a period of time log enough to trigger HA. The HA mechanism will try to power off, migrate and restart VMs. This might fail because the NSX-v environment is being migrated to NSX-v. As a result, after the migration, VMs might remain in a powered-off state or have no network connectivity if powered on. To avoid this situation, disable HA or attach the management vmk to a VSS before starting the migration to NSX-T.

Note: Logical ports and switches that are created during migration are not deleted when the workload VMs are deleted. You must delete these ports and switches via the NSX Manager UI or the API.