Before you start
Capture the current state, preserve recoverable data and record recent changes before remediation. Use production-impacting commands only within an approved maintenance or change window.
Source discovery
Record VM name, OS, firmware mode, CPU, memory, every VMDK, controller, NIC, port group, VLAN, IP, gateway, DNS, snapshots, monitoring and backup dependencies.
Check the VMware snapshot chain before conversion. Never convert only a base VMDK when production data depends on snapshot delta disks.
Backup and rollback
Verify a recent recoverable backup and define the rollback point. Keep the VMware source intact until application validation and business sign-off are complete.
Do not power on both source and target copies with the same identity or IP unless the design explicitly supports it.
Hyper-V readiness
Verify Hyper-V role, host capacity, storage, virtual switch, VLANs and clustering if applicable.
Use Get-VMHost, Get-VMSwitch and Get-Volume to capture target capacity before conversion.
VMDK conversion
Shut down the source cleanly and confirm no backup or snapshot task is modifying it. Convert the active disk chain to VHDX with a supported tool.
Preserve source VMDKs until the converted VM passes validation. Maintain a disk mapping such as OS→Disk01, Data→Disk02.
Create and boot the target VM
Select Generation 1 for supported legacy BIOS workloads and Generation 2 for supported UEFI workloads. Attach VHDX files in the original logical order.
If the VM reports no boot device, check generation, firmware boot order and whether the converted disk contains the expected boot partition.
Network troubleshooting
After first boot, run Get-NetAdapter, Get-NetIPConfiguration and Get-NetRoute. Windows may retain a hidden VMware adapter with the old static IP.
Attach the VM NIC to the correct Hyper-V switch and VLAN. Test gateway, DNS and application ports separately.
Guest and application validation
Check Device Manager, services, disks, certificates, scheduled tasks and application listeners. Remove VMware-specific components only after Hyper-V hardware is stable.
Repeat the same business transaction used before migration. A successful Windows boot is not sufficient validation.
Rollback
If validation fails within the change window, shut down the Hyper-V copy and restore the VMware workload according to the approved procedure.
Document the root cause and retain the source until the agreed rollback period expires.
Hyper-V host
Get-VMHost
Get-VMSwitch
Get-VolumeTarget VM
Get-VM -Name 'VMNAME' | Format-Table Name,State,Generation,ProcessorCount,MemoryStartup
Get-VMHardDiskDrive -VMName 'VMNAME'Guest network
Get-NetAdapter
Get-NetIPConfiguration
Get-NetRoute -AddressFamily IPv4Troubleshooting validation
- Confirm the original symptom is resolved.
- Verify dependent services and application health.
- Review logs or command output for secondary errors.
- Document the root cause and corrective action.
- Retain rollback evidence until the change is accepted.
Frequently Asked Questions
What should I check first?
Capture the current state, exact error, affected scope and recent changes before making changes. Then test the failing layer from the lowest dependency upward.
How do I validate the fix?
Repeat the original failing operation, check dependent services and confirm the issue remains resolved after any required restart or service recovery.
Can this troubleshooting be automated?
Automate read-only diagnostics first. Add remediation only after commands, permissions, logging and rollback behavior have been validated.