Classify migration complexity

In the initial stage, the complexity of the migration is estimated. An aspect of this complexity is based on the source environment. Therefore, a review of the current NSX-V environment must be undertaken and documented so the following details are understood:

• Logical network topology - A series of diagrams that document the external and internal networking.
• Logical networking and security configurations - Detailed parameters that are used in the configuration of the NSX-V network and security. Logical switches, routing, distributed firewall, edge firewall, NAT, VPNs, and load balancing are included.
• Clusters and hosts - Information on the clusters and their hosts.
• Workload virtual machines - Placement of VMs, and their relationships to each other.
• Integration - External tools that integrate with vCenter or NSX-V Manager, such as Veeam®, VMware Aria® Operations™ Manager, VMware Aria® Automation™, custom scripts, and other tools.

The following factors govern the complexity of migration:

• Project-based factors - such as how is the project that is being staffed.
• Architecture factors - such as changes to the existing NSX-V environment since deployment.
• Micro-segmentation factors - such as the use of distributed firewall rules and the use of tagging in these rules.
• Integration factors - what systems are integrating with NSX-V Manager and vCenter as both these components are replaced in the migration. Integrated systems can include VMware Aria Automation, VMware Aria Operations, VMware Aria Orchestrator, SEIM or security tools, backup and recovery, replication, F5, vSRX, FortiGate, or other third-party network applications.

For more information, see Assess migration complexity.

Classifying or assessing the migration complexity provides guidance so that you can estimate the migration time frame, required tools, skills and knowledge, and to help you prepare in the best possible way.

Required skills

When you assess the complexity, you must focus on skills and resource availability. You must assess:

• If existing resources have time to participate in migration activities while they are delivering their existing duties.
• If existing resources have the skills, knowledge and experience that are needed to successfully deliver the required tasks.

If it is deemed that in-house skills need to be supplemented, then it is advised to engage a migration services provider as soon as possible.

In addition, to ensure successful Day 2 operations, improve the core VMware NSX-T™ skills by using the available VMware Learning for NSX-T education.

Engage a migration services provider

You can engage PrimaryIO’s experienced Professional Services team through the IBM catalog. For more information, see VMware Cloud Migration Services.

PrimaryIO’s Fasttrack Migration Service is optimized to move customers away from NSX-V and onto NSX-T through short-form engagements that continually drive progress by focusing on critical path objectives.

Source environment complexity patterns

The output of the Assess migration complexity step is a complexity status of low, medium, or high.

This status can be used to help the selection as follows:

• A target platform.
• A configuration migration pattern.
• A workload migration pattern.
• A network L2 extension pattern.

You are not able to neatly classify every source environment due to the multiple number of variations. Also, client requirements into one of these three categories by a set of rules or a defined set of parameters. Therefore, an analytical approach is required with a consensus gained across your team.

Target platforms

Based on the source environment complexity, you must consider the following target platform:

• Single site VMware VCF for Classic - Automated® instance - An automated provisioning offering that deploys hardware and software in a defined pattern. After initial deployment, you must add capacity and extra services to a number of automated workflows as needed. For more information, see VCF for Classic - Automated overview. The types of VCF for Classic - Automated instances include:
  • Regulated Workloads. For more information, see VMware Regulated Workloads overview.
  • Security and Compliance Readiness Bundle. For more information, see Security and Compliance Readiness Bundle overview.
• Multisite or location VCF for Classic - Automated instance - The VCF for Classic - Automated offering can be deployed in multiple locations to create a multisite or location VCF for Classic - Automated instance. The VCF for Classic - Automated multisite deployment pattern is two or more instances that are deployed into a common root domain and single sign-on domain with vCenters in Enhanced Link Mode. Each site or location has its own NSX-T instance. For more information, see Multisite configuration for VCF for Classic - Automated instances.

The VCF for Classic - Automated multizone offering is now deprecated. For more information, see VCF for Classic - Automated multizone BOM.

For more information about comparisons of the previous available offerings to enable a selection, see Target platforms in IBM Cloud.

Configuration migration

Configuration migration covers all the NSX-V settings and parameters that must be transferred to the NSX-T environment to provide similar functions of the NSX-V environment. Configurations can be applied by one of the following approaches:

• Manual or scripted
• VMware Migration Coordinator
• Third-party tool

If the configurations are simple, or don't have too many rules or definitions, manual, or scripted is typically the simplest way to migrate the configuration. A benefit of following this approach is also that you have a better understanding of how the target is configured. If the configurations are complex or have many firewall rules, consider the use of a third-party tool to ease up duplicate manual work.

Workload migration

After the configuration migration, the workload VMs can be migrated by using either a Layer 3 or Layer 2 connection between workload VMs awaiting migration on the NSX-V environment. Also, those workload VMs that migrated to the NSX-T environment. To migrate your workloads from NSX-V to the NSX-T environment, consider the following steps:

• Bridge the NSX-T and NSX-V overlays and use the available L2 extension methods, by allowing for gradual migration of individual or small batches of VMs.
• Migrate all the VMs on a subnet by using your preferred migration method or tool and move the default gateway to NSX-T.

Considerations include the following questions:

• Do you need to move workload VM with or without limited downtime?
• Do you need to move workload VMs individually or in small batches but cannot move a subnet at a time?
• Do you need to extend Layer 2 between the existing and new VCF for Classic - Automated environments?
  • How many networks do you need to extend at one time?
  • Do you need high availability?
  • How much spare capacity do you have on the NSX-V prepared host to deploy the required number of NSX-T Edge node VMs for L2 Bridge edge VMs?

The following migration patterns for workload migration must be considered:

• HCX™ - VMware HCX application migration enables the scheduling and migration of thousands of VMs. For more information, see VMware HCX Migration Types.
• Advanced vCenter vMotion - From vSphere 7.0 Update 1c (Patch 02), vCenter supports the import of VMs from another VCF for Classic - Automated that is not part of the same SSO Domain. The source VCF for Classic - Automated must be version 6.5 or later. For more information, see Introducing the Advanced Cross vCenter Server vMotion Capability.
• Zerto or Veeam® - You might have Zerto or Veeam installed on your NAX-V environment and be competent in their usage. These products can be used to replicate VMs from the source data store to the target data store and then initiate a fail-over. And also to replicate a backup from the source cluster to a recovery on the target cluster.

Network L2 extension

From a network perspective, the requirement for Layer 3 and Layer 2 connectivity during the migration must be understood. The L2 extension allows bridging the NSX-T logical switches to NSX-T segments. You can move the workloads between the NSX-V and NSX-T environments, while you keep the default gateway either on the NSX-V or move it to the new NSX-T. This action allows a smoother network migration. However, it is not mandatory if your environment can tolerate downtime.

Consider the following details for Layer 3 network migration:

• VM by VM migration – This approach moves one VM at a time and the /32 route for that host is injected into the NSX-T environment. Therefore, a specific route is defined to this IP address to the NSX-T environment while all other IP addresses in the subnet are still routed to the NSX-V environment.
• Subnet by subnet migration – This approach moves all the VMs on a subnet at a time. The subnet is advertised out of the NSX-T environment and not advertised from the NSX-V environment.
• Big-bang - All subnets and their connected VMs are moved and then all subnets advertised from the NSX-T environment.

Consider the following details for Layer 2 network extension during migration:

• NSX-T L2 bridge - In this approach an NSX-T Edge VM or preferably a pair of NSX-T Edge VMs, are deployed on the NSX-V prepared hosts. These Edge VMs are registered with NSX-T Manager and an L2 Bridge is configured to connect the required NSX-V VXLAN (virtual wire) to an NSX-T segment. For more information, see Migration that uses vMotion or third-party tools and NSX-T L2 bridge.
• VMware HCX - VMware HCX is a solution that is primarily used for migrating workloads between environments, and consists of a number of services to achieve workload mobility. HCX integrates into both NSX-V and NSX-T. HCX Network Extension (NCX-NE) allows simultaneous bridging of multiple networks. The solution is useful in cases where the applications are spread across multiple segments and need inter-app connectivity for extended periods of time during the migration. Using HCX allows bridging of eight segments at a time per HCX-NE pair. This action is especially useful if a workload spans multiple segments. For more information, see Workload migration with HCX.

A third possible Layer 2 approach is to use NSX-T L2VPN. In this approach, the NSX-V environment acts as the L2VPN client and the NSX-T environment acts as the L2VPN server. The L2 VPN connection is secured with a route-based IPsec tunnel between the L2 VPN server and the L2 VPN client. This approach is not recommended in IBM Cloud between two VCF for Classic - Automated instances for V2T migration as NSX-T L2 Bridge offers better performance. And also because IBM Cloud private network supports large MTU (jumbo frames).

Related links

• VMware Cloud Migration Services
• NSX-T Data Center Migration Guide
• Terraform by Hashicorp
• The NSX Terraform Provider
• NSX-V to NSX-T fast track migration service