The debate about the Broadcom changes around VMware is often about licenses and contracts. At least as important is the impact of VMware Cloud Foundation (VCF) on your teams, architecture and roadmap. VCF has been the integrated standard for private cloud – but the pressure to actually consolidate and optimize existing environments is increasing. In this article, we won't focus on the "paperwork side," but on the daily practice of infrastructure teams and architects.
From separate building blocks to one integrated platform
For years, many MSPs built their platforms on separate VMware components: vSphere, vSAN, NSX, and vRealize, each with its own lifecycle and management process. VMware Cloud Foundation has long been the integrated standard for private cloud. VCF bundles compute, storage, networking, Kubernetes integration, and management into a single stack, including lifecycle automation and centralized management.
This has advantages: fewer disparate products, a more consistent platform, and better automation. At the same time, consolidating to VCF means your architecture and operations are no longer "business as usual" – especially if your environment has historically grown from disparate components.
Why this is more than a license change
If you look solely at licensing, the change seems primarily a pricing and contract discussion. In reality, the entire consumption model is shifting. Broadcom has simplified its product line to VCF and a limited number of alternative SKUs, with VCF as the clear endpoint.
Concretely for your organization:
- Lifecycle and patching are handled through streamlined VCF processes instead of individual component upgrades.
- Monitoring, security and compliance are managed more centrally within the platform.
- Your infrastructure team will build less manually and work more with integrated templates, domains, and automation.
Anyone who underestimates this runs the risk of a VCF platform that runs technically, but does not land organizationally.
Impact on MSP teams: from managing vSphere to running VCF
For many engineers, VCF initially feels like "more of the same with a different name." In practice, their work changes:
- Skillset: In addition to classic vSphere knowledge, more focus is needed on automation, lifecycle management, and integration with container/Kubernetes services.
- Processes: Change, release, and incident processes should align with the VCF lifecycle, not with individual point releases.
- Collaboration: Infrastructure, security, and platform teams need to work more closely together as VCF brings these disciplines closer together.
Add to that the fact that older versions are being phased out more quickly, and you get a lot of pressure on teams to reorient themselves.
Impact on architecture and hardware
VCF requires a well-thought-out architecture: management domains, workload domains, and clear boundaries between customer environments. Existing hardware isn't always suitable:
- Not all existing clusters meet the support requirements for the latest VCF versions.
- Resource planning is changing: you need to consider management overhead, workload domains, and future growth.
- In some cases it is more efficient to refresh or resegment hardware than to push existing configurations into VCF.
Without a good architectural sketch, you run the risk of higher costs or a suboptimal environment that is difficult to manage.
Three routes for MSPs
Broadly speaking, we see three routes for MSPs now delivering VMware services:
- Building a VCF platform yourself
You maintain maximum control over the entire stack. You purchase VMware licenses in the customer's name (resell) and place them on dedicated hardware, completely single-tenant, without shared infrastructure. This gives customers maximum autonomy and a clear ownership structure. However, this does require significant investments: hardware, licenses, skills, and 24/7 support capacity for the platform. This approach is therefore particularly feasible for larger MSPs with sufficient scale and dedicated platform teams. By building a dedicated hardware stack for each customer, there's more flexibility within the platform, reducing (cost) efficiency and increasing the management burden.
- Re-platforming to an alternative
You're leaving VMware (partially or completely) and choosing a different virtualization and cloud stack. This may make strategic sense, but it often requires a major migration and rebuild of customer environments. This also results in duplicate costs due to the setup and deployment of a second platform and a shift away from the organization's focus. Furthermore, migrations like these entail operational risks.
- Connect to an existing Pinnacle platform
You choose to collaborate with an authorized Pinnacle partner using a VCF platform. You retain control over your end customers, but outsource the platform, licenses, and lifecycle to a specialized provider.
Whichever route you choose, the implications for your teams and architecture are at least as important as the licensing side.
The role of a Pinnacle partner as Uniserver
As a Broadcom Advantage Pinnacle Partner for VMware Cloud Service Providers, Uniserver is authorized to operate and make its own VCF platform available to MSPs. This position is reserved for a limited group of partners with proven scale and expertise.
For MSPs this means:
- Access to an authorized VCF platform in a sovereign, Dutch cloud.
- A partner-only model: Uniserver provides the platform, while the MSP remains the face to the customer.
- Support from certified specialists who understand both the technical and commercial implications of the VCF transition.
Your teams can focus on customer value – management, security, applications, data and AI – while the underlying platform, lifecycle and compliance are secured.
Want to know if your current environment and hardware are optimally configured for VCF and what this means for your teams? Schedule a VCF architecture and team impact session with with Rick Glas (r.glas@uniserver.nl) In a single session, we'll map out where you are today, which route is best, and the steps needed to move in a controlled manner toward an optimized VCF environment.
