TLDR: Your hardware vendor and your software vendor will both have a view on this. I think it’s fair to say both views are valid, they’re just optimising for different things. Let the platform lead. Decide what the private cloud has to deliver, then make the hardware fit it - not the other way round.
Why this keeps coming up
Most private cloud projects have two strong voices in the room.
The hardware vendor has reference designs and a refresh cycle. They want the servers specified early.
The software vendor has a platform, and its features need certain hardware. They want the platform requirements specified early.
Neither is wrong. But if you specify the hardware before anyone agrees what the platform needs to do, you get a private cloud shaped by the servers. If you specify the software without looking at what you already own, you can end up replacing hardware that still had life in it.
Which goes first should be your decision, not whoever got there first.
When software first makes sense
Software first means you decide what the private cloud needs to deliver, then pick hardware from the platform’s support list.
It’s the right call when;
- You’re building a new platform, or the hardware is due for refresh anyway
- You need specific platform features, now or in the next few years
- AI or GPU workloads are on the roadmap
- You want one consistent build to run for five years or more
The benefit is you don’t close doors. The cost is time and money - a proper design phase and often new hardware.
When hardware first makes sense
Hardware first means you start with the servers you have, or a hardware standard you’ve already committed to, and shape the private cloud around them.
It’s the right call when;
- The servers are recent and still well supported
- There’s a company-wide hardware standard you need to stay on
- Time matters more than features
- Your servers already carry plenty of memory, which costs a lot more to buy than it did
It can work well. You just need to know what it will limit before you commit.
Questions to ask before anyone signs off
- What does the private cloud need to deliver over the next 3-5 years?
- Who owns that outcome - us, or a vendor?
- Has the hardware design been checked against the platform’s support list?
- If we go hardware first, what are we giving up, and are we happy with that?
- If AI is in the plan, where does it run?
If you can answer those, see below on how this impacts design.
For the design team: three checks on existing hardware
Support - is the hardware supported by the platform version you want to run and for how long? Older CPU generations drop off over time, so a server that works today may not make the next major upgrade.
Capability - does it have what the platform features need? Storage and drive type, network speed and older network or storage cards are often points overlooked and where older hardware falls short.
Fit - does the balance of CPU and memory match your workloads? Many platforms are licensed per core (some per socket), so a server with lots of cores and not much memory means paying for CPU you never use. Some platforms also expect matching hardware across a cluster, so mixing old and new servers isn’t always an option.
None of these stop you building a private cloud. But they do decide which version and features or capabilities of it you get.
The two approaches side by side
| Compared on | Software first | Hardware first |
|---|---|---|
| Who leads | What the platform needs to deliver | The servers you have, or a hardware standard |
| Upfront cost | Higher - new hardware plus design time | Lower - reuses what you own |
| Time to start | Longer | Shorter |
| Platform features | Not limited - you buy for what you need | Limited by the hardware |
| Licence efficiency | CPU and memory sized to each other | Risk of paying for idle cores |
| Lifecycle | One refresh across the platform | Mixed generations, earlier end of support |
| Main risk | Designing for needs that never come | Hitting a limit you can’t fix without new hardware |
In practice most people land somewhere in between. Reuse what fits the design, and replace what doesn’t.
What matters in the hardware
CPU - core count is a cost decision as much as a performance one. Size it to what your workloads use, not the biggest CPU on the list. Watch for minimum core counts too - they can make very small CPUs poor value.
Memory - this is often what runs out first, and it can be the biggest single cost in the server. Memory prices have risen sharply since late 2025, driven by AI demand. Measure what your workloads use before you buy, and check whether your platform can use dedicated NVMe drives as extra memory (it needs its own drives, and not every workload suits it).
Storage - decide early whether storage lives in the servers or on a separate array. It changes how many drive bays you need, what network you need, and how you grow.
Network - plan for storage and migration traffic, not just application traffic. Buying faster networking up front is usually cheaper than upgrading it later.
GPUs - this is where hardware first hurts most. Existing servers usually weren’t bought to take a large datacentre GPU - power, cooling and slot space get in the way. If AI is on the roadmap, plan for it up front, usually as its own cluster designed software first.
Where to start
- Write down what the platform needs to deliver (the requirements), before either vendor specifies anything.
- Share it with both vendors or partners and try to actively encourage collaboration between them.
- Check every server against the platform’s support list, and how long that support lasts.
- Start understanding your capacity requirements and demands - find out what resource runs out first (often memory) and take that information into your sizing.
- Establish a features and capabilities roadmap, so it’s clear what’s available day one compared to sometime in the future.
If you’re working through this now and want a second opinion, drop me a message.
