Choosing VVF 9.x or VCF 9.x from vSphere 8: The Customer Decision Workshop

Part 2 of 4 in the vSphere 8 exit series.

TL;DR

Choosing between VMware vSphere Foundation (VVF) 9.x and VMware Cloud Foundation (VCF) 9.x should begin with an architectural decision workshop, not a licensing comparison or feature checklist. Both platforms support modern enterprise workloads, but they represent different approaches to infrastructure ownership, networking, automation, lifecycle management, and private cloud operations.

For customers migrating from vSphere 8, the decision has additional consequences. Existing NSX dependencies, vCenter boundaries, storage configurations, hardware compatibility, licensing, recovery design, and the ability to reuse infrastructure can materially change the recommended platform and transition strategy. Broadcom’s October 14, 2026 feature comparison provides a current baseline for VVF 9.1.1 and VCF 9.1.1, but product capabilities alone do not establish customer suitability.

I would structure the selection around three decisions: first, establish mandatory requirements and disqualifying constraints; second, compare qualified architectures using evidence, operational ownership, and three-to-five-year total cost of ownership (TCO); third, approve a supported transition strategy with explicit conditions that must be met before implementation.

Takeaway: Select the operating model the customer can justify, implement, maintain, and recover. Then choose the supported technical path to reach it.

Introduction

The customer has a healthy vSphere 8 environment. The hosts are running production workloads, vCenter is operational, and the infrastructure team understands how to manage it.

The October 2027 support deadline has prompted a modernization discussion.

One proposal recommends VVF 9.x because the customer currently uses conventional VLAN networking, external storage, and a relatively small amount of automation.

Another recommends VCF 9.x because the organization expects to introduce NSX segmentation, standardize several datacenters, and eventually provide self-service infrastructure.

Finance wants to understand the subscription difference. The network team wants to know whether it will retain control of routing and firewalls. The application owners do not care which VMware product is selected as long as their systems remain supported and recoverable.

Everyone has a defensible concern, but they are answering different questions.

That is the problem the decision workshop needs to solve.

The previous article in this series established the need to begin the vSphere 8 exit program now, work toward production completion before the October 11, 2027 deadline, and treat lifecycle supportability as a platform-wide outcome.

This article addresses the architectural decision that should occur before the detailed upgrade design is approved.

It is not another general VVF-versus-VCF feature comparison. DTD already has coverage of that distinction. The objective here is to show how I would lead a customer through a repeatable selection process that produces an approved architecture, an evidence-backed recommendation, commercial assumptions, and a clear basis for moving into technical planning.

The scope is existing vSphere 8 environments considering VVF 9.x or VCF 9.x. The current 9.1.1 feature documentation provides the product baseline as of October 26, 2026. Exact source-to-target compatibility, entitlement, and partner support remain environment-specific decisions.

Define the Decision Before Introducing the Products

I would open the workshop with one question:

What must this infrastructure environment be capable of delivering over the next three to five years, and what responsibilities is the organization prepared to own?

That question changes the discussion.

An infrastructure team may be perfectly capable of operating ESX hosts, vCenter, distributed switches, vSAN or external storage, backup software, and existing automation tools.

It may have no business requirement to become an internal cloud service provider.

Another organization may need multiple business units to request virtual machines, Kubernetes clusters, networks, and storage through governed self-service, with quotas, delegated roles, application-level policy, cost allocation, and standardized lifecycle management.

Those organizations need different platform operating models, even if both have the same number of hosts.

Separate three decisions that are often confused

These decisions are related, but none can substitute for another.

A customer may select VVF and still require a greenfield deployment because existing hardware is incompatible with ESX 9.

Another may select VCF but determine that an in-place convergence would retain unacceptable technical debt.

A third may select VVF as the immediate target and retain a future option to adopt VCF when its service-delivery requirements become mature enough.

The workshop should approve the first decision and define the conditions that govern the other two.

Build the Workshop Around Evidence, Not Preference

Before bringing stakeholders together, I would create a discovery package that identifies what is known, what is assumed, and what remains unverified.

The workshop is not the place to discover that the organization has NSX running in production, that its backup product has an unvalidated target release, or that a planned hardware refresh has no approved funding.

A useful intake package should contain four kinds of information: the current estate, the target service requirements, the organizational operating capability, and the financial constraints.

Current-state evidence

The critical point is that an inventory alone does not explain the organization’s desired future.

If the customer has 300 virtual machines and no self-service today, that does not prove it will never need automation.

Likewise, owning NSX licenses does not automatically prove that every NSX capability is deployed, critical, or must be preserved.

The evidence should distinguish deployed capabilities, consumed capabilities, planned requirements, and capabilities that exist only in an architecture presentation.

Define the future workload and service model

I would ask the customer to describe the next three to five years through concrete requirements.

For example, is the organization expecting to operate additional datacenters, integrate acquisitions, expand virtual desktop infrastructure, introduce Kubernetes services, deploy private AI workloads, increase application isolation, or standardize infrastructure delivery across business units?

Each answer should become a requirement with an owner, expected date, and observable acceptance condition.

A vague statement such as “we need cloud-like automation” is not ready to influence a purchase.

A stronger requirement would be:

Application teams must be able to request an approved three-tier development environment, including compute, storage, networking, and security policy, without creating separate infrastructure tickets. The service must have defined quotas, an accountable owner, and a controlled retirement process.

That is something the architecture team can evaluate.

It also allows the customer to determine whether VCF Automation is required, whether an existing external automation platform could satisfy the need, or whether the requirement is not yet funded.

Use Hard Gates Before a Weighted Scorecard

Weighted scorecards are useful when comparing credible options. They are dangerous when they allow a mandatory architectural failure to be offset by unrelated strengths.

Consider a customer whose production environment relies on NSX virtual networking and distributed security enforcement.

If the business requires those capabilities to be preserved within an integrated VMware platform, a VVF-only option cannot become acceptable simply because it scores well on price or implementation familiarity.

The same principle applies to supportability, recovery, regulatory requirements, and architectural feasibility.

The workshop should identify mandatory gates first.

The hard-gate model

The important part of this model is that a failed gate cannot be repaired by a favorable weighted score. The candidate must change, the requirement must be legitimately revised by its owner, or another architecture must be evaluated.

Establish explicit gate criteria

The status for each gate should be pass, fail, or unverified.

An unverified condition is not a pass. It is a required investigation with an owner and due date.

Understand what a hardware failure actually disqualifies

Suppose the customer has an older server generation that cannot run the selected ESX 9 release.

That does not automatically disqualify VVF or VCF as the target platform.

It disqualifies an implementation that depends on reusing those servers.

The architecture team must then evaluate replacement hardware, a parallel build, workload relocation, or an approved exception.

This distinction prevents the selection workshop from confusing product suitability with deployment feasibility.

Translate Platform Capabilities into Operational Requirements

Once the hard gates are established, I would compare the two platforms by what the customer actually needs to operate.

This is where the current Broadcom feature comparison becomes useful.

The October 14, 2026 comparison of VVF 9.1.1 and VCF 9.1.1 confirms that both platforms provide vSphere, vSAN capabilities, VMware vSphere Kubernetes Service (VKS), and VCF Operations capabilities. VCF expands the architecture with integrated NSX networking, VCF Automation, and broader fleet and private cloud services.

However, a feature’s presence in a product does not establish that it is licensed, deployed, integrated, or operationally useful in a particular environment.

I would use the following translation during the workshop.

The table describes architectural approaches, not a complete entitlement matrix. Some VCF advanced security, load balancing, recovery, and data services require separately licensed capabilities. The specific feature guide footnotes and commercial agreement govern the final bill of materials.

When VVF is enough

I would give VVF serious consideration when the customer already has a successful infrastructure operating model that does not require extensive redesign.

Consider a hypothetical regional enterprise operating three vCenter environments, conventional VLAN networking, external Fibre Channel storage, centralized backup, and a small infrastructure team.

The organization runs predominantly Windows and Linux virtual machines. Application provisioning is automated through existing scripts and templates. Its network team already operates corporate routing, firewalls, and address management.

The company expects normal application growth but has no funded requirement for integrated private cloud tenancy or self-service infrastructure.

In that case, VVF may provide the necessary modernization path without introducing capabilities that create additional operational work.

The recommendation would remain conditional on release compatibility, hardware suitability, subscription terms, recovery validation, and an acceptable four-year cost model.

I would not recommend VCF simply because the organization is large or has multiple vCenters.

When VCF changes the outcome

Consider a different hypothetical enterprise with several datacenters, significant NSX networking dependencies, multiple application teams, inconsistent provisioning practices, and a funded objective to deliver private cloud services.

The architecture requires infrastructure requests to include networking, security, compute, storage, and lifecycle policies.

Application teams need delegated access without unrestricted infrastructure administration. The platform team wants standardized management across its supported fleet.

This customer has a much stronger architectural reason to evaluate VCF.

Even then, I would want to prove that the organization can actually adopt the capabilities creating the value.

If VCF Automation is included in the business case, I want a defined service catalog, service owners, provisioning workflows, and a realistic implementation plan.

If NSX segmentation is a mandatory requirement, I want the existing policy inventory, target security design, and evidence of any advanced security entitlements required.

If fleet operations are expected to reduce administration effort, I want to understand the existing lifecycle work, the new management requirements, and what measurable work will disappear.

A VCF recommendation becomes credible when the customer can identify which operating responsibilities will change and why those changes are worth funding.

Evaluate the Management Footprint Before Assuming VCF Is Simpler

There is a technical dimension to the decision that feature comparisons rarely explain adequately.

VCF introduces management and lifecycle dependencies that must fit into the customer’s existing infrastructure and operating practices.

Broadcom KB 440630 documents VCF 9.1 management architecture requirements, including VCF Management Services, licensing services, management networking, and component upgrade sequencing.

For example, the documented VCF Management Services deployment requires an initial minimum allocation of 12 management-network IP addresses, with additional capacity available for expansion and future lifecycle requirements. The documentation also identifies internal service-network ranges that must be checked for overlap.

VCF Management Services is required in the VCF 9.1 deployment model and optional in the applicable VVF model. The centralized license server is a requirement for both.

That is more than an installer prerequisite.

The architecture team must establish how these services will be addressed, protected, monitored, updated, backed up, and recovered.

The infrastructure footprint is an operating commitment

I would ask the customer to validate the following before approving VCF:

• Is the existing management infrastructure suitable for the selected VCF deployment topology?
• Is management-network IP capacity available, including the required DNS records and future expansion allowance?
• Are the proposed vCenter boundaries compatible with the intended VCF management or workload domains?
• Can the team support NSX management, transport, and lifecycle requirements?
• Is there adequate compute, storage, and network capacity for management services during maintenance or failure?
• Who owns management-plane recovery, certificate lifecycle, software depots, licensing, and upgrades?

An affirmative answer should be supported by a preliminary design and capacity model.

For VVF, the same discipline applies to its deployed management components, but the required operating footprint may be smaller when full VCF fleet services and NSX are not needed.

The difference is not simply how many virtual appliances appear in the diagram.

It is how many interdependent services the organization must continuously support.

Score Only the Candidates That Pass Mandatory Requirements

Once both options have passed the mandatory gates, weighted scoring can help the customer compare the remaining tradeoffs.

I would not introduce a generic vendor scorecard with dozens of equally important criteria. I would use a relatively small set of decision dimensions with explicit weights and evidence requirements.

The following is an illustrative weighting model for a vSphere 8 customer. It is a starting framework, not a universal set of enterprise priorities.

For each criterion, the workshop should define what qualifies as a strong, moderate, or weak result before assessing either product.

The scoring formula can be simple:

Weighted Platform Score =

  Sum(
      Criterion Weight
      x Evidence-Based Score
  )

Only calculate a final score for candidates
that have passed every mandatory gate.

A five-point scale is sufficient, provided each point has a defined meaning and traceable evidence.

Unknown values should remain unknown rather than receiving an arbitrary middle score.

Do not let the score determine the architecture by itself

Suppose VCF scores higher on automation and future operating capabilities, while VVF scores higher on near-term implementation risk and projected costs.

The conclusion should not automatically be whichever number is larger.

I would examine three additional questions:

1. How much of the future capability is backed by a funded requirement rather than a hypothetical roadmap?
2. Can the current operating team support the management and organizational changes required to realize that capability?
3. Would a phased VVF-to-VCF strategy preserve value without imposing unnecessary change before the support deadline?

The score provides a transparent comparison. It does not eliminate architectural judgment.

A useful sensitivity exercise is to adjust the weights to reflect a credible change in business priorities.

If the recommendation changes when a speculative automation requirement receives less weight, the architecture decision is fragile. The customer should resolve that uncertainty before committing.

Build the Financial Comparison Around Equivalent Outcomes

I would not approve the VVF-versus-VCF business case using a subscription-price comparison alone.

The products differ in entitlement, management footprint, implementation scope, and potentially the integration work they allow the customer to retire.

A meaningful comparison needs a common time horizon and equivalent service requirements.

I would use four years as an initial planning baseline for this workshop, then test a three-year or five-year view if it better matches the customer’s hardware and subscription cycle.

The financial model

Four-Year Total Cost of Ownership =

  Subscription and Add-on Costs
+ Hardware and Infrastructure Costs
+ Platform Implementation Costs
+ Integration and Migration Costs
+ Backup, Recovery, and Security Costs
+ Operational Labor and Training
+ Parallel Running and Transition Costs
+ Risk and Contingency Allowances
- Verified Avoided Costs

The important word is verified.

I would not automatically credit VCF with reducing administrative staffing merely because its automation platform provides additional capabilities.

Nor would I assume VVF is less expensive simply because it has a narrower product scope.

For example, an enterprise could select VVF but continue funding separate tools for automation, network analysis, orchestration, and governance. Those costs belong in the VVF operating model.

Another enterprise could deploy VCF but fail to adopt its integrated services, carrying the platform cost while continuing to fund the original systems.

That is not an economic benefit. It is duplicated capability.

Normalize the comparison

Both options must be priced against equivalent business requirements.

That includes the same workload demand, capacity growth, availability assumptions, storage protection, operational support, and recovery objectives.

Where the architecture differs, the cost model should explain why.

Broadcom KB 437250 confirms that VMware 9.x licensing uses subscription-based license files managed through VCF Operations and the VCF Business Services console rather than traditional upgraded 25-character keys.

The customer must validate its specific eligibility and commercial arrangements. No universal discount, minimum purchase, or renewal penalty should be assumed from a generic price discussion.

Include the cost of change

Transition cost can materially alter the answer.

If the existing estate is already compatible with VVF 9.x, an in-place upgrade may have a different cost and risk profile from a new VCF deployment that also introduces NSX, additional management services, and redesigned operations.

However, if the customer’s environment has significant technical debt and requires new hardware regardless of product selection, that distinction may narrow.

The decision model must consider the architecture that can actually be delivered, not the cheapest theoretical deployment of either product.

Evaluate Future Flexibility and Conversion Risk

There is an important asymmetry between VVF and VCF.

Broadcom KB 455220 documents a convergence or conversion path from eligible VVF 9.x environments into VCF 9.x. The process can retain existing vCenter and ESX infrastructure while integrating the required VCF management components.

Broadcom KB 441960 also documents that the opposite direction is not an equivalent in-place conversion. Moving from an existing VCF 9 environment to VVF 9 requires fresh redeployment.

That should influence the architecture decision, particularly for customers uncertain about their long-term requirements.

VVF now, VCF later

This can be a legitimate phased strategy when the customer needs to exit vSphere 8 support but has not yet established a funded private cloud transformation.

The organization can target a supported VVF 9.x environment, modernize lifecycle and operations, and separately assess later VCF adoption.

But it must not assume that every VVF environment will automatically qualify for conversion.

The future VCF design should be tested against the documented prerequisites, including management topology, vCenter boundaries, network architecture, storage, lifecycle image management, and available infrastructure capacity.

A later conversion is still an architectural change.

VCF now, VVF later

I would approach this direction more cautiously.

If a customer is selecting VCF only because of uncertainty, with an assumption that it can simply downgrade the operating model later, that assumption is technically incorrect under current documented conversion rules.

Moving back to VVF requires a new deployment and an appropriate workload transition strategy.

That creates potential future costs involving migrations, licensing, management redesign, recovery reconfiguration, and coexistence.

Reversibility should therefore be a visible evaluation criterion.

A platform selection is stronger when the customer understands both how it will enter the architecture and what it would take to leave it.

Use Three Customer Profiles to Challenge the Recommendation

I would test the emerging decision against several realistic customer profiles rather than relying on the weighted model alone.

These examples are hypothetical and are intended to illustrate the workshop’s reasoning. They are not assessed customer environments.

Profile A: Traditional enterprise virtualization

The customer has a stable vSphere 8 environment, conventional network architecture, external enterprise storage, mature backup, limited private cloud requirements, and a centralized infrastructure team.

There is no significant NSX dependency and no approved initiative requiring integrated tenant self-service.

Initial direction: Evaluate VVF 9.x first.

The architecture decision would change if discovery reveals required VCF capabilities, significant NSX dependencies, or a compelling integrated operations business case.

The transition method would remain dependent on hardware compatibility and exact source builds.

Profile B: NSX-dependent enterprise private cloud

The customer has production NSX networks, security policies, several infrastructure domains, distributed application teams, and an approved modernization program.

The desired operating model requires stronger network integration, governed provisioning, and consistent platform lifecycle operations.

Initial direction: Evaluate VCF 9.x as the primary architecture candidate.

The workshop must still determine whether convergence, import, or a new deployment is appropriate.

Existing NSX usage is not enough to declare the entire estate ready for VCF. Network boundaries, current builds, management topology, backup, recovery, and supported workflows must all be validated.

Profile C: Virtualization today, private cloud aspirations tomorrow

The customer primarily runs conventional vSphere workloads but has a strategic roadmap for self-service and platform engineering.

The roadmap is credible but not yet fully funded. The infrastructure team needs a supported production platform before the October 2027 deadline.

Initial direction: Compare an immediate VCF deployment against VVF modernization with a separately approved VCF adoption phase.

I would favor the phased approach if VVF meets all current mandatory requirements, the future conversion can be designed responsibly, and early VCF adoption would increase schedule or operational risk without delivering near-term value.

I would favor VCF earlier if the required service-delivery capabilities have committed owners, funding, and a viable implementation plan.

This scenario is especially important because it prevents long-term ambition from becoming uncontrolled scope inside a time-sensitive lifecycle program.

The Operating Model Must Be Approved Alongside the Technology

A platform may be technically suitable and financially viable while still being the wrong operating model for the organization.

I would therefore require an ownership discussion as part of the architecture workshop.

This is an illustrative responsibility model, not a requirement that every organization use these exact team names.

The critical issue is whether each responsibility has one accountable owner and a documented execution path.

The question that exposes organizational readiness

I would ask:

If we select VCF and introduce self-service infrastructure, who will own the service catalog, tenant onboarding, quotas, network policy, template maintenance, service retirement, billing visibility, and incident escalation?

If the answer is still “the VMware administrators will figure that out,” the organization has not yet designed its private cloud operating model.

That does not automatically make VVF the better long-term choice.

It means the customer must fund and plan the organizational capability needed to use VCF effectively.

Turn the Workshop into an Approved Architecture Decision

The workshop should produce a decision record, not simply a presentation containing a preferred product.

I would capture the recommendation, assumptions, verified evidence, risks, unresolved conditions, and the events that would cause the decision to be revisited.

The following YAML is an illustrative, vendor-neutral decision artifact. It is not a Broadcom configuration file and does not execute a deployment.

decision:
  id: VMWARE-2027-PLATFORM-001
  title: vSphere 8 Target Platform Selection
  status: conditional-approval
  reviewDate: 2026-10-26

  currentState:
    platform: vSphere 8.x
    exactBuildsValidated: false
    hardwareCompatibilityValidated: false
    integrationsValidated: false

  businessObjectives:
    - remain-on-supported-platform
    - preserve-production-services
    - maintain-recovery-capability
    - establish-four-year-operating-model

  hardGates:
    applicationSupport: unverified
    networkSecurityRequirements: pending-review
    recoveryObjectives: pending-test
    hardwareCompatibility: unverified
    subscriptionEligibility: pending-confirmation
    operationalOwnership: pending-approval

  candidates:
    - VMware vSphere Foundation 9.x
    - VMware Cloud Foundation 9.x

  provisionalDecision:
    preferredPlatform: VMware vSphere Foundation 9.x
    rationale: >
      Current requirements favor virtualization
      modernization without a funded integrated
      private cloud service-delivery model.
    implementationMethod: not-yet-approved

  approvalConditions:
    - validate-exact-build-interoperability
    - verify-hardware-and-storage-support
    - confirm-subscription-entitlements
    - complete-representative-recovery-test
    - approve-transition-cost-and-risk
    - confirm-platform-operations-ownership

  reviewTriggers:
    - mandatory-nsx-requirement
    - funded-private-cloud-automation-program
    - material-commercial-change
    - unsupported-hardware-discovery
    - failed-pilot-or-recovery-test

  accountability:
    decisionOwner: enterprise-architecture
    businessApprover: infrastructure-sponsor
    technicalApprover: platform-engineering
    riskReviewer: security-and-resilience

In this example, VVF is the provisional preference, but implementation remains unapproved because several mandatory evidence items are unresolved.

That is intentional.

A successful workshop may produce a conditional architectural direction without pretending that compatibility, recovery, and licensing have already been demonstrated.

The artifact should be updated as those conditions are resolved and attached to the customer’s architecture decision record or change-governance system.

How I Would Run the Customer Workshop

I would organize the engagement into three working sessions, supported by discovery and evidence review.

The sessions are not intended to teach every product feature. Their purpose is to move from requirements to an approved decision.

The customer should have architecture, platform operations, networking, security, application ownership, recovery, finance, and procurement represented through the appropriate parts of the engagement.

One representative does not need to attend every minute, but every material requirement needs an accountable owner.

What the customer should leave with

I would expect four concrete artifacts.

An approved requirements baseline. This identifies mandatory capabilities, operating goals, constraints, assumptions, and evidence owners.

Two credible architecture candidates. Both should be sufficiently developed to compare management topology, networking, storage, lifecycle, recovery, and operational responsibilities.

A decision and commercial assessment. This records the recommended direction, hard-gate results, weighted evaluation, cost assumptions, risks, and circumstances that could change the decision.

A transition planning authorization. This defines the work needed to validate exact builds, hardware, licensing, migration method, and pilot scope before production changes are approved.

At the end of the workshop, the customer should be able to explain why VVF or VCF was selected without referring only to a feature checklist or a sales quote.

What I Would Not Allow Into the Final Recommendation

Several shortcuts can make the selection appear more complete than it is.

Choosing VCF because it is the larger product. Broader capabilities are valuable only when the customer has an actual requirement and can operate them.

Choosing VVF purely because the customer uses VLANs and external storage. VCF can still be appropriate when its lifecycle, networking, automation, security, or governance architecture provides necessary value.

Scoring future capabilities without funding or ownership. An ambition to introduce private cloud self-service should not receive the same evidence confidence as an approved implementation requirement.

Assuming existing infrastructure can simply be converted. VCF convergence and import have prerequisites that can determine whether the existing architecture is eligible.

Ignoring lifecycle and licensing dependencies. Both platforms have requirements that extend beyond installing ESX and vCenter. Version 9 licensing and current deployment guidance must be incorporated into the target design.

Treating future conversion as symmetrical. The documented VVF-to-VCF option does not establish an equivalent in-place VCF-to-VVF path.

Declaring a decision final before the critical evidence exists. A conditional recommendation is legitimate. An unverified compatibility assumption presented as a completed assessment is not.

The workshop should expose these risks rather than smoothing them over to create an easier executive presentation.

Conclusion

The VVF-versus-VCF decision is best treated as an enterprise architecture selection with operational, commercial, and lifecycle consequences.

VVF 9.x can be the appropriate destination for organizations that need a capable workload platform, a familiar virtualization operating model, modern lifecycle processes, and integration with existing network, storage, security, and automation services.

VCF 9.x becomes more compelling when the customer needs integrated private cloud services, NSX networking, automation, tenancy, coordinated fleet management, and a platform operating model designed to serve multiple infrastructure consumers.

Neither recommendation should be based solely on product packaging.

The strongest customer decision begins with non-negotiable requirements, evaluates only the architectures that satisfy them, tests realistic cost and operating assumptions, and preserves the evidence behind the final choice.

For a customer currently running vSphere 8, I would complete this decision before approving the detailed migration execution plan. The platform choice should direct the transition strategy, not be an accidental consequence of whichever upgrade workflow appeared easiest.

The next practical action is to authorize a source-to-target compatibility assessment using the selected architecture, complete current build inventory, supported hardware and storage information, and approved recovery constraints.

That leads directly into Part 3 of this series, where the architecture decision becomes an exact-build, dependency-aware transition plan from vSphere 8 to VMware 9.x.

External References

• VMware by Broadcom: VMware Cloud Foundation 9.1.1 and VMware vSphere Foundation 9.1.1: Feature Comparison & Upgrade Paths
• Broadcom: End of General Support for vSphere 8.0 (KB 459135)
• Broadcom: Upgrade Sequence and Related Issues for VMware Cloud Foundation and vSphere Foundation 9.1 (KB 440630)
• Broadcom: Converge or convert from VVF to VCF 9 (KB 455220)
• Broadcom: Migrating or converting from VCF 9 to VVF 9 (KB 441960)
• Broadcom: Upgrade path from vSphere 8.x to VMware vSphere Foundation (VVF) 9 or VMware Cloud Foundation (VCF) 9 (KB 437250)
• Broadcom: Verifying hardware compatibility for an upgrade from vSphere 8.0 U3 to VCF 9.x (KB 443586)

vSphere 8 End of Support: Build the 2027 Transition Program Before Choosing VVF or VCF

Plan the vSphere 8 exit before October 11, 2027, with VVF or VCF selection, dependency mapping, migration waves, and production acceptance.

Next Post

vSphere 8 to VMware 9.x: Building the Exact Build Compatibility and Transition Plan

Part 3 of 4 in the vSphere 8 exit series. TL;DR Moving from VMware vSphere 8.x to VMware vSphere Foundation (VVF) 9.x or VMware Cloud Foundation (VCF) 9.x requires more…

The post Choosing VVF 9.x or VCF 9.x from vSphere 8: The Customer Decision Workshop appeared first on Digital Thought Disruption.