Servers, Storage & Virtualization

How It Works & Technology Overview

On-premises compute for a small or mid-sized organization is a handful of physical servers ("hosts") running a hypervisor, with the workloads — domain controllers, file servers, line-of-business applications, databases — living as virtual machines. Two or more hosts become a cluster when they share storage, so VMs can move between hosts and restart elsewhere if one fails. Shared storage is either a separate array (SAN or NAS, connected over iSCSI, Fibre Channel or NFS) or hyperconverged storage pooled from the hosts' own disks.

Projects fall into four shapes: a server refresh (new hardware, same platform), a hypervisor migration (moving VMs from one platform to another), a consolidation (fewer, larger hosts), and a build-out (new cluster for a new site or workload). Every one of them is a migration project in disguise: the hard part is moving live workloads with known dependencies inside a maintenance window, not racking the hardware.

Common Deployment Scenarios

• Two- or three-host cluster refresh with shared storage, replacing aging hosts near end of warranty.
• VMware exit: moving workloads off vSphere to Hyper-V, Proxmox VE or Nutanix after licensing changes, converting or restoring VMs onto the new platform.
• Single-host small office: one host with local storage and a solid backup, where clustering isn't justified.
• Physical-to-virtual consolidation of remaining physical servers.
• Server OS upgrades riding along with the hardware: retiring operating systems near end of support and rebuilding roles (domain controllers, file services) rather than in-place upgrading.

Products, Vendors & Characteristics

• Hypervisors: VMware vSphere (Broadcom) — now subscription-only, licensed per core with a 16-core-per-CPU minimum and order minimums that have changed repeatedly since 2024; Microsoft Hyper-V, included with Windows Server; Proxmox VE (open source with paid support subscriptions); Nutanix AHV on Nutanix hyperconverged platforms.
• Windows Server licensing: licensed per physical core with minimums of 8 cores per processor and 16 per server; Standard edition covers two Windows VMs per fully licensed host (license again for more), Datacenter covers unlimited VMs on the host. Client access licenses are separate.
• Hardware: enterprise servers from Dell, HPE and Lenovo; arrays and hyperconverged appliances from storage vendors and the hypervisor ecosystems. Firmware, drivers and the hypervisor's hardware compatibility list must agree.
• Migration tooling: each platform ships converters/importers; backup products can restore a VM onto a different hypervisor, which is often the most reliable path.

What Makes It Hard (Gotchas & Failure Modes)

• Licensing math: core minimums make small hosts expensive to license, and VM counts under Windows Server Standard multiply licenses; a cheap host can carry a large software bill.
• Undocumented dependencies: a "file server" that also runs a scheduled task the accounting app depends on; hard-coded IP addresses; licenses tied to MAC addresses or hardware IDs.
• Driver and tooling residue: VMs moved between hypervisors need guest tools removed and new drivers installed; boot and storage-controller changes can leave a VM unbootable.
• Network design: VLANs, storage networks and host networking must exist before migration night; storage traffic on the general network causes performance complaints.
• Firmware drift: hosts at different firmware levels destabilize clusters; baseline before go-live.
• Maintenance windows: line-of-business systems may only be down overnight or on weekends; database and application vendors may need to be on call.
• End-of-support deadlines on server operating systems and hypervisor versions drive scope and urgency.

Effort & Estimation Patterns

• Host build (rack, firmware baseline, hypervisor install, networking, storage connection, validation): 4–8 hours per host.
• Cluster and shared storage setup and failover testing: 1–2 days for a small cluster.
• VM migration: 1–2 hours per standard VM including validation; 4–8 hours for databases and complex line-of-business applications, often with the vendor involved.
• Physical server decommission (data wipe, documentation, disposal coordination): 1–2 hours per server.
• Contingency: add 20–30% for discovery in environments without a current inventory of VMs, dependencies and licenses.
• Cutover: schedule weekend or overnight windows with a defined rollback point; budget a post-migration check the next business morning.