Virtualisation and Hypervisor Support

It depends on your renewal number, your estate profile, your existing Windows licensing and the migration effort. There is no general answer and anyone giving you one has not looked at your environment.

Staying is defensible where the feature dependence is deep and the operational practice is mature. Moving to Hyper-V changes the arithmetic considerably for Windows-dominant estates that already hold Datacenter licensing. We produce the comparison with your actual numbers rather than arriving with a preference.

For most mid-market workloads, yes. Feature parity is closer than it was and it is not identical, and the gaps are in areas many estates do not use.

Where VMware retains an advantage is in the mature ecosystem, the depth of the management tooling and the breadth of third-party integration. Whether those matter depends on whether you use them. An estate running virtual machines and clustering, with no dependence on the wider suite, generally transitions without much pain.

Virtualisation runs multiple virtual machines on your own hardware. Cloud runs workloads on someone else’s infrastructure, usually with a consumption-based cost model and managed services above the virtual machine layer.

They are complementary rather than alternatives, and the phrase virtualization gets used loosely to mean both. Moving virtual machines to cloud infrastructure without changing anything else gives you the cost model of cloud and few of its other benefits, which is a legitimate choice and worth making deliberately.

Enough to run everything with one host unavailable, which is N+1 as the minimum. A cluster that cannot lose a host has no resilience during a failure and no headroom during patching.

Three hosts running at eighty percent utilisation is a very common configuration and it does not satisfy this. It works until the day a host fails or you try to patch, at which point the constraint appears. Sizing for N+1 at realistic utilisation is the single most important cluster decision.

Most often storage latency, over-allocated virtual CPUs causing scheduling contention, memory over-commitment forcing swapping, or long-lived snapshots.

Snapshots and virtual CPU over-allocation are the two that surprise people. Assigning eight virtual CPUs to a machine that needs two makes it slower on a busy host, not faster, because the scheduler has to find eight free cores before it can run anything. Right-sizing downward frequently improves performance.

Hours. Days at the outside. Never weeks, and never on a database or a domain controller.

The delta file grows with every change, degrading performance steadily and consuming datastore capacity. The eventual outcome is a full datastore, which stops every virtual machine on it. Monitor snapshot age and count, alert on both and give every snapshot an owner and a removal deadline when it is created.

Occasionally. Workloads with specific hardware dependencies, licensing that penalises virtualisation, extreme performance requirements or vendor certification against physical hardware.

The list is much shorter than it used to be. Where a vendor requires physical hardware, ask when that requirement was last reviewed, because it is often inherited from an older version of their product and no longer accurate.

Yes, both directions and physical to virtual as well. The approach is phased, machine group by machine group, with fallback at each stage rather than a single cutover.

The effort is usually underestimated in one specific area: the surrounding integrations. The virtual machines themselves migrate reasonably predictably. Backup, monitoring, automation and any tooling built against the old platform all need rework, and that is where the schedule goes if it has not been scoped.

A very small estate with one or two large workloads that consume most of a host. The hypervisor layer, its licensing and its operational overhead buy you little when there is nothing to consolidate.

That is a genuinely small set of cases and most estates benefit from virtualisation. Where it applies, running on physical hardware with good backup and a documented rebuild is simpler and cheaper. We will say so rather than designing a cluster around two machines.