A 4:1 Server Consolidation Can Leave Your Licence Bill Exactly Where It Was

Written and maintained by Haink's infrastructure team · Worked from current platform specifications and stated assumptions, 29 August 2026 · authorized-channel sourcing, serial-verified

Refresh business cases are usually built on two claims: fewer boxes, and lower running cost. The first is straightforwardly true and the arithmetic is easy. The second is where these projects go wrong, because most of the savings people assume are in the licence line, and in 2026 the licence line does not behave the way it did when the outgoing fleet was bought.

What follows is the arithmetic, worked out in the open with every assumption stated, so you can substitute your own numbers rather than trusting ours.

The worked example

The outgoing fleet. A common shape for hardware bought in 2019–2020: forty 2U dual-socket servers, second-generation Xeon Scalable, twenty cores per socket. That is 1,600 physical cores across 80 sockets, occupying 80U before cabling and switching. At a working assumption of roughly 450 W per node under typical enterprise load, the fleet draws in the region of 18 kW.

The replacement. A current-generation 2U node — ThinkSystem SR650 V4, PowerEdge R770 or ProLiant DL380 Gen12 — carries up to 86 P-cores per socket, 172 per node. On raw core parity:

Read the third row again. Forty boxes became ten, and the physical core count went up. That is not an error in the example — it is the arithmetic of consolidating onto very high core-count processors, and it is the single most misunderstood number in a refresh business case.

What genuinely gets cheaper

• Space. Sixty rack units released. On leased space or a full facility, this is often the loudest number in the business case, and it is real.
• Power and cooling. Roughly 40% less draw in the example, with the cooling load falling with it. Per-node power roughly doubles on modern hardware, but four times fewer nodes still nets out well ahead.
• Support contracts. Maintenance is priced per node. A 4:1 node reduction is close to a 4:1 reduction in the maintenance line — and this is where a refresh most reliably pays, because out-of-support hardware is either uncovered or covered at a premium.
• Failure rate and the labour attached to it. Four times fewer moving parts, and hardware inside its support window rather than beyond it. Difficult to put in a spreadsheet, easy to feel in the operations rota.
• What the platform will run. Newer hypervisor versions, current security baselines and vendor-supported firmware paths. On an old enough fleet this stops being an economic argument and becomes a compliance one.

What usually does not get cheaper, and sometimes gets worse

The licence. Every major virtualization stack now meters on physical cores: VMware as a per-core subscription with a 16-core minimum per processor, Nutanix per core, Azure Local as a per-core monthly host fee. Your licence bill follows the cores you buy, not the boxes you retire.

In the example, billable cores rise from 1,600 to 1,720. If you are already on core-based licensing, a 4:1 hardware consolidation produces roughly no licence saving. And if the outgoing fleet was licensed on the per-socket model that applied when it was bought, the comparison is 80 sockets against 1,720 cores — a different unit entirely, and usually a considerably larger number.

This does not mean the refresh is wrong. It means the business case has to be built on space, power, support and risk — the items above — and the licence line has to be modelled honestly rather than assumed to fall with the node count. We work through what the licence model does to node design, including why the top processor SKU is rarely the right buy, in choosing a server generation under per-core licensing and in the hardware decision behind a VMware exit.

The version of this that does save licence cost

Consolidate onto fewer cores, not more. Sizing from committed rather than allocated resources routinely shows that an estate running 1,600 cores is genuinely using far less, and the replacement can be specified at a lower total core count with headroom intact. That is a real licence saving, and it is available only if the sizing work is done properly before the specification is frozen. Sizing on the old core count and buying the biggest processors available is how a refresh delivers a smaller estate and a larger annual bill.

The constraint moves from rack units to kilowatts

Twenty rack units of replacement hardware sounds like it fits anywhere. Ten nodes at roughly a kilowatt each is 9–11 kW, and in a hall provisioned at 6–8 kW per rack that is more than one rack can take — not because the space ran out, but because the power did.

This is the practical trap in modern consolidation: you free 60U and then discover you cannot fill the rack you kept. Uptime Institute's 2026 survey describes average modal rack densities continuing a slow upward trajectory, with high density — 30 kW and above — still reported by a growing minority rather than the norm. Most enterprise halls have not moved as fast as the servers going into them.

Three practical consequences:

1. Check the per-rack power budget before the node count is settled. It may push you toward more, less dense nodes than the pure consolidation maths suggests.
2. Check the PDU and circuit configuration, not just the headline kW. A rack rated for 10 kW with the wrong circuit layout will not deliver it to the sockets you need.
3. Check cooling delivery at the rack, not the hall average. A dense rack in a hall designed for even load is a hot spot, and hot spots throttle before they trip anything.

Where density is genuinely the binding constraint, liquid cooling becomes worth pricing — but read the trade-offs first: on the SR650 V4, for instance, the liquid-cooled compute complex halves the DIMM slots from 32 to 16.

When the refresh does not pay

• When the fleet is still inside support and under three years old. The support saving, which is the most reliable line, is not available yet.
• When the estate is small. Below roughly ten nodes, the fixed costs of the project — design, migration, downtime windows — dominate the savings.
• When the workload is about to move anyway. If a platform change, a cloud exit or a data-residency programme is coming, refresh the hardware as part of that decision rather than ahead of it.
• When the constraint is memory capacity. Current-generation 2U nodes top out at 8 TB, the same ceiling as the previous generation. A refresh does not solve a memory-capacity wall; a different chassis class does.
• When the facility cannot take the density. If the power and cooling work required to host the consolidated fleet exceeds the saving, the honest answer is to refresh less aggressively, with more nodes at lower density.

Finding your actual end-of-support dates

Do not plan a refresh on a rule of thumb about five-year lifecycles. Every vendor publishes per-model dates, and they vary by several years across a fleet that was bought in one wave:

• Lenovo publishes an end-of-service date lookup covering servers, storage and networking. Our ThinkSystem lifecycle and status map covers which platforms are withdrawn and what replaced each one.
• HPE publishes end-of-support-life notices per product family.
• Dell publishes support lifecycle dates per platform in its support portal.

Pull the dates for every model and serial in the estate, then sort by date rather than by rack. Refresh waves organised around support cliffs are cheaper and less disruptive than waves organised around the calendar, and they surface the uncomfortable case where a quarter of the fleet has two more supported years and should not be touched yet.

The outgoing fleet is a budget line, in one direction or the other

Forty decommissioned servers have residual value, and it falls fastest in the weeks immediately after they come out of the rack. Decided in advance, certified disposal or remarketing offsets a visible share of the new capital; decided late, the same fleet becomes a storage problem and then a disposal cost. Our guide to ITAD and the secondary market covers the options and where the value actually sits.

How to run the numbers for your estate

1. Committed resources, not allocated. Pull actual sustained CPU and memory consumption, not the sum of VM configurations. This is the input that most changes the answer.
2. Target core count from that figure, plus headroom and N+1 — not from the outgoing core count.
3. Price the licence on the target core count over the full term, at the per-core rate you actually pay, remembering the 16-core-per-CPU floor where it applies.
4. Add hardware, then subtract the maintenance contracts retired, the power at your actual tariff, the space at your actual cost, and the residual value of the outgoing fleet.
5. Check the answer against the facility — per-rack kW, circuit layout, cooling at the rack.
6. Sanity-check the delivery date against the window. A refresh that arrives after the maintenance window has a payback period of one more year, whatever the spreadsheet said.

On most estates, steps one and three swing the result more than the hardware price does — which is why negotiating hard on the server quote while sizing from allocated resources is the wrong order of effort.

Frequently asked questions

How many old servers does one current-generation server replace?

On raw core parity, a 2U node with two 86-core processors replaces about four 2U nodes built on twenty-core processors from 2019–2020. Real consolidation ratios are usually better than core parity suggests, because per-core performance and memory bandwidth also improved — but size from measured consumption rather than from a ratio.

Does consolidation reduce our VMware licence cost?

Not by itself. Licensing follows physical cores, not nodes. Consolidating forty twenty-core nodes into ten 172-core nodes takes you from 1,600 cores to 1,720 — slightly more. The licence saving is available only if you deliberately specify a lower total core count, which requires sizing from committed rather than allocated resources.

Could a refresh increase our licence bill?

Yes, and it is common. If the outgoing estate was licensed per socket and the replacement is licensed per core, you move from 80 sockets to 1,720 cores. That is a different unit and usually a larger bill. Model it explicitly before the specification is frozen.

Where do the real savings come from, then?

Rack space, power and cooling, maintenance contracts, failure rate and the operational labour attached to it, plus the ability to run currently supported software. In the worked example that is 60U released, roughly 40% less power, and close to a 4:1 reduction in per-node maintenance.

Why can't we fit the consolidated fleet into one rack?

Because the constraint is kilowatts, not rack units. Ten current-generation nodes at roughly a kilowatt each need 9–11 kW, and many enterprise halls provision 6–8 kW per rack. Check the per-rack power budget, the circuit layout and cooling delivery at the rack before the node count is fixed.

How do we find our end-of-support dates?

From each vendor's lifecycle lookup, per model and serial — not from a five-year rule of thumb. Lenovo, HPE and Dell all publish per-product dates, and across a fleet bought in one wave they can differ by years. Sort the estate by support date and plan the waves around the cliffs.

When should we not refresh?

When the fleet is under three years old and still supported; when the estate is under about ten nodes and project overhead dominates; when a platform change or cloud exit is coming and the hardware decision belongs inside it; when the real constraint is memory capacity, which the current generation does not raise; or when the facility cannot take the resulting density without work that costs more than the saving.

Related

• ThinkSystem V3 vs V4 — which generation to specify, and why the top SKU is rarely the right buy
• HPE ProLiant Gen11 vs Gen12 — the core-variant and memory-speed decision
• GreenLake vs owning the hardware — what the consumption contract actually charges for
• Lenovo vs Dell vs HPE — the three current-generation platforms compared on the same specification
• VMware exit — the hardware decision — when the refresh and the platform change are the same project
• Buying 20–60 servers as one project — how a refresh of this size is actually purchased
• ThinkSystem lifecycle and end of support — platform status, successor map, and how to get your real dates
• ITAD and the secondary market — recovering value from the fleet coming out
• How to choose Lenovo ThinkSystem servers · stock vs BTO/CTO · stock and lead times
• Sovereign cloud infrastructure — 40 nodes, 7,680 vCPUs, 96 TB NVMe delivered as one programme

Sources

• Lenovo Press — ThinkSystem SR650 V4 product guide (86 cores per socket, 8 TB ceiling, Neptune Core and its 16-DIMM configuration)
• Dell — PowerEdge R770 · HPE — ProLiant Compute DL380 Gen12 (current-generation 2U core and memory ceilings)
• Uptime Institute — 16th Annual Global Data Center Survey, 2026 (average modal rack densities on a slow upward trajectory; 30 kW+ reported by a growing number of operators)
• Lenovo — end-of-service date lookup for servers, storage and networking
• VMware licensing changes (per-core subscription, 16-core minimum per CPU)