VMware Cloud Foundation 9 Readiness: What Changes From vSphere 8, and How to Assess Your Hardware

VMware Cloud Foundation 9 is not just a version bump on vSphere. It folds vSphere, vSAN, NSX, and the Aria suite into a single engineered stack with one lifecycle manager, one upgrade path, and one set of interoperability guarantees across the components. That is a real change in how an environment gets built and maintained, and it means the planning work has to happen before a single host gets touched, not after.

What Changes From a Standalone vSphere 8 Deployment

Running vSphere 8 on its own gives an administrator freedom to patch, upgrade, and configure each component independently. VCF trades some of that freedom for consistency: vSphere, vSAN, and NSX get validated, licensed, and upgraded together as a known-good combination instead of a patchwork of versions someone has to verify by hand. It also means an organization moving from vSphere 8 to VCF 9 is not just upgrading a hypervisor. It is adopting SDDC Manager as a lifecycle layer that expects to own the whole stack, and any customization built into the old environment outside that layer needs to be re-evaluated before it comes along.

Hardware Is the First Real Constraint

Every VCF deployment lives or dies on the VMware Compatibility Guide for the exact version being installed, and that list is narrower than the general vSphere HCL because VCF certifies whole configurations, not individual components in isolation. A server that ran vSphere 8 comfortably can still fail VCF 9 certification over a NIC firmware revision, a BIOS setting, or a CPU generation that has been deprecated for new VCF builds even though it is still supported for standalone vSphere. Skipping this check is the most common way a VCF project stalls midway through, after hardware has already been ordered or racked.

New Deployment vs. Migrating From vSphere 8

A new VCF 9 deployment gets to design storage, networking, and the management domain from a blank slate, which is simpler in some ways and more consequential in others, because every choice made at the management domain level is expensive to unwind later. A migration from an existing vSphere 8 environment carries baggage in the other direction: existing network topology, existing storage policy, and existing workloads that cannot tolerate an extended outage during cutover. Both paths start with the same honest question. What hardware is already in the building, and does it qualify.

• Confirm every host's CPU, NIC, and storage controller against the VMware Compatibility Guide for the specific VCF 9 build, not the general vSphere HCL.
• Size the management domain separately from workload domains. It has its own minimum host count and shouldn't be undersized to save budget.
• Check firmware and BIOS versions against the certified baseline before racking new hardware, not after.
• Map existing vSphere 8 network topology and storage policy against what NSX and vSAN expect in VCF, so nothing gets assumed to carry over automatically.

The Licensing Model Is Part of the Assessment Too

VCF is sold and consumed differently than a standalone vSphere license, and that shift matters as much to a budget conversation as the hardware check matters to a technical one. Where vSphere licensing was historically per-CPU, VCF's model is core-based and bundles the entitlement for vSAN, NSX, and the Aria components into the same subscription rather than licensing each one separately. That changes how a true-up gets calculated as a cluster grows, and it means the hardware assessment and the licensing assessment need to happen at the same time, not one after the other, because the core count on the hardware being evaluated is the same number the license cost gets built around.

Working Alongside an Existing IT Team

Most organizations bringing in outside help for a VCF 9 project already have an internal IT team running the vSphere 8 environment today, and a deployment that ignores that team's existing operational knowledge creates its own risk. The people who know which VMs are quietly load-bearing, which maintenance windows are actually safe, and which application owners need advance notice before a cutover are the same people who have been running the environment day to day. A VCF 9 deployment done in collaboration with that team, rather than around it, is what turns the assessment into something the internal team can actually operate once the project is done.

None of this is a reason to avoid VCF 9. It's a reason to assess before committing. Gibson IT works through hardware and licensing requirements against the actual environment first, whether that's a fresh VCF 9 build or a migration up from vSphere 8, and only then moves into deployment alongside the internal IT team. Call (407) 485-8884 or request a free evaluation for a straight answer on what your current hardware can and can't carry into VCF 9.