1. Introduction
2. Prequisite
3. Migration Work Flow
4. Conclusion

Introduction

In the complex landscape of data center transformation, migrating to VMware Cloud Foundation (VCF) requires strategic precision. Central to this endeavor is the enhanced Migration Planning feature within VMware Aria Operations for Networks (vRNI). This powerful capability is specifically engineered to facilitate a seamless transition for workloads and infrastructure from non-VCF environments into your VCF deployment. By natively leveraging vRNI’s intelligent application discovery and dependency mapping, this feature provides a robust foundation for building well-structured migration plans. Further amplifying this power, VMware Aria Operations for Networks 6.14 introduces a dedicated Migration Planning dashboard. This intuitive interface empowers users to efficiently organize migration waves and define logical mobility groups. Crucially, these meticulously planned groups can then be seamlessly exported and integrated directly into VMware HCX 4.11, bridging the gap between comprehensive planning and flawless execution.

Prequisite

Capture 1: –

Before diving into the migration process, ensure you have the following in place:

• VMware HCX Deployment: Both Source and Destination HCX Managers (4.11) are deployed, activated, and paired successfully.
• HCX Service Mesh: A robust Service Mesh is configured, including HCX Interconnect, WAN Optimization, Mobility Optimized Networking (MON), and Layer 2 Extension (L2E) services as per your network design.
• VMware Aria Operations for Networks (vRNI): vRNI 6.14 is deployed, configured, and collecting data from your source vCenter Server(s).
• Network Connectivity: All required network paths between source and destination environments are open and verified.
• VMware Tools: Ensure VMware Tools are up-to-date on all VMs targeted for migration.
• Permissions: Necessary administrative permissions on both vCenter Servers, HCX Managers, and vRNI.

Migration Work Flow

Capture 1: –

Successfully navigating a data center migration requires a structured approach. By following these 10 essential steps, you can leverage the power of vRNI and HCX to ensure a predictable and efficient transition for your workloads:

1. Assess Workload Portfolio: Begin by thoroughly examining and evaluating all workloads within your environment to identify those best suited for migration to VCF.
2. Define Strategic Migration Plan & Criteria: Formulate a detailed migration plan by systematically categorizing suitable workloads using key criteria such as Application, Cluster, VM Tags, Host, VM Name, and vCenter associations (Datacenter, Manager).
3. Organize Workloads into Migration Waves & Mobility Groups: Group your selected workloads into distinct migration waves based on your plan’s scope. Within each wave, organize VMs into Mobility Groups to facilitate concurrent and orchestrated migrations.
4. Export Planned Migration Data from vRNI: Utilize vRNI to export the categorized workload and network dependency data in CSV format, preparing it for seamless import into HCX.
5. Import Migration Wave into HCX Manager: Import the exported workload data CSV (and network dependencies, if applicable) into the HCX Manager (destination side). This initiates the migration wave within the HCX platform.
6. Validate & Commit Mobility Groups: Conduct a thorough validation of all workloads within each Mobility Group. Once satisfied with the grouping and initial data, confidently “Commit” these Mobility Groups within HCX, signaling readiness for detailed configuration.
7. Configure Migration Settings & Schedule Windows: Optimize each Mobility Group by precisely configuring migration and placement options (e.g., target compute, storage, network, migration type). Crucially, establish clear transfer and switchover windows to minimize disruption and ensure a smooth cutover.
8. Execute Pre-Migration Checks: Before initiating transfers, run comprehensive pre-migration checks within HCX. This vital step validates workload connectivity, resource availability, and the optimal health of your HCX Service Mesh, proactively identifying and resolving potential issues.
9. Initiate Workload Migrations: With all prerequisites met and checks passed, proceed to initiate the workload migrations as defined in your wave. Monitor progress closely within the HCX interface.
10. Perform Post-Migration Validation & Activities: Once migrations are complete, conduct thorough post-migration validation of all applications and services. Finalize essential tasks such as DNS updates, monitoring system adjustments, and eventual decommissioning of source resources.

1. Create a Migration Plan

Capture 1: –

Note:- Login to VCF Aria Operations for Networks.

1. Navigate to Plan & Assess.
2. Click on Migration Planning.

Capture 2: –

3. Click on Create Plan.

Capture 3: –

4. Gives the Name of the Plan.

5. Gives the Description of the Plan.

6. Click on Proceed.

2. Add VM Attributes

Capture 1: –

1. Click on Add VM Attributes.

Capture 2: –

2. Click on Upload.

Capture 3: –

Note:- Follow the Mandatory columns and content rules before creating the CSV file.

Format of CSV File

Mandatory Columns

The `vc_ip` attribute refers to the specific IP address/FQDN assigned to the vCenter instance that is responsible for managing the virtual machine (VM). This address is crucial for establishing network connectivity and communication with the vCenter server where the VM operates.

the `vm_moref` attribute denotes the unique Vendor ID associated with the VM within the vCenter instance. This identifier is essential for accurate tracking and management of virtual machines in the vCenter environment. You can find the Vendor ID by navigating to the entity details section of the VM in the VCF Aria Operations for Networks , which provides comprehensive information about the VM’s configuration and status.

3. Click on Browse and Upload the CSV file.

4. Click on Upload and Proceed.

Capture 4: –

5. Status seems Completed.

Note:- Once you upload the CSV file, you will be greeted with a comprehensive overview that details the total number of virtual machines (VMs) identified. This insightful breakdown highlights how many of these VMs align perfectly with the new attributes and how many fall short of those standards. Additionally, any errors that occurred during the process will be clearly outlined, ensuring you have all the information you need at your fingertips.

Capture 5: –

Note: -To continue working on your migration plan, navigate to back to Plan and Access–>Migration Planning and select your migration plan.

6. click on pencil to edit the Plan Name-VCF-Migration-01.

3. Define the Migration Scope

Capture 1: –

Note: – This will empower us to access a diverse range of selections, allowing us to navigate through applications, clusters, tags, environments, virtual machine names, locations, data centers, and management options. With a multitude of filtering capabilities at our fingertips, we can precisely hone in on specific data centers, management resources, and various other criteria, ensuring a tailored and efficient approach to our decision-making process.

1. We are selecting the applications(WEB-Development, PROD-Application and APP-Development).
2. Under Name we are selecting the VM’s by name. Total 06 VMs are selected.
   Note:- Application tab after the name will show the Dependent applications of the selected VMs.
3. Click on ADD to Scope.

Capture 2: –

4. click on IN SCOPE.

Note: – Now these 06 Entities are part of the Migration scope. We can remove any entity from scope. To do this just click on Action–> Remove From Scope. We can also export the IN SCOPE entities as a CSV Format for further validation.

Capture 3: –

5. Click on Network Dependencies.

6. Click on Out of Scope.

Note:- You may examine any identified out-of-scope virtual machines that are categorized as dependencies and include them in the current migration scope.

7. Under the In Scope VM tab will show the VMs which are part of the Migration Planning.

8. Out of Scope (VM/IP) will show you those IP/VMs which are not the part of application migration.

9. Direction will show you the traffic flow directions type (Incoming/Outgoing).

10. In Scope applications will show you the Application names of corresponding In Scope VM.

11. Out of Scope Applications will show those application which are not related to In Scope Applications.

12. Flow will show the communication between the In Scope VM and In Scope Applications.

13. Total Traffic Sum will show you the traffic flow in Sum Form(KB, MB or GB).

14. Total Traffic Rate will show you the traffic flow in Avg form (BPS).

15. Action tab will help us as below

To add VMs in the current scope then we will use Add to Scope Option.

If we want to remove the VMs from the current scope then we will use Remove from Scope Option.

If we want to export the Current Scoping the we will use the Export as CSV option.

Note: – Navigate to the In Scope tab to explore the virtual machines currently included in your migration plan. Here, you’ll find a detailed list of each VM you’ve selected, ready for transfer, showcasing the vital components of your migration strategy.

Capture 4: –

16. VM Changes option will show you count of VM if you Add or Remove from the Scope.

17. Click on Done.

4. Create A Migration Wave

Capture 1: –

1. Click on Create Migration Wave.

Capture 2: –

2. Select the VMs from the Name Tab.

Note: – It is important to note that only virtual machines (VMs) from the same vCenter instance may be included in a specific migration wave. Any portions of your workload residing on different vCenter instances must be allocated to separate migration waves.

3. Click on Action drop down.

4. click on Create New Migration Wave.

Capture 3: –

5. Give the name of Migration Wave.

6. Corresponding vCenter will auto popup in the manager.

7. Give the description.

8. Click on Proceed.

Capture 4: –

9. Click on Migration Waves(1)

10. Select your Migration wave from the tab.

11. We can see the VMs those are part of the migration wave.

12. If we want to make any changes then select the modify or if you want to remove any VM from the migration wave then click on delete or if you want to remove this migration wave then click on action–> remove Migration wave .

13. Click on Done.

Capture 5: –

14. If you want to modify the migration wave click on pencil icon.

15. If you want to make some changes in the current migration wave click on Edit.

5. Create Mobility Group: –

Capture 1: –

1. Click on Create Mobility Group.

Capture 2: –

2. Select your migration wave.

3. Select the Vms.

4. Click on Acton drop down.

5. Click on Create New mobility Group.

Capture 3: –

6. Give the name of the Mobility Group.

7. Give the Description of the Mobility Group.

8. Click on Proceed.

Capture 4: –

9. We can see the name of the migration wave, corresponding vCenter, Mobility Group and the Description.

10. Select the VMs.

11. If you want to remove any VM from this group then click on Actions –>Remove From Group.

12. If you want to add any VM in the group then click on Modify or if you want to delete this group then click on Delete.

13. Click on Done.

6. Export Migration Waves

Capture 1: –

1. Select the Export Migration Wave.
2. Click on Edit if we make any changes.
3. Click on the Arrow ICON and then click on export as CSV.
   Note:- Don’t be misled by the name change from Migration Wave 1 to Migration Wave 11; both waves contain the same information.

Capture 2: –

4. Click on Save to save the tar.gz file.

Note:- Export as CSV file are encapulated format as a tar.gz file.

Capture 3: –

5. Execution.info.csv is the Workload Data File.

Note:- This document contains detailed information regarding each workload involved in the migration wave. It includes the VMware vCenter Server that hosts the workload, the designation of the migration wave, and the associated Mobility Group for the workload.

6. vm-network-info.csv is the Network Dependencies File.

Note:- The network dependencies file serves as a vital blueprint, outlining the networks connected to workloads within the vCenter Server. While it is optional for the initial import of migration wave workloads, it can be integrated later to ensure all network connections are accounted for as the migration progresses.

Having successfully navigated the intricacies of the Aria Operation for network tasks, we now stand on the brink of a new phase: the transition to HCX via a Migration Wave. However, before embarking on this journey, it is crucial that we ensure full compliance with the established prerequisites for HCX, laying a solid foundation for a seamless migration experience.

7. Import the Migration Wave

Capture 1: –

1. Navigate to Migration Planning under Services.
2. Click on + Import Migration Wave.

Capture 2: –

3. Select the destination HCX Manager from the drop down. vCenter FQDN will auto populate.

4. Browse and upload the Workload data CSV File.

5. Browse and upload the Network dependencies CSV File.

6. Click on Import Migration Wave.

Capture 3: –

7. Click on View Details.

Capture 4: –

8. Click on Migrations.

9. Select the Mobility Group.

Note:- check your workload details with their corresponding application groups and compute resources. Status should be validated. If their is any issue then click on actions and click on edit.

Capture 5: –

10. Click on Network Extensions.

Note: – Here we can see the connected networks of the VM and extension Status.

8. Commit Migration Wave.

Capture 1: –

1. Click on Commit Migration Wave.

Capture 2: –

2. Click on Commit.

Capture 3: –

3. Status should be Committed.

Note:- Once the status is committed , the action drop down area is Greyed Out.

9. Configure and Schedule the Mobility Group & Pre Validation.

Capture 1: –

1. Navigate to Migration under Services.
2. Click on Mobility Groups.
3. click on 3 Dots in front of the Mobility group name.
4. click on Edit Mobility Group.
   Note:-If you want schedule the migration then click on the Edit migration Schedule, like wise you can use the retry mingrations and delete mobility group.

Capture 2: –

5. Select the group Transfer and Placement adn gives the necessary details.

6. Select the Switchover details.

7. Select the Interconnect Service Mesh.

8. Click on Validate.

Note:- if any errors occur during validation then resolve before moving to step 8.

8. click on Save.

Note:- Below is the Mind map for configuring and Schedule the mobility group and Pre-Validation.

10. Run Migration with Break Down Beckend Steps

Capture 1: –

1. Click on GO.

Here’s a breakdown of the steps running in the backend from HCX Site A (Source) to HCX Site B (Destination) when we initiate an HCX Replication Assisted vMotion:

Phase 1: Migration Initiation & Configuration

1. User Request: The user selects a VM in the HCX UI (usually on the destination HCX Manager), chooses the “Replication Assisted vMotion” method, and specifies target compute, storage, and network resources.
2. Orchestration Request: The destination HCX Manager receives the request and communicates it to the source HCX Manager.
3. Source HCX Preparation: The source HCX Manager identifies the VM, its associated disks, and the source ESXi host. It prepares the VM for replication.

Phase 2: Initial Replication (Bulk Data Transfer)

4. Temporary Snapshot: On the source vCenter/ESXi host, a temporary, non-quiesced snapshot is taken of the source VM. This provides a consistent point in time for the initial full copy and allows the VM to continue running normally.
5. Block-Level Copy (HCX-REP):
   • The source HCX Replication appliance (in Site A) connects to the source VM’s virtual disks.
   • It begins a full block-level copy of all allocated blocks from the source VM’s disks.
   • This data is sent over the secure, optimized tunnel established by the HCX Interconnect appliances to the destination HCX Replication appliance (in Site B).
   • The destination HCX Replication appliance writes these blocks to newly provisioned virtual disks on the specified target datastore in Site B.
6. CBT Activation: During this phase (or just before), Change Block Tracking (CBT) is engaged on the source VM’s disks to track all ongoing changes.
7. Snapshot Removal: Once the initial full copy is complete, the temporary snapshot on the source VM is committed/removed. The VM continues to run from its base disks.

Phase 3: Delta Replication (Continuous Synchronization)

8. Continuous Sync: The HCX Replication appliances continuously monitor for and replicate only the changed blocks (deltas) from the source VM’s disks to the destination VM’s disks, leveraging CBT.
9. Low Latency Data Flow: This delta synchronization occurs in near real-time, keeping the destination VM’s disks highly synchronized with the source VM. This phase runs for as long as needed until the migration is ready for cutover. The source VM remains fully operational.

Phase 4: Quiescence, Final Sync & Memory Transfer (The “vMotion” Phase)

10. Scheduled Cutover Window: At the pre-defined cutover time (or when manually initiated by the user), the system begins the final phase, which involves brief downtime.
11. VM Quiescence: HCX signals the source vCenter to quiesce the source VM.
    • If VMware Tools are present and configured for application-aware quiescing, the VM’s applications are prepared for a consistent state.
    • A final, quiesced snapshot is taken. This momentarily pauses or slows down I/O to ensure data integrity.
12. Final Delta Replication: A very rapid, final block-level replication of any remaining changes since the last continuous sync occurs. This typically takes only seconds or a few minutes, as the delta is very small due to continuous synchronization.
13. Memory State Transfer (vMotion Core): Immediately following the final disk synchronization, HCX triggers the traditional vMotion memory transfer. The source VM’s active memory state is copied to the destination ESXi host. During this short window, the source VM is momentarily stunned or paused.

Phase 5: Switchover and Activation at Destination

14. Source VM Powered Off: The source VM is powered off (or de-registered) from the source ESXi host/vCenter.
15. Destination VM Activation: The destination VM, now fully constituted with its replicated disks and transferred memory state, is powered on or resumed on the target ESXi host in Site B.
16. Network Cutover:
    • If L2E is used: The VM’s MAC address is announced on the destination network segment. The source network’s ARP cache is updated, effectively “moving” the VM’s network presence to Site B without an IP address change.
    • If New Network: The VM will connect to its new network. If DHCP, it will get a new IP. If static, the IP might need to be changed post-migration.
17. Source VM “Stale”: The original source VM (its files) remain on the source storage but are typically unregistered or marked as “stale” by HCX.

Phase 6: Post-Migration Cleanup

18. User Validation: The user validates the functionality of the migrated VM in Site B.
19. Source VM Cleanup: Once validated, the user can initiate the cleanup process in HCX, which will remove the stale VM files from the source vCenter and datastore.

11. Validation

1. HCX Validation: –

Capture 1: –

1. Navigate to Activity logs under Administration.

Note :- We can view the status of migration.

Capture 2: –

2. Navigate to Migration under Services we can see the status Completed.

2. NSX Validation

Capture 1: –

We can validate Migrated VMs from Source DVPG to Destination NSX-Segments connected with the help of layer 2 extension.

3. Destination vCenter Validation: –

Capture 1: –

Note : – In my lab setup, vCenter B is the source, and vCenter A is the destination. According to capture 1, we can see that the VMs have been successfully migrated.

Conclusion

vRNI for Planning + HCX for Execution = Predictable, Efficient, Low-Risk Migrations.
Our journey through this migration blueprint has illuminated a clear path to successful data center transformation, highlighting the critical roles of VCF Network Operations and HCX. We’ve seen firsthand how VMware Aria Operations for Networks (vRNI) 6.14 provides the indispensable intelligence layer, leveraging its advanced application discovery and dependency mapping to inform every strategic decision. This meticulous planning, organized through its dedicated dashboard and readily available CSV exports, forms a robust foundation for building predictable migration waves and mitigating inherent risks.

This intelligence then seamlessly transitions to VMware HCX 4.11, the powerful execution engine that transforms the blueprint into actionable implementation. From committing waves and configuring mobility groups with precise placement, to strategically scheduling transfer windows and executing rigorous pre-migration checks, HCX orchestrates a smooth transition. Its robust capabilities ensure the secure, optimized, and controlled execution of migrations, followed by essential post-migration validation, bringing your workloads safely to their new VCF home.

Ultimately, the inherent synergy between vRNI for intelligent, data-driven planning and HCX for robust, efficient execution delivers precisely what enterprises demand: predictable, efficient, and low-risk migrations. This integrated approach empowers organizations to confidently accelerate their journey to a modern, agile VCF infrastructure with minimal disruption and maximum operational success.

Please find attached the complete mind map of migration.