HYCU Migration Path — Runbook¶

Step-by-step migration runbook using HYCU. Execute one batch of 8–10 VMs at a time.

Section 1 — HYCU Setup¶

1.1 Deploy HYCU Controller VM¶

Download the HYCU appliance image (QCOW2 for AHV) from the HYCU customer portal
In Prism, create a new VM: 4 vCPU, 8 GB RAM, 256 GB disk
Assign a static IP on the management VLAN; verify DNS resolution in both directions
Power on the VM — HYCU boots within a few minutes
Open a browser: https://<hycu-ip>:8443
Set admin password, accept EULA, apply your HYCU license key

1.2 Add Nutanix Cluster as Source¶

Nutanix AHVNutanix ESXi

In HYCU web console → Administration → Sources → Add Source
Select Nutanix AHV
Enter Prism Element cluster VIP or FQDN
Provide Nutanix Cluster Admin credentials
HYCU validates connectivity and auto-discovers all VMs, volume groups, and Nutanix Files shares
Verify VM inventory shows the expected count

In HYCU web console → Administration → Sources → Add Source
Select VMware vSphere
Enter vCenter or ESXi FQDN
Provide vSphere service account credentials
HYCU discovers all VMs managed by vCenter

1.3 Configure Backup Target¶

HYCU console → Administration → Targets → Add Target
Select target type (SMB, NFS, S3, or iSCSI) and provide connection details and credentials
Test the connection and save
Size the target for the total used disk of the concurrent batch + 20% overhead

1.4 Register Hyper-V Host as Restore Target¶

HYCU console → Administration → Targets → Add Target
Select Microsoft Hyper-V
Enter Hyper-V host FQDN and provide domain or local admin credentials
HYCU discovers available storage paths and virtual switches on the Hyper-V host
Set the default restore path (e.g., D:\Restored) and default virtual switch
Verify the connection shows healthy

Section 2 — Create Backup Policies (Per Batch)¶

HYCU console → Policies → Create Policy
Name: Use MIG-Batch01-VMs001-010, MIG-Batch02-VMs011-020, etc.
Assign VMs: Select exactly 8–10 VMs for this batch
Schedule: Daily incrementals; set a manual or scheduled full backup time
Retention: Keep at least the latest restore point (short retention is fine for migration-only use)
Run Initial Full Backup: Trigger the first full backup immediately. Monitor progress.

Initial full backup time varies with VM disk size and backup target bandwidth (typically 2–12 hours per batch on first run).

Section 3 — Hop 1 Cutover Procedure (Per Batch)¶

Do not delete source VMs

Source Nutanix VMs are your rollback point. Do NOT decommission them until the batch is fully validated on Azure Local.

Hop 1 downtime starts at VM power-off and ends when the restored VM is running and validated on Hyper-V

Typical Hop 1 downtime: 30 minutes to 4+ hours per VM depending on disk size and storage throughput. Plan approximately 1 hour per 200 GB of VM used disk at 10 GbE speeds. Establish your baseline in the PoC.

3.1 Pre-Cutover¶

Notify stakeholders — maintenance window begins for this batch
Trigger a manual incremental backup to capture the latest changes
Wait for the incremental to complete successfully

3.2 Cutover Steps¶

Power off source VMs on Nutanix (in Prism or vCenter)
Trigger one more manual incremental backup to capture final dirty blocks from shutdown
Restore to Hyper-V:
- In HYCU console, select each VM → Restore → Restore to Hyper-V
- Select the Hyper-V staging host registered in step 1.4
- Select the restore storage path and virtual switch
- HYCU automatically converts disk format to VHDX during restore
Monitor restore progress in the HYCU console
Power on the restored VMs on Hyper-V

3.3 Re-IP After Restore (If Subnets Differ)¶

HYCU does not have built-in re-IP rules

Unlike Veeam, HYCU does not inject new IP addresses during restore. If your Hyper-V staging network uses different subnets, apply IP changes immediately after the VM boots on Hyper-V — before running the validation checks or proceeding to Hop 2.

# Example: Update IP post-restore (Windows)
Set-NetIPAddress -InterfaceAlias "Ethernet" -IPAddress "10.0.2.50" -PrefixLength 24
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses "10.0.0.10"

For Linux VMs, update /etc/netplan/*.yaml or the appropriate network config file for the distro.

3.4 Hop 1 Completion Gate¶

Stop here — do not proceed to Hop 2 until all Hop 1 validation checks pass

See Hop 1 Go / No-Go Sign-off for the full checklist. Each VM must be independently validated.

3.5 Rollback (If Needed)¶

If Hyper-V validation fails:

Power off the restored Hyper-V VMs
Delete the restored VMs from the Hyper-V host
Power the source Nutanix VMs back on in Prism/vCenter
Investigate the issue, adjust, and retry the restore

Section 4 — Azure Migrate Setup (Hop 2)¶

Azure Migrate for Azure Local is in Preview

The native Hyper-V → Azure Local migration path via Azure Migrate uses a dual appliance architecture and is currently in Preview (requires Azure Local 2503+). Both a source appliance (on the Hyper-V host) and a target appliance (on the Azure Local cluster) are required. Data does not leave your datacenter.

4.1 Prepare Azure Local Prerequisites¶

Before deploying appliances, confirm on the Azure Local cluster:

Azure Local instance deployed, Arc-registered, and healthy
A custom storage path created for the Arc resource bridge (VM configuration and OS disks)
A logical network created for the Arc resource bridge for migrated VMs
Contributor + User Access Administrator roles granted on the subscription for the Azure Migrate project

4.2 Create Azure Migrate Project¶

Azure portal → Azure Migrate → Create Project
Project name: use IIC naming (e.g., nutanix-to-azl-migration)
Subscription: tied to Azure Local cluster registration
Resource Group: rg-iic-migration-01

4.3 Deploy the Source Appliance (Hyper-V Host)¶

Azure Migrate → Discover → select Hyper-V and Azure Local as the target
Download the Azure Migrate source appliance VHD (16 GB RAM, 8 vCPU, 80 GB disk)
Create a VM on the Hyper-V staging host using this VHD
Boot and configure via browser wizard on port 44368
Register with the Azure Migrate project key
Add Hyper-V host credentials; start discovery

4.4 Deploy the Target Appliance (Azure Local Cluster)¶

In Azure Migrate project → Deploy target appliance
Download and deploy the Azure Migrate target appliance on the Azure Local cluster
Register the target appliance with the same project key
Associate with the Azure Local custom location, storage path, and logical network
Verify both appliances show as Connected in the Azure Migrate portal

Section 5 — Azure Migrate Replication and Cutover (Hop 2)¶

Hop 2 downtime starts when VMs are shut down for final delta sync and ends when Azure Local VMs pass validation

Typical cutover downtime: 30–60 minutes per batch of 10 VMs.

5.1 Start Replication¶

Azure Migrate → Replicate → Source: Hyper-V | Target: Azure Local
Select Azure Local cluster, custom storage path, and logical network
Select the 10 restored Hyper-V VMs; set target VM names (original names); set virtual switch
Click Replicate — wait for Protected state (initial replication runs in background; VMs stay running on Hyper-V)

5.2 Test Migration¶

Select all 10 VMs → Test Migration → select isolated test network
Validate all VMs (see Hop 2 Validation)
Clean up test migration after validation

5.3 Production Cutover¶

Downtime begins here for Hop 2

Azure Migrate shuts down the Hyper-V VMs, performs a final delta sync, then creates Azure Local VMs. Expected time: 30–60 minutes per batch of 10 VMs.

Select all 10 VMs → Migrate
Toggle Shutdown VMs before migration = Yes
Azure Migrate performs final delta sync and creates Azure Local VMs
Confirm VMs are visible in Azure portal as Azure Local VMs
Validate (see Hop 2 Validation)
Click Complete Migration

Section 6 — Cleanup¶

After the batch is fully validated on Azure Local:

Delete the restored Hyper-V VMs to free staging storage
Delete HYCU backup policies for this batch (or disable them) to free backup target storage
Begin the next batch (return to Section 2)
Source Nutanix VMs: keep powered off during the holding period; decommission after it expires

Batch Execution Tracker¶

Batch	VMs	Full Backup	Restore to HV	HV Validation	Azure Migrate	Azure Local	Status
Batch 01	VM001–VM010	—	—	—	—	—	Not Started
Batch 02	VM011–VM020	—	—	—	—	—	Not Started
Batch 03	VM021–VM030	—	—	—	—	—	Not Started
Batch 04–30	...	—	—	—	—	—	Not Started