Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.

This step prepares System Center Virtual Machine Manager (SCVMM, or VMM) to manage the Hyper-V destination and VMware source. It covers host groups, credentials, Hyper-V cluster and vCenter onboarding, networks, the VMM library, and readiness checks. It does not convert a VM; perform the V2V migration only after these checks pass.

These instructions follow the currently documented VMM 2025 workflow. Menu labels and supported Windows Server, vCenter, and ESXi versions depend on your exact VMM build, so confirm compatibility before changing a production environment. The earlier steps in this series should have prepared the Hyper-V hosts and cluster and installed VMM. See Microsoft’s VMM VMware integration guidance and Hyper-V host onboarding guidance.

Before you begin

Have the following details ready and record the exact software builds in your change plan. Do not assume an older VMM update package or a Windows Server version from a lab walkthrough applies to your deployment.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Item What to confirm
VMM VMM version and build, supported management-server operating system, and the update procedure for that build.
Hyper-V Supported Windows Server version, cluster and node names, DNS records, domain membership, and storage visibility on every node.
VMware Supported vCenter and ESXi versions, vCenter FQDN, certificate trust, and the datacenters, clusters, and hosts to expose to VMM.
Database and access SQL Server version and database placement, administrative access to VMM, and separate credentials for host, vCenter, and library operations.
Networks and capacity Source port groups and VLANs, destination logical and VM networks, storage capacity, and the intended mapping for each workload.
Recovery A current VMM database backup, tested workload backups, an approved maintenance window, and a defined rollback plan.

Use a lab, pilot, or production change process appropriate to the environment. Keep direct access to Hyper-V Failover Cluster Manager and vCenter available; VMM should not be your only route to either platform.

1. Organize the fabric with host groups

In the VMM console, create host groups that reflect how you will administer and place resources—not merely the order in which you discovered them. A simple starting structure is Hyper-V and VMware, with child groups such as Production, Test, or Migration-Pilot where they serve a real purpose.

Host groups organize fabric objects and can scope inherited settings, permissions, network availability, and placement. They do not move workloads or translate their configuration. Decide where each cluster or VMware inventory object belongs before onboarding it, especially if environments have different network sites, storage classifications, or administrative boundaries.

2. Create separate, controlled credentials

Use VMM Run As accounts to store credentials for operations that need them, but do not use one broadly privileged account for every system. Plan distinct identities for Hyper-V host management, vCenter access, library access, and any required domain or cluster operations. The VMM service account is a separate installation and service-design concern; do not casually reuse it as a day-to-day administrator.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
  • Use dedicated, documented accounts and grant only the permissions required by the VMM release and task.
  • For Hyper-V onboarding, the supplied account must have local administrator permissions on the hosts, as Microsoft’s host-add guidance specifies. If you use a Run As account, VMM retains it for future host access.
  • For VMware integration, provide an account with the necessary vCenter administrative permissions and an account with administrative permissions on the vSphere hosts, as applicable to the workflow. Microsoft documents these requirements in its VMware host guidance.
  • Record whether each identity is a domain, local, or VMware account; who owns it; and how its password or secret will be rotated. Expiration, password changes, or permission changes can interrupt refresh and management jobs.

A lab may use a highly privileged account to simplify setup, but that is not a production recommendation. In particular, do not assume that using the ESXi root account is required or appropriate for every deployment; validate the permissions needed for your VMM and VMware versions.

3. Add the Hyper-V cluster

  1. Open Fabric > Servers.
  2. Select Add group > Add Resources > Hyper-V hosts and Clusters.
  3. Choose the location and provide the domain credentials or Run As account with the required administrative rights on the hosts.
  4. Search for the cluster, select it, and assign it to the intended host group.
  5. Submit the job and inspect its details rather than assuming that a completed wizard means every node is healthy.

Refresh the cluster and verify that every intended node is present and healthy, the cluster is associated with the correct group, and VMM can communicate with each node. Confirm that the nodes see the expected storage and CSVs, that DNS and time synchronization are sound, and that there is no pending reboot or agent issue.

If discovery or refresh fails, check account rights, domain trust, name resolution, firewall and WinRM reachability, host agent status, and cluster/storage health. A Needs attention warning is a symptom, not a diagnosis. For example, a warning about MPIO matters when the storage design requires multipath I/O; installing MPIO solely to silence a warning can be inappropriate. Reboot only when required and within an approved window.

4. Add VMware through vCenter

VMM’s VMware integration is through vCenter Server; ESXi hosts and clusters are managed through vCenter, not added as an independent replacement for it. In Fabric > Servers, start the VMware resource-add workflow, enter the vCenter FQDN, select or create the appropriate Run As account, validate the certificate, choose the datacenters, clusters, and hosts to manage, and assign the discovered inventory to the VMware host group.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

VMM communicates with vCenter over SSL. A self-signed certificate may be used, but it must be trusted or manually imported on the VMM management server. Treat certificate trust as an ongoing requirement: document certificate ownership, renewal, and replacement so a later certificate change does not break management.

After discovery, confirm the expected inventory appears and can be refreshed. VMM does not create VMware port groups for you; configure those on the VMware side and map them deliberately to the Hyper-V destination. VMM does not integrate with VMware vCloud. Also check VM configuration before planning conversion: Microsoft lists VMware VMs with virtual hard disks attached to an IDE bus as unsupported for this VMM workflow. Review the current VMware integration limitations against your exact build.

5. Design the network mapping before conversion

Keep these VMM objects distinct:

  • Logical network: a model of network connectivity, commonly organized around purpose or isolation.
  • Network site: the subnets and VLANs available to a host group or host location.
  • VM network: the network a virtual machine connects to, backed by the relevant logical network configuration.
  • Logical switch and port profiles: VMM constructs used to standardize host virtual-switch, adapter, and uplink configuration.
  • Physical adapters, VLANs, and subnets: the actual host connectivity and network segmentation that must match the intended design.

Before the first move, build a mapping such as this and validate it with the network team:

VMware source Hyper-V destination Validate
Port group and VLAN VMM VM network and destination VLAN/site Subnet, routing, security policy, and reachability
Source virtual NIC order and connection Destination virtual NIC order and connection Guest interface identity, static IP assumptions, firewall rules, and application bindings
Special network policy Equivalent destination switch or network policy Load balancer, firewall, QoS, and isolation behavior

Source and destination names need not match, but the mapping must be explicit. VMM may discover VMware network names and create corresponding logical-network objects; it does not configure the VMware port groups themselves.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

For Hyper-V, VMM logical switches can standardize configuration across hosts, but applying or changing one can temporarily disrupt connectivity. Confirm that logical networks, uplink port profiles, physical adapter assignments, VLANs, and subnets are consistent across the intended hosts. Preserve at least one path for VMM management communication, plan out-of-band access, and make switch changes during a maintenance window. See Microsoft’s Hyper-V network configuration guidance.

Production networks commonly separate management, VM traffic, cluster/CSV traffic, live migration, and storage or backup traffic where the design calls for it. One shared network can suit a limited lab; do not treat that as a production blueprint. For Windows Server 2025 live migration, Microsoft recommends Kerberos. Credential Guard is enabled by default and can block CredSSP-based saved credentials and single sign-on, so do not copy an older CredSSP recipe without checking the current live-migration authentication guidance.

6. Add and verify the VMM library

The VMM library stores resources used in deployment and management, such as ISO images, scripts, drivers, templates, and other approved files. It is not a CSV, a backup repository, a VMware datastore, or a live-migration mechanism.

Add a library server or a dedicated SMB library share through the VMM console or command shell. The default library share is named MSSCVMMLibrary and is normally under %SYSTEMDRIVE%ProgramDataVirtual Machine Manager Library Files; additional shares can be used. Check Microsoft’s VMM library documentation for applicable details.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Use a share with adequate capacity and reliable access. Confirm the VMM agent is installed on the library server, the share is associated with the right host group, and permissions allow VMM and the relevant Hyper-V hosts to use the intended resources. Refresh the library and verify that files appear. Do not put migration data there by assumption: confirm which files the conversion workflow actually stages and where it expects them.

7. Keep VMM and host agents current

Updates are version- and build-specific. The earlier lab walkthrough used particular Update Rollup 2 packages and filenames; those are historical artifacts, not universal instructions for VMM 2025 or another installation. Record your VMM build, then follow the update guidance and package for that exact release.

  1. Back up the VMM database and record the current server and console versions.
  2. Check that no critical jobs are running and review the update procedure for your release.
  3. Update the VMM management server and console as instructed, restarting only when required.
  4. Update host agents as required, then refresh each host and review job output.
  5. Validate cluster, network, storage, and library status; test a low-risk operation before relying on the updated fabric.

After host changes or updates, an agent update, refresh, reboot, or revalidation may be needed. Do not globally weaken PowerShell execution policy to run an update script; use trusted, signed material and a controlled procedure appropriate to your organization.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

8. Troubleshoot the errors that commonly block readiness

Host shows “Needs attention”

Inspect the host’s VMM status details and related job output first. Check for a pending reboot, outdated or unhealthy agent, communication or firewall failure, DNS/time problems, insufficient rights, and cluster or storage warnings. Resolve the underlying issue; do not suppress a warning without understanding its effect.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

“Unsupported VM Configuration”

This status has multiple possible causes: unsupported virtual hardware, inaccessible or missing disks, invalid network associations, stale media, unsupported controller settings, host-agent health, or cluster/CSV visibility. A VM with an ISO attached may be worth checking, but disconnecting media is not a universal fix.

For a selected VM, you can ask VMM to reread its configuration from the VMM command shell or a PowerShell session with the VMM module loaded:

Get-SCVirtualMachine -Name "<VMName>" | Read-SCVirtualMachine -Force

Replace <VMName> with the exact VMM object name. If the status remains, investigate the specific unsupported item before conversion. Restarting WMI inside a guest has been suggested in lab troubleshooting, but it is not a general remedy and should not precede diagnosis.

vCenter certificate or discovery failure

Check that the vCenter FQDN resolves from the VMM server, the account has the required permissions, SSL connectivity works, and the certificate presented is trusted and current. If the certificate changed, update trust deliberately rather than bypassing validation as a routine fix.

Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Logical network or switch inconsistency

Compare the logical network and uplink associations on every intended host. This diagnostic can help expose differing VMM associations:

Get-SCVirtualNetwork | Sort-Object LogicalNetworks | Format-Table Name, LogicalNetworks, VMHost

Review results before making changes. Correct host/network associations and remove an obsolete logical network only after dependent objects are addressed. A logical-switch change can interrupt host connectivity; preserve management access and follow the switch planning guidance.

Windows Server 2025 live migration authentication fails

Do not assume saved CredSSP credentials or single sign-on will work. Check Kerberos configuration and constrained delegation in accordance with Microsoft’s current guidance for Windows Server 2025 and your VMM release.

9. Complete a pre-conversion readiness check

Before selecting a production VM for V2V, confirm each item:

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
  • VMM console connects, and the management server and database are healthy.
  • The Hyper-V cluster and all intended nodes are managed, reachable, and healthy.
  • vCenter is managed, its certificate is trusted, and the required VMware inventory is visible.
  • Run As accounts validate and have documented ownership, scope, and rotation plans.
  • The library share is visible and accessible to the systems that need its resources.
  • Destination logical/VM networks, VLANs, and physical connectivity are mapped and tested.
  • Destination storage has adequate free capacity and is visible to the intended hosts.
  • The candidate VM’s disks, controller types, firmware mode, CPU, memory, devices, snapshots/checkpoints, and guest OS have been reviewed for compatibility.
  • Guest tools and Hyper-V integration-service changes, licensing, and activation implications have an owner and plan.
  • Application owners have approved downtime, dependencies, validation, and rollback. Backups have been tested, not merely reported successful.

Use a noncritical pilot VM to validate inventory, disk discovery, placement, network mapping, guest boot, application checks, and rollback behavior. Define rollback concretely—such as restoring service on the source VM after a controlled cutover—not simply as “run the conversion again.” Keep the source VM and vCenter environment intact until the migrated workload has passed its agreed validation.

What comes next

Once the fabric is healthy and the readiness checks pass, the next stage is the V2V conversion itself. VMM supports VMware-to-Hyper-V conversion through its VMware integration, subject to the versions and VM configuration. That operation is distinct from ordinary host onboarding and from VMM’s other transfer types: Microsoft describes network, quick, and live migration behavior separately in its migration overview. Choose the conversion and cutover method based on workload, downtime, storage, and rollback requirements; do not assume a successful inventory import has migrated any VM.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.