TL;DR
Consolidating older vSphere and VMware Cloud Foundation environments onto VCF 9.1 is not one upgrade procedure. It is a portfolio decision involving four different actions: upgrading an existing VCF instance, converging suitable vSphere infrastructure into a new VCF instance, importing an existing vCenter as a workload domain, or migrating workloads into a clean VCF 9.1 target.
The best design does not force every cluster into one giant management boundary. It creates a smaller number of intentional VCF instances and workload domains based on lifecycle, security, hardware, availability, ownership, and operational requirements.
Before selecting a path, inventory the complete environment, including hardware compatibility, vSphere Distributed Switch usage, NSX state, storage, certificates, identity, plug-ins, backup systems, disaster-recovery dependencies, and workload mobility constraints. Unsupported or heavily customized environments are usually better treated as migration sources rather than direct conversion candidates.
Introduction
Many VMware estates were not designed as one private cloud. They grew through hardware refreshes, acquisitions, application projects, data-center expansions, and separate administrative teams.
The result is often a mixture of:
Standalone vSphere clusters managed by independent vCenter Servers
Older VCF instances at different patch and component levels
Separate identity and Single Sign-On boundaries
Inconsistent distributed-switch designs
Multiple NSX deployments
Different storage platforms and storage policies
Duplicate monitoring, backup, automation, and lifecycle tools
Hardware generations with different remaining service lives
Business-critical workloads that cannot all use the same migration method
VCF 9.1 creates an opportunity to simplify that environment, but simplification requires more than moving virtual machines or upgrading ESX hosts. The organization must decide which control planes should survive, which infrastructure should be adopted, which workloads should move, and which legacy environments should be retired.
The central design question is therefore not:
How do we upgrade everything to VCF 9.1?
A better question is:
Which legacy components should become part of the VCF 9.1 operating model, and which should exist only long enough to migrate their workloads?
That distinction prevents an organization from rebuilding its existing sprawl inside a newer product version.
Consolidation Is a Control-Plane Redesign
A server-consolidation project focuses on reducing physical hosts. A VCF consolidation project must also reduce management-plane duplication and establish repeatable lifecycle boundaries.
An environment can contain fewer hosts and still remain operationally fragmented if it retains:
Too many vCenter Servers
Too many SSO domains
Duplicate NSX management clusters
Separate lifecycle processes
Inconsistent identity integrations
Multiple monitoring and logging stacks
Uncoordinated certificate authorities
Different configuration baselines
Separate backup and disaster-recovery registrations
Custom scripts that depend on retired object names or APIs
VCF 9.1 introduces fleet, instance, domain, operations, lifecycle, and management-services considerations that must be designed before migration begins. The platform should not be treated as a collection of upgraded VMware components.
The target state needs explicit answers to four questions:
How many VCF fleets are required?
How many VCF instances should exist in each fleet?
Which workload-domain boundaries are operationally meaningful?
Which legacy management planes can be retired?
The answers should be based on failure domains, lifecycle independence, security, geography, ownership, and recovery requirements, not only on the current number of vCenter Servers.
The Four Consolidation Paths
Broadcom provides several ways to begin building or expanding a VCF 9.1 platform. In a consolidation program, these become four practical design paths.
Upgrade an Existing VCF Instance
Use the VCF lifecycle process when the source is already a healthy, supported VCF environment and its current topology remains appropriate.
This path generally preserves:
The VCF instance
Management and workload-domain boundaries
Existing vCenter relationships
Existing NSX relationships
Current infrastructure placement
Operational history and configuration
An upgrade is usually the least disruptive option, but it does not automatically consolidate anything. After the upgrade, duplicate workload domains, clusters, management tools, and integrations may still need to be rationalized.
Converge Existing vSphere Infrastructure
Convergence uses existing virtual infrastructure as the foundation for a new VCF or vSphere Foundation platform.
This can be appropriate when the existing environment:
Is already close to the required VCF architecture
Uses supported hardware and software
Has a clean distributed-switch design
Meets network, DNS, certificate, and identity prerequisites
Does not contain unsupported topology features
Can accommodate the VCF management components
Has enough remaining lifecycle value to justify adoption
Convergence is not a universal conversion mechanism for every legacy vSphere environment. It should be selected only after all supported-configuration checks pass.
Import an Existing vCenter as a Workload Domain
An existing vCenter can be imported into a VCF instance as a workload domain when the source configuration meets the applicable prerequisites.
This path can preserve the existing workload environment while bringing it under VCF inventory and lifecycle control.
Import can reduce immediate workload movement, but it also preserves much of the source environment. Existing naming, cluster layout, networking, storage decisions, plug-ins, and technical debt may become part of the target platform.
For that reason, import should be treated as controlled adoption, not automatic cleanup.
Migrate Workloads into a Clean VCF 9.1 Target
A clean target is often the safest option when the source environment is too old, too customized, too fragmented, or too close to hardware retirement.
Workloads can be moved by methods such as:
Cross-vCenter vMotion
Cold migration
Shared-storage relocation
VMware HCX vMotion
HCX Bulk Migration
HCX Replication Assisted vMotion
Application-level replication
Backup and restore
Storage-array replication
Rebuild and data migration
This path requires more workload planning, but it avoids importing unsupported topology and years of accumulated configuration drift.
Comparing the Consolidation Paths
PathBest fitPrimary advantageMain riskUpgrade existing VCFHealthy and supported VCF instance with a valid upgrade pathPreserves the established VCF architecture and workload placementPreserves unnecessary domains, integrations, and legacy design choicesConverge existing vSphereSupported vSphere environment that can become the first VCF instanceReuses infrastructure while establishing a VCF management planeSource configuration may fail convergence prerequisitesImport existing vCenterSupported vCenter environment that should remain intact as a workload domainAvoids immediate mass workload migrationImports technical debt and operational inconsistenciesMigrate into clean VCFUnsupported, aging, highly customized, or strategically obsolete environmentProduces the cleanest target architectureRequires migration capacity, application coordination, and coexistence design
The correct answer may differ by environment. A large enterprise might upgrade two VCF instances, import one relatively modern vCenter, and migrate workloads out of several older vSphere environments.
That is not inconsistency. It is path selection based on evidence.
Target-State Architecture Principles
The target VCF 9.1 design should be established before source environments are assigned migration paths.
Design One Operating Model, Not One Giant Cluster
Consolidation does not require placing every workload in the same vCenter, cluster, or workload domain.
A large shared domain can create:
Oversized maintenance windows
Wider lifecycle blast radius
Increased resource contention
More complex security delegation
Difficult application coordination
Larger failure and recovery domains
Conflicting hardware requirements
The goal is to reduce arbitrary boundaries while retaining the boundaries that protect operations.
Treat Domains as Lifecycle and Isolation Boundaries
Create separate workload domains when there is a durable reason for independent lifecycle or isolation.
Valid reasons can include:
Different maintenance windows
Separate regulatory controls
Distinct security administration
Dedicated hardware or accelerator requirements
Separate availability-zone designs
Different storage architectures
Service-provider or tenant isolation
Independent business ownership
Different support or recovery models
A domain should not exist only because a legacy vCenter existed.
Separate Fleet Design from Workload Placement
The fleet establishes shared management and governance services. The VCF instance represents a discrete software-defined data-center footprint. Workload domains establish more focused lifecycle and isolation boundaries.
These constructs should not be collapsed into a single design decision.
A company may reasonably operate:
One fleet for centralized governance
Multiple VCF instances for geographic or failure isolation
Multiple workload domains inside each instance
Multiple clusters inside a domain when they share lifecycle requirements
Prefer the Path That Retains the Least Unnecessary Debt
The fastest technical path is not always the lowest-risk strategic path.
Importing a vCenter may be faster than migrating its workloads, but migration may be better when the source contains:
Obsolete network constructs
Unsupported server hardware
Uncontrolled plug-ins
Inconsistent host images
Legacy certificates
Unclear ownership
Poorly documented dependencies
Workloads already scheduled for modernization or retirement
The path decision should account for the cost of operating the imported design for several years after consolidation.
A Practical Target-State Model
The following model shows the intended separation between centralized governance and deliberate infrastructure boundaries.
The point is not that every organization needs two instances or four domains. The point is that consolidation should occur at the correct layer.
Centralize governance where consistency creates value. Preserve separate instances and domains where isolation creates value.
Build a Complete Source Inventory
A migration decision made from an RVTools export alone will be incomplete. Virtual-machine inventory is important, but the hardest consolidation problems usually involve management dependencies rather than VM count.
Each source environment should have a structured evidence pack.
Discovery areaEvidence to collectWhy it affects the pathProduct versionsExact vCenter, ESX, VCF, SDDC Manager, NSX, vSAN, HCX, and management-product buildsDetermines supported upgrade, convergence, import, and migration combinationsHardwareServer models, firmware, adapters, boot devices, CPU generations, support status, and remaining lifecycleDetermines VCF 9.1 compatibility and whether reuse is economically sensibleCluster designHA, DRS, EVC, admission control, resource pools, affinity rules, vCenter HA, and special clustersIdentifies unsupported or migration-sensitive configurationsNetworkingVSS and vDS usage, vDS versions, VMkernel services, MTU, VLANs, uplinks, LACP, NSX preparation, and port groupsDetermines convergence readiness and workload-mobility feasibilityStoragePrincipal storage, datastore types, storage policies, replication, stretched configurations, RDMs, and shared disksAffects platform support, migration method, and recoveryIdentitySSO domains, identity providers, service accounts, permissions, local accounts, and privileged accessDetermines future authentication and administrative boundariesCertificatesCertificate authorities, expiration dates, SANs, trust stores, and appliance certificatesFrequently blocks import, integration, or lifecycle workflowsIntegrationsBackup, monitoring, CMDB, automation, security, hardware management, and IT service managementIdentifies systems that must be re-registered or redesignedWorkload exceptionsvGPU, passthrough, SR-IOV, encryption, vTPM, shared disks, appliances, large disks, and latency-sensitive VMsDetermines whether live migration is possibleRecoveryBackup, replication, recovery plans, ransomware recovery, and site dependenciesPrevents consolidation from weakening recoverabilityCustomizationAdvanced settings, host scripts, custom VIBs, plug-ins, alarms, scheduled tasks, and unsupported changesReveals configuration that may not survive adoption or upgrade
Every finding should be assigned an owner and one of four dispositions:
Retain
Remediate
Replace
Retire
An unresolved inventory item should block final path selection when it affects supportability or recoverability.
Route Each Source Environment Through a Decision Gate
The following decision flow can be applied to each vCenter or VCF instance.
Passing the technical decision gate does not automatically mean the path is desirable. A second architecture gate should ask:
Does this preserve an unwanted topology?
Does it extend the life of hardware that should be retired?
Does it create another long-term VCF instance?
Does it preserve an unnecessary SSO or NSX boundary?
Will the environment be supportable after the next lifecycle event?
Does the path reduce or increase operational complexity?
A technically supported import may still be a poor architecture decision.
Design Guidance for Older VCF Environments
Existing VCF environments should normally remain under VCF lifecycle control. Avoid independently upgrading vCenter, ESX, NSX, or integrated management components outside the supported VCF sequence.
Validate the Exact Source and Target Builds
Do not plan only around marketing versions such as “VCF 5.2” or “VCF 9.1.” Patch levels and component builds can change the required sequence.
For example, a patch-level target may require an intermediate update even when a base-version upgrade appears direct. The source-of-truth upgrade documentation and current release notes must be reviewed immediately before the change.
The upgrade plan should capture:
Current VCF and SDDC Manager build
Current component bill of materials
Target VCF 9.1 patch build
Required intermediate hops
Component upgrade order
Known issues for every hop
Offline or online depot method
Backup requirements
Rollback and recovery limits
Upgrade Before Consolidating Domains
Trying to change topology and product versions in the same window creates unnecessary troubleshooting ambiguity.
A safer sequence is:
Stabilize the existing VCF environment.
Resolve health and certificate issues.
Upgrade through the supported path.
Validate lifecycle and monitoring.
Rationalize clusters and domains.
Migrate workloads where boundaries should change.
Retire unnecessary domains and infrastructure.
This separates platform lifecycle risk from workload-movement risk.
Review the VCF 9.1 Management-Services Change
VCF 9.1 changes parts of the fleet and lifecycle architecture. The design must reserve the necessary management-network address space, DNS records, certificates, appliance resources, and internal network ranges.
Broadcom’s current upgrade guidance identifies specific management-services address requirements and an internal service network that must not overlap with the management environment. These values should be revalidated against the exact target patch before implementation.
The centralized license-server design is also part of the target architecture. DNS, connectivity, entitlement, registration, backup, and operational ownership should be planned rather than handled as a late deployment task.
Treat NSX as a Separate Readiness Workstream
NSX version lineage, host preparation, transport-node state, edge design, certificates, backups, and upgrade chronology can determine whether a domain can move directly.
Do not assume that an NSX environment is safe to adopt merely because its hosts and vCenter pass basic checks.
Validate:
NSX Manager version and build
Cluster health and backup status
Transport-node state
Host-switch configuration
Edge-cluster availability
Tier-0 and Tier-1 dependencies
Distributed firewall policies
Partner-service integrations
Certificates and principal identities
Upgrade compatibility with the target VCF bill of materials
Where NSX lineage creates an unsupported upgrade path, workload migration and network-policy reconstruction may be safer than forced adoption.
Design Guidance for Older vSphere Environments
Older vSphere environments require an explicit choice between convergence, workload-domain import, and migration.
Use Convergence Selectively
Convergence is strongest when the existing environment is structurally close to the desired management domain.
Good candidates typically have:
Supported vCenter and ESX levels
Compatible server hardware
Consistent host images
vSphere Distributed Switch networking
Healthy DNS and NTP
Valid certificates
Available management capacity
No blocking topology features
Clear administrative ownership
A cluster that requires extensive redesign before convergence may be better used as a temporary migration source.
Remove Unsupported Topology Before Adoption
Current VCF 9.x guidance requires distributed-switch-based management networking. Environments still dependent on vSphere Standard Switches must be redesigned before supported convergence.
Current Broadcom guidance also calls out vCenter High Availability as unsupported in relevant VCF 9.1 convergence and upgrade scenarios. Do not assume that an existing vCenter architecture can be adopted unchanged.
Other features that deserve specific verification include:
Enhanced Linked Mode
vSphere Supervisor
VMware Cloud Director integration
Third-party networking
Third-party storage plug-ins
Custom ESX images
Custom VIBs
External Platform Services Controller remnants
Legacy NSX configurations
Unsupported certificate arrangements
Absence from a generic checklist should not be interpreted as approval. Obtain explicit confirmation for uncommon or business-critical designs.
Import Only What You Intend to Keep
Importing a vCenter as a workload domain can be useful for a modern, healthy workload estate.
Before import, decide whether the following source constructs should remain:
Cluster boundaries
vDS topology
Network names
Datastore layout
Storage policies
Folder structure
Resource pools
Permission model
Tag categories
Alarm definitions
Backup registrations
Automation dependencies
If most of these need to change, migration into a clean workload domain will usually provide a clearer result.
Workload Mobility Must Be Designed as a Service
A large consolidation program needs a repeatable migration service rather than a collection of one-off change tickets.
Select Migration Methods by Workload Characteristics
Workload characteristicLikely migration approachStandard VM with compatible networking and CPUCross-vCenter vMotion or HCX vMotionLarge migration wave with short cutoverHCX Bulk Migration or Replication Assisted vMotionPowered-off or low-priority workloadCold migrationShared storage visible to both environmentsCompute-only relocation where supportedVery large VMPre-copy, replication, or storage-assisted method after throughput testingWSFC or shared-disk workloadApplication-specific or storage-replication procedurevGPU, passthrough, or SR-IOV workloadHardware-aware cold migration or rebuildAppliance with vendor restrictionsVendor-supported migration or redeploymentDatabase with strict consistency requirementsDatabase-native replication or coordinated backup and restoreObsolete applicationRetire, archive, or isolate instead of migrating by default
The migration tool should be selected after classifying the workload, not before.
Build Network Mapping Before the First Wave
Every source network needs an intentional target disposition:
Preserve the subnet temporarily
Stretch the network
Map to a new port group
Re-IP the workload
Place behind a new gateway
Move into an NSX segment
Replace with an application-level endpoint
Retire the network
Do not let temporary Layer 2 extension become the permanent architecture by accident.
For every network, define:
Source and target gateway
Routing ownership
Firewall-policy translation
DNS changes
Load-balancer changes
Address-management updates
Monitoring and flow visibility
Rollback behavior
Date for removing temporary extension
Test the Complete Data Path
A successful ping does not validate workload mobility.
Test:
vMotion and provisioning interfaces
Required TCP ports
MTU across the complete physical and virtual path
Routing symmetry
Firewall state
DNS resolution
Time synchronization
Storage throughput
Replication throughput
Packet loss and latency
Target network availability
Source and destination vDS compatibility
CPU compatibility and EVC
Migration duration for representative workloads
Large migrations should be tested with data volumes that resemble production, not only with small utility VMs.
A Phased Consolidation Strategy
Establish Governance and Scope
Define the program boundaries before technical discovery begins.
Required decisions include:
Executive sponsor
Platform owner
Architecture authority
Security owner
Network owner
Storage owner
Workload migration owner
Application-owner responsibilities
Change-approval process
Exception process
Decommission authority
The consolidation charter should state which environments are included, which are excluded, and what measurable outcomes define success.
Discover and Classify
Create a normalized inventory across all vSphere and VCF environments.
Classify each environment by:
Support status
Hardware runway
Upgrade eligibility
Convergence eligibility
Import eligibility
Workload-mobility complexity
Business criticality
Recovery criticality
Technical-debt level
Decommission target date
The output should be an environment disposition matrix, not just a raw inventory export.
Design the VCF 9.1 Target
Complete the target architecture before beginning broad remediation.
Define:
Fleet boundaries
VCF instance boundaries
Management-domain placement
Workload-domain design
Cluster standards
Host profiles and images
vDS and NSX architecture
Storage and policy architecture
Identity and role model
Certificate model
VCF Operations design
License-server placement
Backup and recovery
Depot and lifecycle connectivity
Capacity reserve
Monitoring and alert ownership
The design should include failure domains, ownership boundaries, and future expansion.
Remediate Source Environments
Typical remediation includes:
Moving management networking to a supported vDS
Removing unsupported vCenter HA configurations
Updating firmware and host images
Replacing expired or invalid certificates
Correcting forward and reverse DNS
Cleaning stale plug-ins and extensions
Removing abandoned hosts and datastores
Consolidating snapshots
Repairing vSAN or NSX health
Documenting service accounts
Removing unused networks
Validating backups
Resolving time synchronization
Establishing configuration baselines
Do not hide remediation inside the production migration window.
Build and Validate the First Target
Deploy, upgrade, or converge the first VCF 9.1 target and treat it as a production platform before moving large workload waves.
Validate:
Platform health
VCF Operations inventory
Lifecycle bundle access
License assignment
Password and certificate workflows
Backup and restore
Identity integration
Host commissioning
Cluster expansion
Network creation
Storage-policy behavior
Logging and alerting
Support-data collection
Change and incident procedures
The first target should be operated through at least one normal maintenance cycle before it becomes the destination for the highest-risk workloads.
Pilot Each Migration Pattern
Do not use one successful test VM as evidence that every migration pattern works.
Run separate pilots for:
Cross-vCenter vMotion
HCX Bulk Migration
Network extension
Re-IP migration
Large VM migration
Database migration
Shared-disk application
Encrypted VM
vTPM workload
Backup restoration
Disaster-recovery re-registration
Each pilot should produce a validated runbook and measured throughput.
Execute Controlled Migration Waves
Group workloads by dependency and recovery needs.
A practical sequence is:
Low-risk infrastructure services
Development and test systems
Stateless production applications
Standard stateful applications
Large databases and file services
Clustered and shared-disk workloads
Security and management appliances
Remaining exceptions
Every wave needs entry criteria, rollback criteria, technical validation, application validation, and a named business approver.
Stabilize and Decommission
A workload being powered on in the target does not mean the source can be immediately removed.
Complete:
Backup-policy validation
Monitoring registration
Security verification
Performance baseline comparison
Recovery-plan updates
CMDB updates
License reassignment
DNS cleanup
Load-balancer cleanup
Firewall-rule cleanup
Replication removal
Network-extension removal
Source datastore cleanup
Host decommissioning
Certificate revocation
Service-account revocation
vCenter or VCF shutdown
Asset and contract updates
Decommissioning should have its own approved runbook and evidence package.
Best Practices for Reducing Consolidation Risk
Use Read-Only Discovery First
The first automation pass should collect evidence, not modify the environment.
Export:
Inventory
Versions
Host hardware
Cluster settings
vDS configuration
VMkernel services
Datastores
Storage policies
VM devices
Snapshots
Tags
Permissions
Alarms
Certificates
Integrations
Change automation should be introduced only after the desired target state is approved.
Preserve Recovery Before Preserving Convenience
Before upgrading, converging, or importing an environment, prove that its management components and critical workloads are recoverable.
Confirm:
Supported backups exist
Backups are recent
Restore procedures are documented
Encryption keys are protected
NSX backups are valid
Recovery credentials are available
Recovery infrastructure is independent enough to survive the change
Application owners understand rollback limitations
A convenient import path is not valuable if it weakens recovery confidence.
Keep Temporary Coexistence Explicit
During consolidation, two operating models may exist at the same time.
Document which platform owns:
Identity
Monitoring
Backup
Patching
Incident response
Capacity
Network policy
Security exceptions
Change approval
Disaster recovery
Every temporary relationship should have an expiration condition.
Protect Capacity for the Migration Itself
The target needs more capacity than the final steady-state workload total.
Reserve resources for:
Replication appliances
HCX components
Temporary duplicate VMs
Snapshot growth
Storage migration
Failed-wave rollback
Rebalancing
Host maintenance
N+1 or N+2 resilience
Management-services expansion
A target that is sized only for final workload consumption may be unable to perform the migration safely.
Track Decisions as Architecture Records
For each source environment, record:
Selected path
Alternatives considered
Evidence
Assumptions
Required remediation
Expected outage
Rollback method
Long-term operating impact
Owner
Approval
Review trigger
This prevents the same decision from being reopened during every migration wave.
Common Failure Patterns
Treating “Supported” as “Recommended”
A supported import may still preserve an inefficient cluster layout or aging hardware.
Supportability is an entry condition. It is not the complete architecture decision.
Upgrading Components Independently
Independent vCenter, ESX, NSX, or management-product upgrades can move a VCF environment outside its supported bill of materials and disrupt lifecycle management.
Use the supported VCF sequence.
Ignoring Distributed-Switch Readiness
VCF 9.x convergence and upgrade workflows expect supported distributed-switch networking. Legacy VSS dependencies should be identified and remediated early.
Discovering Certificate Problems During Import
Expired certificates, missing SANs, untrusted roots, and inconsistent appliance names commonly block integration workflows.
Perform a certificate and DNS audit before the change window.
Underestimating Special Workloads
RDMs, WSFC shared disks, vGPU, passthrough devices, encrypted VMs, vTPM, appliances, and very large VMs require separate migration patterns.
Do not leave these workloads for the end without an approved method.
Preserving Every Legacy Boundary
One workload domain per former vCenter may reproduce the previous sprawl.
Require a documented lifecycle, security, availability, or ownership reason for each boundary.
Retiring the Source Too Early
Application testing may pass while backups, monitoring, replication, security policy, or disaster recovery remain incomplete.
Use operational acceptance, not only VM power state, as the decommission gate.
Operating the Consolidated VCF 9.1 Platform
The program is complete only when the new environment has a sustainable operating model.
Define ownership for:
CapabilityAccountable roleFleet architectureEnterprise or private-cloud architectureVCF instance lifecycleVCF platform engineeringWorkload-domain lifecyclePlatform operationsIdentity and privileged accessIdentity and security teamsNSX networking and securityNetwork virtualization and security teamsStorage policies and capacityStorage and platform operationsVCF OperationsOperations engineeringLicense server and entitlementPlatform owner and software-asset managementBackup and recoveryData protection and application ownersWorkload migration serviceMigration factory or platform engineeringApplication acceptanceApplication ownerDecommission approvalInfrastructure owner and business sponsor
The post-consolidation platform should have:
One authoritative inventory
Standard host and cluster baselines
Repeatable lifecycle windows
Clear exception governance
Capacity and cost reporting
Certificate and password ownership
Tested backup and recovery
Documented workload placement criteria
A process for adding and retiring domains
A process for reviewing unsupported drift
Without this operating model, the consolidated platform will gradually fragment again.
Conclusion
Consolidating older vSphere and older VCF environments onto VMware Cloud Foundation 9.1 is a platform-design program, not a mass upgrade exercise.
Existing VCF instances should follow supported lifecycle paths when their topology remains valid. Suitable vSphere environments can be converged or imported when they meet the required architecture and support conditions. Aging, unsupported, or heavily customized environments should usually remain migration sources while their workloads move into a clean target.
The strongest VCF 9.1 designs centralize governance without creating unnecessary blast radius. They use fleets, instances, workload domains, and clusters as deliberate operating boundaries. They preserve isolation where it protects the business and remove boundaries that exist only because of historical growth.
The practical path is to inventory first, design the target second, remediate third, and then select the least risky path for each source environment. Upgrade, convergence, import, and workload migration are all valid tools. The mistake is assuming that one of them is correct for every environment.
External References
Broadcom TechDocs: VMware Cloud Foundation 9.1Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1.html
Broadcom TechDocs: VMware Cloud Foundation 9.1 Release NotesCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/release-notes/vmware-cloud-foundation-9-1-0-0-release-notes.html
Broadcom TechDocs: Getting Started with VMware Cloud FoundationCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/overview-of-vmware-cloud-foundation-9/getting-started-with-vcf.html
Broadcom TechDocs: Upgrading to VMware Cloud Foundation 9.1Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/deployment/upgrading-cloud-foundation.html
Broadcom Knowledge Base: Upgrade Sequence and Related Issues for VMware Cloud Foundation and vSphere Foundation 9.1Canonical URL: https://knowledge.broadcom.com/external/article/440630/upgrade-sequence-and-related-issues-for.html
Broadcom TechDocs: Converging Existing Virtual Infrastructure to a VCF or a vSphere Foundation PlatformCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/deployment/converging-your-existing-vsphere-infrastructure-to-a-vcf-or-vvf-platform-.html
Broadcom TechDocs: Supported and Not Supported Configurations to Converge to VCFCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/deployment/converging-your-existing-vsphere-infrastructure-to-a-vcf-or-vvf-platform-/supported-and-not-supported-configurations.html
Broadcom TechDocs: Import an Existing vCenter to Create a Workload DomainCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/building-your-private-cloud-infrastructure/working-with-workload-domains/import-an-existing-vcenter-to-create-a-workload-domain.html
Broadcom TechDocs: VCF Operations Detailed DesignCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/design/design-library/vcf-operations-design.html
Broadcom Knowledge Base: Cross vCenter Migration and Clone Requirements in VMware vSphere 6.x and LaterCanonical URL: https://knowledge.broadcom.com/external/article/344959/cross-vcenter-migration-and-clone-requir.html
Broadcom TechDocs: VMware HCX Migration TypesCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/hcx/vmware-hcx/9-0/vmware-hcx-user-guide-vcf-9-0/migrating-virtual-machines-with-vmware-hcx/vmware-hcx-migration-types.html
Broadcom TechDocs: SDDC Manager 9.1.0.0100 Release NotesCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/release-notes/patch-releases-9-1-0-x/vcf-installer/sddc-manager-9-1-0-0100-release-notes.html
On-Prem Private AI Series: Dell AI Factory with NVIDIA and Red Hat OpenShift AI as the AI Factory Build Pattern
TL;DR Dell AI Factory with NVIDIA and Red Hat OpenShift AI is the private AI option for organizations that want a validated…
The post Consolidating Legacy vSphere and Older VCF onto VMware Cloud Foundation 9.1: Design Patterns, Migration Paths, and Best Practices appeared first on Digital Thought Disruption.