You’ll have heard of many private cloud projects failing before a single workload moves. Technology is rarely the culprit. Too often, the original brief pulls in several directions at once: technical stakeholders want the newest technology, the senior leadership team wants an immediate problem solved, and somewhere in the middle, the actual goal gets lost.
It is a bit like planning a long ride by obsessing over the bike. The chainset, the frame weight, the tyre width – hours go into the equipment. Then you wake up with no idea where you’re going, no idea where you’ll get food (the most important part of any ride), and no plan for what happens when the weather turns at mile 60. The bike is exactly as it should be, but the ride still falls apart.
The platform is rarely the problem. The longer-term headaches come from how the organisation sets its goals and choses its new platform – and whether anyone asked the right questions before the architecture got drawn up.
Two different starting points
Some organisations face a compelling event: ageing hardware falling out of support, a lease expiry, a licensing deadline. vSphere 8’s end of support in October 2027 is forcing exactly that conversation across a large part of the market. For these customers the brief can be literal: replace this with that, by this date.
Others are working to a more distant horizon: consolidating data centres, building the foundation for an AI programme, or keeping sensitive workloads in a sovereign environment they fully control. In higher education and the public sector, for example, control over data location is a governance obligation, not a preference.
Most private cloud proposals treat both starting points with the same approach: compute, storage, networking, priced and packaged into cores, terabytes and licence tiers – but this is rarely the best brief for either.
Five questions to get you where you need to be
The fix isn’t a longer proposal, it’s a different first conversation: one that starts with the end destination and the milestones to get there, not the components along the way. Here are five questions I ask in every discovery session:
1
"What does good look like to you?"
Most briefs describe what needs to be built. Instead, ask yourself what success means for your organisation. The answer is what everything else maps back to. Skip it, and you risk building something technically correct that solves the wrong problem.
2
"What's driving this conversation right now?"
The compelling event shapes everything. A hardware deadline and a five-year strategic ambition need different approaches, and you cannot tell which until you ask the question. The answer changes the scope, the pace, and the shape of the journey that follows.
3
"What do you already have, and are you getting everything out of it?"
Organisations regularly pay for capability they don’t fully use. A common concern from organisations already running VMware technology is that they’re not using everything they have, so what is the point of having more? In my experience, the value of a thorough discovery phase cannot be understated. The discovery process will surface what is being used, what is not, and what could be unlocked to move faster. VMware Cloud Foundation 9.x works best as a platform, not a collection of parts. The more of it you put to work, the more streamlined operations become and the more value it delivers.
4
"What is it about your current environment that keeps you up at night?"
In my experience, the pain points listed in a proposal are rarely the real ones. This question gets past the prepared answer and into the anxiety that’s actually driving the conversation. The real brief usually lives here.
5
"Who in your organisation would answer these questions differently?"
Stakeholders from different parts of the organisation often describe the same requirement in different languages. For example, an IT Director might talk in VMs, cores and failover configurations, whereas an Operations Director is focused more on keeping the lights on and not getting woken up at 2am. If discovery only captures one version, the brief only solves part of the problem.
Know the terrain, not just the route
There is one more question worth asking in every discovery session, months before it becomes urgent: what do you do when things get tough?
A route tells you where to go. It does not tell you the terrain. Knowing a climb is coming is one thing. Knowing how to pace it, read it, and get over it without burning out is another.
Private cloud is the same. Deploying a platform and owning one are not the same thing. The teams who fare best are the ones involved from day one: in the discovery, in the design decisions, in the reasoning behind the build. That knowledge accumulates throughout. It does not need to be handed over at the end.
Know the route before you clip in
The strongest riders aren’t the ones that obsessed over the bike. They are the ones who knew the route, planned for the conditions, and had support when it got hard – not at the finish line.
Get the brief right and you own the platform in every sense: the kit, the business challenges it solves, and the capability to run it on your own terms. Get it wrong and a flawless deployment still solves the wrong problem.
If you are planning a migration or revisiting one that did not land the way you hoped, the conversation worth having is not about the platform, it is about the route.
This is what makes Xtravirt different. We ask the right questions from the start, stay with your teams through the strategy, design and deployment stages, and remain alongside you when the terrain gets rough. Additionally, our managed service team actually frees you up to plan the next leg of the journey.
Having a plan and riding alone is one thing, but it’s better facing the journey with a partner who’s been there before.
Get in touch to talk through what a proper discovery process could look like for your organisation.
