Server Consolidation: Planning What Actually Goes Wrong

Consolidating physical servers onto fewer hosts is usually justified on hardware cost, and the hardware is rarely where the difficulty is. What makes consolidation projects overrun is the machines nobody documented and the dependencies nobody knew about.

Find out what is actually running

The step that determines whether the project is predictable.

Estates accumulate servers. There is usually at least one machine nobody can account for, one running something a single department depends on, and one whose owner left years ago.

Two techniques.

Look at what talks to what. Network connections reveal dependencies that documentation does not — which machines connect to which, and on what schedule.

Make it temporarily unavailable and see what complains. Crude and effective, and the same approach our decommissioning guide recommends. It surfaces scheduled jobs and intermittent consumers that connection monitoring misses.

Pay particular attention to things that run monthly or quarterly. A dependency that fires at quarter-end will not appear in a week of observation, and it will fail three months after you considered the project finished.

What does not consolidate well

Being clear about this early prevents the difficult discoveries.

Hardware dependencies. Machines with specialist cards, dongles, serial connections to equipment, or anything physically attached that a virtual machine cannot present.

Licensing tied to hardware. Some software is licensed against physical characteristics, and virtualising it may breach the licence or simply stop it working.

Systems under validation. In regulated environments, moving a validated system may require revalidation, which can cost more than keeping the hardware.

Legacy operating systems. Very old systems may not run on modern hypervisors, or may run unsupported. Our legacy platform guide covers why these systems stay where they are.

Latency-sensitive or heavily I/O-bound workloads, where sharing a host changes behaviour in ways the application notices.

Identify these first. A project that discovers them halfway through stalls.

Sizing the target hosts

The mistake here is summing what the source machines have rather than what they use.

Physical servers are typically specified generously and run at a fraction of their capacity. Adding up their specifications produces a target far larger than necessary.

Measure actual utilisation over a representative period including peaks and any month-end processing.

Then size against the resource that will actually run out. On virtualisation hosts that is almost always memory — processors can be oversubscribed because guests rarely use allocated cores continuously, while a guest allocated memory generally holds it. Our host sizing guide covers this in detail, including how per-core licensing frequently reverses the core count decision.

And size for failure headroom: the cluster must run its whole workload with one host absent, or a host failure has nowhere to go.

Storage is the design decision

Consolidation changes the storage picture more than the compute one.

I/O becomes random. Many guests issuing independent requests simultaneously produces a very different pattern from a single server’s workload. This is the classic case for flash, and our SSD versus HDD guide covers why.

Shared or local decides whether clustering works. Guests can only move between hosts or restart elsewhere on failure if storage is shared and block-level. Our architecture guide covers the distinction.

Size from usable capacity. RAID overhead, spares and unit conversion all reduce it, and consolidation projects frequently arrive short because raw figures were summed. Our capacity guide covers the arithmetic.

On mechanical storage, RAID 10 usually suits this better than parity — better random write behaviour and far better rebuild performance under load.

Risk concentrates

The consequence that changes operational requirements, and it is frequently underweighted.

Twenty physical servers means twenty independent failure domains. Three hosts means three, each carrying far more. A host failure that previously affected one service now affects many.

Three things follow.

Redundancy matters more. Dual power supplies on separate circuits, and each circuit able to carry the full load alone. Our PDU guide covers why.

Spares matter more. A host down is now several services down, so the parts to restore it should be on the shelf.

Monitoring matters more. Early warning on drives, memory errors and thermal conditions is worth more when each host carries more. Our monitoring guide covers what gives useful warning.

And backups need re-examining. The consolidated environment is a new backup target, and the restore procedure has changed.

Migrate in a sensible order

Start with the least critical machines to build confidence and expose problems cheaply. Move systems with known dependencies as groups rather than individually, so a dependent pair is never split across old and new.

Keep the source machines available after migration rather than decommissioning immediately — through at least one full monthly cycle, ideally through a quarter-end. That converts a problem from a restore into a switch back.

When you do decommission, follow the decommissioning sequence: sanitise data before hardware leaves, cancel support contracts, update asset records — and keep anything compatible with equipment still running, since retired hardware is the cheapest spares source available.

Common questions

Tell us measured utilisation and guest count and we will help size hosts and storage rather than summing what you currently have.