If you’re running VMware today, it’s likely that VMware Cloud Foundation (VCF) is where you are heading. Holding many organisations back today isn’t scepticism about the platform, but the assumption that adopting VCF means changing your hardware, networking, storage, and operating model all at once.
It doesn’t. A phased adoption isn’t just possible; it’s the recommended way to adopt VCF.
In fact, most organisations already own more of the platform than they’re using. If you’re licensed for VCF, or moving that way, the components you need for a phased start are usually sat there already; the next step is to unlock their value.
What "not ready" actually means
When customers tell us they’re not ready for VCF, what they usually mean is something more specific: they think adoption requires turning every VCF component on together, immediately, on day one. More importantly, they think that means turning everything outside of the VCF stack off immediately as well.
In reality, none of that has to happen straight away. A phased VCF migration roadmap lets you adopt the platform in stages, bringing components across as you’re ready, rather than converting your whole estate in a single move. That’s not a workaround. It’s how VCF 9.1 is designed to be adopted.
A roadmap built around your business, not a template
There’s no single right pace, because there’s no single starting point. Your roadmap depends on your strategy, the outcomes you’re targeting, and what you’ve already committed to elsewhere including existing storage contracts, networking investment, and hardware refresh cycles.
Getting that right starts with an assessment, not the architecture diagram. It’s the same thinking behind the five questions we ask before any private cloud project begins, and it applies just as much to a VCF adoption strategy as it does to the wider platform decision.
A proper VCF onboarding assessment looks at all of this before it recommends a path. Two organisations on the same VMware estate can, and often should, end up on entirely different roadmaps. A university planning around student intake and exam periods has a very different change window to a business with a storage contract expiring in eighteen months. Neither is wrong. They’re just different starting points, and the roadmap should look different because of it.
What phased adoption actually looks like
Take vSAN and NSX, the two components people worry about most:
- You don’t have to run vSAN in the management domain from day one. You can use your existing storage array instead, with vSAN sitting alongside it in the same cluster, and bring workloads across when a storage renewal or hardware refresh comes round.
- VCF requires NSX at the management layer, but you don’t have to move onto NSX segments straight away. You can run your existing physical networking, Cisco or otherwise, while NSX sits underneath, and plan a phased move onto NSX segments and vDefend when it suits your business.
This isn’t improvisation. Broadcom documents specific, supported paths for converging an existing vSphere estate into VCF without a rebuild, and separately, for upgrading straight through. A phased vSphere to VCF migration is a documented route, not an unofficial workaround: you can adopt vSAN, NSX and VCF Operations in stages, on your own hardware and networking, rather than converting the whole estate in one move. Broadcom’s VCF 9.1 Upgrade Planner will map the specific route from your current version, if you want a starting point beyond this conversation.
The same logic extends to the advanced services sat on top of VCF. Something like vDefend can be switched on for a single domain first, proven there, and rolled out further once you’re confident it does what you need. You’re not choosing between “on” and “off” for the whole estate. You’re choosing where to prove value first, and building outward from there. Broadcom’s own upgrade guidance follows the same logic: harden the foundation first, add secure fleet management once networking is in place, then multi-tenant governance, then the advanced add-ons last. Four stages, not one switch.
Where most businesses start
There is a genuine deadline in play too. vSphere 8 reaches end of general support in late 2027, which is a reasonable prompt to start the assessment soon. It is not, on its own, a reason to rush the whole stack.
If there’s one place to start regardless of your eventual path, it’s VCF Operations. It’s the one component every route to VCF 9.1 requires, so deploying it first costs you nothing in optionality. Point it at your existing vCenter environments and clusters and, within weeks, you’ll have visibility you probably don’t have today, including which virtual machines are over-provisioned. That’s frequently enough to free up hardware you can put straight back into the next phase of the roadmap, funding part of the next step from capacity you already own rather than a fresh purchase order.
Own your VCF adoption
If your journey to VCF has been stalling due to concerns around it needing to be a single, disruptive event, then hopefully now you can see instead that it can be a sequence of manageable ones, each shaped by what your business actually needs next.
That’s the difference between a vendor roadmap and one built for you: it starts with your contracts, your constraints and your goals, and works out the sequence from there. At Xtravirt, we’ve run this assessment enough times to know the shape it usually takes, without pretending every business fits the same shape twice.
Own your VCF adoption, on your terms, and you get every ounce of value your existing investment already promised, on a timeline that was actually built around you.
