IBM Cloud Docs
NSX-V to NSX-T lift-and-shift migration approach

NSX-V to NSX-T lift-and-shift migration approach

VMware NSX-V to VMware NSX-T™ migration in IBM Cloud® is done by following the VMware® lift-and-shift migration model. In this model, you deploy a new NSX-T infrastructure on new server hardware so you can benefit from the Cloud consumption model.

In IBM Cloud, you need to deploy a new VCF for Classic - Automated with NSX-T instance, which then runs in parallel with the existing VCF for Classic - Automated with NSX-V instance. The NSX-T architecture is different than the NSX-V architecture, though they share similar concepts for overlay networking, distributed routing, and firewalling.

NSX-V to NSX-T lift–and-shift migration approach
NSX-V to NSX-T lift–and-shift migration approach

  1. Your existing NSX-V based instance was deployed previously and it hosts the current workloads and NSX-V network configurations. Before you start the migration, you need to have a thorough understanding of the environment, the workloads that are deployed on it, and the NSX-V and underlay network configurations.
  2. Before you deploy a new NSX-T based VCF for Classic - Automated target, analyze your capacity needs. Optimize and size your new hosts and clusters by using the most recent hardware options available in IBM Cloud. Check the options in the VMware Solutions console, or contact your IBM Sales representative for more details.
  3. You can deploy the new VCF for Classic - Automated with NSX-T instance in new VLANs and a new pod, or you can use existing VLANs. 25GE NICs might not be available on the same pod. Also, you cannot move the subnets between VLANs, if, for example, you need to reuse the public IP addresses. Analyze your networking needs and then decide.
  4. Migrate your network configurations from NSX-V to NSX-T. As the NSX-T architecture is different, you have the opportunity to design and implement the overlay network and configurations based on NSX-T best practices. NSX-T offers scripting capabilities or you can use Terraform to define your topology. You can alternatively use NSX-T Migration Coordination tool or third-party tools to migrate your existing network configurations, firewall, and load-balancing rules.
  5. To minimize network downtime, the L2 extension is typically used between NSX-V logical switches and NSX-T overlay segments. You can use either NSX-T Bridging or HCX™ Network Extension here. HCX provides tools for bulk and vMotion migrations, too.
  6. After your network configurations are migrated or prepared for migration, you can start to migrate your workloads between the environments. Here you have a choice of various methods. With HCX, you have a single tool to do both L2 extension and migration. You can also use Advanced vMotion and storage vMotion between the environments. In addition, you can use services and tools from Zerto or Veeam.

When you deploy a new VCF for Classic - Automated with NSX-T instance, you get a new Active Directory (AD). If you customized your AD, you must migrate these changes to the AD of the new instance.

In your VM migration between the NSX-V and NSX-T environments, the new VCF for Classic - Automated instance is provisioned with new storage, both vSAN and NFS.

Considerations for NSX-V to NSX-T migration

To ensure that your migration is seamless and to minimize the downtime, design the migration and its phases and waves carefully. Due to the differences in the architecture, you can redesign parts of your network instead of just mirroring the configurations to best match your requirements and NSX-T best practices.

If needed, you can get help from various service providers. For example, the IBM Cloud partner PrimaryIO provides an optional pro service to help you accelerate your NSX-V to NSX-T migration.