Introduction
The phrase “import an existing vCenter” sounds safer than it really is.
It suggests that VMware Cloud Foundation reads an inventory, registers a few objects, and leaves the underlying environment largely untouched. That description is incomplete. In VMware Cloud Foundation 9.1, brownfield adoption is a change in platform ownership, lifecycle control, management topology, networking dependencies, storage governance, and recovery responsibility. The virtual machines may continue running, but the environment around them is being absorbed into a different operating model.
That is why the right question is not simply whether the VCF 9.1 import workflow can discover the current vCenter. The real question is whether the existing vCenter boundary, every cluster beneath it, the host lifecycle state, the network design, the storage architecture, the management-appliance placement, and the organization’s rollback expectations are suitable for VCF ownership.
Broadcom documents two primary brownfield paths. An organization with an existing VCF fleet can import an existing vCenter as a VI workload domain through VCF Operations. An organization without an existing VCF instance can use the VCF Installer to converge an existing vSphere environment into a new VCF management domain. A third path, side-by-side rebuild and workload migration, remains the safer answer when the existing estate cannot meet those architectural conditions cleanly. A fourth path also matters: remain on supported vSphere or VMware vSphere Foundation until the operating model and business case justify VCF.
This article focuses on the consequences hidden behind the workflow names. It treats import and convergence as architecture decisions, not wizard selections.
TL;DR
The safest method depends on the boundary you are willing to adopt and the amount of change you are willing to make in place.
Import into an existing VCF 9.1 instance when the current vCenter and all of its clusters form a clean VI workload-domain boundary, the environment passes current VCF 9.1 prechecks, NSX can be introduced or adopted safely, and the organization accepts VCF lifecycle ownership.
Converge into a new VCF management domain when no VCF instance exists and the current vCenter, hosts, storage, and management cluster are suitable to become the foundation of the new VCF instance.
Rebuild side-by-side and migrate workloads when rollback isolation is critical, the vCenter boundary is wrong, hardware or lifecycle state is incompatible, storage support is uncertain, NSX introduction is too disruptive, or the estate contains technical debt that should not be imported into the new platform.
Remain on supported vSphere or VMware vSphere Foundation when the organization does not yet need the VCF operating model, cannot fund the management and networking footprint, or cannot meet support prerequisites without disproportionate risk.
A successful import does not relocate workloads, redesign networks, normalize storage, correct management-component placement, or create a simple undo button. It changes who owns the environment and how future changes must be performed.
Import Is a Control-Plane Adoption Event
The most important mental model is that import and convergence primarily change the management and lifecycle control plane. They are not workload-migration mechanisms.
An imported vCenter becomes the control plane for a VI workload domain inside an existing VCF instance. Broadcom’s current workflow uses VCF Operations to collect vCenter details, validate prerequisites, establish trust, collect NSX information, run final validation, and add the domain to the VCF organization. If NSX is not already connected, the workflow requires information for a new NSX management cluster and deploys it as part of the process.
A convergence workflow has a different destination. The VCF Installer uses an existing vCenter, ESX hosts, and optionally existing vSAN and NSX components to instantiate a new VCF management domain. Missing components, including SDDC Manager services and NSX, are deployed during the transformation.
The distinction matters because the target domain type determines future lifecycle, failure-domain, identity, capacity, and support boundaries.
OptionTarget VCF constructWhat it reusesWhat it changesBest fitPrimary rollback characteristicImportVI workload domain in an existing VCF instanceExisting vCenter, clusters, hosts, storage, and optionally NSXAdds VCF inventory, lifecycle ownership, trust, validation, and NSX when absentExisting VCF fleet with a clean vCenter-to-domain boundaryRemoval is not equivalent to reversing every changeConvergeNew VCF management domainExisting vCenter, management cluster, hosts, storage, and optionally NSXEstablishes the management domain and deploys missing VCF componentsNo existing VCF instance and current estate is suitable to become the platform foundationRecovery affects the new management plane itselfSide-by-side rebuildNew VCF instance or workload domainWorkloads and selected configurations, not the old control planeCreates a clean target and migrates applications in wavesHigh technical debt, strict rollback, wrong boundaries, or uncertain supportSource remains available until each wave is acceptedRemain on vSphere or VVFExisting supported platformCurrent environment and operating modelLimits transformation to supported upgrades and remediationVCF value does not yet justify platform changeNo VCF transformation rollback is required
The safest choice is the one that creates the fewest unsupported or ambiguous states after the wizard completes, not the one with the fewest screens during deployment.
The Current vCenter Boundary Becomes an Architectural Boundary
Broadcom’s VCF 9 adoption guidance makes one constraint especially important: the workflow operates at the vCenter boundary. Import brings the vCenter and all clusters managed by it into one VI workload domain. Convergence uses the vCenter and all of its clusters as one management workload domain.
That means brownfield discovery must answer a question that many environments have never needed to answer:
Does this vCenter already represent a boundary that should be governed, upgraded, recovered, and changed as one VCF domain?
A vCenter that spans unrelated business units, incompatible maintenance windows, multiple regulatory zones, distant sites, different storage teams, or clusters with materially different lifecycle policies may be operationally convenient today but architecturally wrong as one VCF domain.
The diagram below shows what import changes and what it does not.
If the answer is that the current vCenter is too broad, too fragmented, or too inconsistent to become one domain, fix the boundary before import or choose side-by-side migration. Do not use the VCF workflow as a substitute for inventory architecture.
Brownfield Discovery Must Go Beyond a Version Report
A normal vSphere assessment often starts with versions, capacity, and hardware compatibility. A VCF 9.1 brownfield assessment must go further because the target platform assumes stronger consistency across lifecycle, networking, identity, and management services.
vCenter topology and inventory shape
Capture the following before selecting a path:
Every vCenter instance, SSO domain, site, and Enhanced Linked Mode relationship.
Every datacenter, cluster, cluster folder, network folder, datastore folder, and resource pool.
Which clusters are direct children of the datacenter and which are nested in folders.
Duplicate network, port-group, datastore, cluster, and folder names.
The location of the vCenter Server Appliance VM and its datastore, network, compute cluster, backup target, and recovery dependencies.
Any vCenter High Availability configuration and residual VCHA network adapters.
Custom SSO domain names, identity sources, group mappings, service accounts, local accounts, and certificate dependencies.
Plugins and extensions, including storage, backup, monitoring, replication, hardware, security, and automation integrations.
Cross-vCenter workflows, content libraries, tags, custom attributes, alarms, scheduled tasks, permissions, and external automation.
VCF 9.1 has specific brownfield behaviors that make these details operationally important. Current Broadcom knowledge-base articles document failures when target clusters are nested below the datacenter object, when network object names are duplicated, when custom SSO credentials are not supplied correctly, and when a VCHA adapter remains attached to the imported vCenter VM.
ESX host and cluster lifecycle state
For every cluster, record:
ESX version and build.
Server model, CPU generation, BIOS, firmware, storage controller, network adapter, GPU, and other PCI devices.
VMware Compatibility Guide status for the exact target release and device combination.
vSphere Lifecycle Manager baseline versus image-based management.
OEM add-ons, vendor images, firmware packages, component overrides, third-party VIBs, acceptance levels, and custom drivers.
Cluster services such as DRS, HA, vSAN, Supervisor, fault domains, stretched-cluster configuration, encryption, key management, and host profiles or vSphere Configuration Profiles.
Maintenance-mode capacity, evacuation time, and whether the cluster can survive one or more hosts being unavailable during remediation.
Unsupported or exceptional host networking such as standard switches, single-pNIC designs, LACP dependencies, custom VMkernel routing, or inconsistent uplink mappings.
VCF 9 uses image-based lifecycle management rather than legacy baselines. An existing cluster that cannot be represented by a validated image, including the correct OEM add-on, firmware integration, storage driver, and network driver, is not ready for VCF lifecycle ownership.
Existing network and NSX state
Inventory the current network as a dependency graph, not a list of port groups:
Every vSphere Distributed Switch and any remaining vSphere Standard Switch.
Physical NIC assignments, uplink policies, LACP groups, MTU, VLAN trunks, Network I/O Control, and failover order.
Management, vMotion, vSAN, provisioning, replication, backup, witness, storage, and application VMkernel adapters.
VMkernel IP stacks, gateways, static routes, and nondefault routing.
Distributed port groups, VLAN IDs, binding types, security settings, teaming policies, and connected workloads.
Duplicate network-object names, including duplicates between standard and distributed port groups.
Existing NSX Manager clusters, versions, compute-manager registration, transport zones, transport-node profiles, TEPs, edges, Tier-0 and Tier-1 gateways, distributed firewall policy, and load-balancing dependencies.
Whether NSX is shared across vCenters or domains.
Whether workloads currently depend on only VLAN-backed networks or already consume overlays and NSX services.
An environment without NSX is not disqualified from VCF 9.1 import or convergence. It is, however, accepting NSX as a new management dependency. That requires capacity, IP addresses, DNS, certificates, lifecycle planning, backup, and operational ownership even when the first design remains VLAN-backed.
Storage and data-services state
For every cluster and workload, identify:
Principal and supplemental datastores.
vSAN architecture, disk groups or Express Storage Architecture, storage policies, fault domains, encryption, data-at-rest keys, capacity reserve, resynchronization state, and HCL health.
VMFS over Fibre Channel or iSCSI, including zoning, LUN masking, multipathing, path policy, queue depth, host bus adapter firmware, and driver versions.
NFS protocol version, export options, network path, routing, authentication, multipathing behavior, and vendor support.
vVols arrays, Protocol Endpoints, VASA Provider versions, certificate state, storage containers, replication groups, backup integration, and array-plugin compatibility.
NVMe over Fabrics, FCoE, or other external storage configurations.
Storage replication, disaster recovery, snapshot, backup, and ransomware-recovery dependencies.
Datastore names, identifiers, mount consistency, and any application licensing or clustering tied to storage identity.
VCF 9 supports a wider set of principal-storage designs than many earlier VCF generations, including supported external-storage patterns introduced through convergence or import. That flexibility does not remove the need to validate the complete lifecycle chain. A datastore being visible to ESX is not the same as the storage architecture being sustainable under VCF image management, host expansion, upgrades, recovery, and vendor support.
Management and external service dependencies
Document every service that must remain healthy during and after transformation:
Forward and reverse DNS.
NTP and time hierarchy.
PKI, certificate authority, certificate templates, revocation access, and trust chains.
Identity providers, Active Directory, federation, multifactor authentication, and privileged-access workflows.
Software depot, proxy, firewall, offline-bundle, and binary-management paths.
SFTP or other backup repositories.
Monitoring, logging, SIEM, service management, CMDB, configuration management, automation, secrets management, and ticketing integrations.
Backup and recovery products for vCenter, NSX, management appliances, hosts, and workloads.
Support contracts, hardware-vendor support, storage-vendor support, and named escalation paths.
The brownfield environment is ready only when these dependencies can support the target VCF model, not merely the current vSphere model.
Import, Convergence, Rebuild, and Remaining on vSphere
The four choices solve different problems. Treating them as interchangeable creates unnecessary risk.
Import into an existing VCF 9.1 instance
Use import when an existing VCF fleet and VCF instance already provide the management domain, VCF Operations, VCF Management Services, lifecycle services, licensing, and operating model.
The imported vCenter becomes a VI workload domain. All clusters under that vCenter come with it. The environment can already have NSX, or the workflow can deploy a new NSX management cluster when NSX is absent.
Import is usually the best fit when:
The current vCenter maps cleanly to one VCF domain.
Existing VCF fleet services are healthy, sized, backed up, and operationally accepted.
The imported domain can use the existing fleet’s lifecycle, identity, certificate, logging, monitoring, and governance processes.
Hardware and host images can be brought into compliance.
Existing storage is supported and its Day-2 operating model is understood.
The organization has decided how NSX will be introduced or adopted.
Management-appliance placement has been designed rather than left to workflow defaults.
There is a support-led removal and recovery plan if the workflow fails after making changes.
Import is a poor fit when the vCenter contains clusters that should have different domain ownership, maintenance windows, or lifecycle cadence. It is also a poor fit when the organization is using import to avoid fixing unsupported host, network, identity, or storage conditions.
Converge into a new VCF management domain
Use convergence when no VCF instance exists and the organization wants to reuse an existing vCenter and cluster as the management foundation of a new VCF instance.
This path is attractive because it can preserve existing investments while introducing VCF management. It is also more demanding because the converted environment becomes the platform’s management domain. The current cluster must have enough capacity, availability, lifecycle consistency, and recovery capability to host the management plane on which all later domains depend.
Convergence is usually the best fit when:
The selected vCenter and all clusters beneath it are intentionally part of one management-domain boundary.
The management cluster meets current VCF 9.1 support and capacity requirements.
The organization accepts that the existing environment will become the foundational failure domain for the VCF instance.
Missing components such as NSX and VCF management services can be deployed with sufficient compute, memory, storage, IP addresses, DNS, and certificates.
Existing workloads on the future management cluster can be relocated, isolated, or governed appropriately.
The environment can deactivate unsupported constructs such as Enhanced Linked Mode and VCHA before convergence.
The team can recover the new management domain, not just individual virtual machines.
Convergence is a poor fit when the existing management cluster is already capacity constrained, contains a large and volatile business-workload population, depends on fragile external services, or cannot be maintained without putting the future VCF control plane at risk.
Rebuild side-by-side and migrate workloads
Side-by-side rebuild is often dismissed as the expensive option. In a heavily customized environment, it can be the lowest-risk option because it separates platform construction from workload cutover.
Use side-by-side when:
The current vCenter boundary is wrong for VCF domains.
Hardware generations, firmware, or drivers cannot align to the target bill of materials.
Legacy baselines, custom VIBs, or third-party claim rules make in-place lifecycle conversion risky.
Existing networking cannot safely accept NSX host preparation or transport-node changes.
vVols, storage plugins, array dependencies, or replication designs lack a clearly supported future lifecycle.
Enhanced Linked Mode, VCHA, certificate debt, DNS debt, or naming collisions require broad remediation.
The organization needs a clean rollback in which the original platform remains operational.
The management domain should be physically or operationally separated from the current workload estate.
Existing technical debt should not be carried into the VCF lifecycle model.
The cost is additional temporary capacity, application migration, duplicated operations, and a longer coexistence period. The benefit is a much stronger rollback boundary and a target that can be validated before production workloads depend on it.
Remain on supported vSphere or VMware vSphere Foundation
VCF should not be the answer solely because an import workflow exists.
Remain on a supported vSphere or VMware vSphere Foundation path when the organization primarily needs virtualization rather than the broader VCF private-cloud operating model, or when VCF prerequisites would force a disproportionate redesign. This can be a deliberate architecture decision, not a failed migration.
The organization should reconsider when it needs fleet-level lifecycle, integrated NSX, common management services, automation, centralized licensing, or domain-based governance at a scale that justifies the additional management and operational footprint.
NSX Is the Largest Hidden Consequence
For a brownfield vSphere environment without NSX, the word “import” hides a major platform addition.
Broadcom’s import workflow explicitly asks whether the external vCenter is connected to NSX. If it is not, the workflow collects NSX management-cluster details and deploys a new NSX instance. Broadcom also states that NSX 9.x is supported as part of VCF 9.x, not as a new standalone deployment model. The operational result is that the environment now owns an NSX control plane even if the existing application networks remain VLAN-backed.
Existing distributed port groups do not automatically become overlays
A brownfield adoption does not inherently require every existing distributed port group to be replaced with an NSX overlay segment. Broadcom’s 9.1 support guidance confirms that brownfield management components can remain on validated NSX VLAN-backed segments even though greenfield designs commonly recommend overlays.
That does not mean the network is unchanged.
Depending on the selected workflow and design, NSX introduction can add:
NSX Manager appliances and their management network.
Compute-manager registration to vCenter.
Host preparation and lifecycle-managed NSX components.
Transport-node profiles.
TEP VMkernel adapters and TEP IP pools.
Transport zones.
vSphere Configuration Profile changes.
New MTU requirements and physical-fabric validation.
New certificate, backup, monitoring, logging, and upgrade dependencies.
New operational separation between VLAN-backed connectivity and overlay-based services.
The safe statement is not “NSX will not affect the network.” The safe statement is that existing VLAN-backed workload connectivity can remain in place in supported brownfield designs, while the exact NSX deployment, host-preparation, TEP, and overlay choices must be validated for VCF 9.1.
Preserve existing vDS design deliberately
Before transformation, export the configuration of every vSphere Distributed Switch and document:
Switch and port-group names.
Uplink-to-pNIC mapping.
VLAN trunks and native VLAN assumptions.
MTU end to end.
Network I/O Control shares and limits.
LACP mode and physical-switch configuration.
Security and traffic-shaping policies.
VMkernel adapters and IP stacks.
Application and management dependencies on each port group.
VCF 9 relies on vSphere Distributed Switch capabilities. Environments still using vSphere Standard Switches must design and validate the transition before convergence. Do not combine a standard-to-distributed switch migration, NSX introduction, host-image transition, and VCF convergence into one uncontrolled change window.
Validate the actual NSX data plane
A successful workflow task is not enough. Post-transformation validation must confirm:
NSX Manager cluster health and quorum.
Compute-manager connectivity.
Transport-node status for every intended host.
Expected TEP VMkernel adapters and IP assignments.
TEP-to-TEP reachability at the required MTU.
VLAN-backed workload connectivity.
Overlay connectivity if overlays are enabled.
Distributed firewall policy behavior.
Edge and north-south services if deployed.
Backup configuration and a recoverable NSX file-based backup.
Monitoring, logging, certificates, and password-management integration.
Broadcom has documented brownfield cases in which import and NSX configuration complete without the expected TEP VMkernel ports. That is a reminder to validate the realized data plane, not only the orchestration status.
Management-Component Placement Must Be Designed Before Import
Import should not be assumed to relocate the vCenter Server Appliance or place every new management appliance in an ideal failure domain.
Broadcom community lab reports show the vCenter VM remaining on its original cluster after import, with newly deployed NSX Manager appliances placed where that vCenter is hosted. The reported behavior was reproduced by the original poster, but it should still be treated as observed behavior to validate in a VCF 9.1 lab rather than a substitute for official placement design.
The architectural issue is more important than the individual report. Before starting the workflow, decide:
Where the imported vCenter VM should run during the transformation.
Where it should run after the domain is accepted.
Where new NSX Manager nodes will be deployed.
Which datastore and network will host them.
Whether the cluster has enough reserved capacity for management appliances during a host failure or maintenance event.
Whether management appliances are protected from workload resource contention.
Whether vCenter and NSX recovery depend on the same storage, network, DNS, or identity service they are expected to manage.
Whether moving the vCenter before or after import creates a safer placement sequence.
A common anti-pattern is to import a workload-heavy cluster, allow the control-plane appliances to land there, and plan to “move them later.” That creates a period in which the new domain’s management plane depends on the most contested part of the old environment.
For convergence, the issue is even more direct. The reused cluster becomes the management domain. If it cannot provide predictable capacity and a clean recovery boundary for the VCF control plane, it is not a suitable convergence target.
Storage Support Is Not the Same as Storage Simplicity
VCF 9 supports multiple principal-storage patterns, including vSAN, Fibre Channel, NFS, and additional external-storage types introduced through brownfield convergence or import workflows. The design question is not just whether the datastore type is supported. It is how that storage will be commissioned, expanded, patched, recovered, and changed after VCF adopts the domain.
Storage patternBrownfield opportunityHidden dependencySafer design posturevSANStrong integration with VCF lifecycle and domain designHCL, firmware, controller, network, capacity reserve, resynchronization, encryptionImport or converge when health and lifecycle are cleanVMFS on Fibre ChannelCan be used as principal storage in supported designsZoning, HBA firmware, multipathing, array support, vLCM image contentsValidate host image and array interoperability before adoptionVMFS on iSCSISupported through brownfield patterns when preconfiguredVMkernel routing, CHAP, multipathing, network isolation, driver and firmwareTest host remediation and storage path recovery in the pilotNFSSupported principal-storage options depend on protocol and workflowExport policy, protocol version, routing, MTU, multipathing behavior, vendor lifecycleConfirm the exact 9.1 storage model and vendor supportvVolsPreserves policy-driven array integrationVASA Provider lifecycle, certificates, Protocol Endpoints, replication, backup, future primary-storage changeRequire written support confirmation and a tested exit pathOther external storageBrownfield workflows can enable additional principal-storage typesSome Day-2 operations may begin in vCenter and require VCF inventory synchronizationDocument the split operating model and automation impact
vSAN
vSAN is usually the most straightforward storage choice when the hardware, disk layout, controller firmware, drivers, network, and storage policies are already compatible with the target VCF 9.1 lifecycle. It is not automatically ready because the cluster is healthy today. Validate the exact target image, firmware integration, disk-group or ESA design, free-capacity policy, failure-domain layout, encryption, key management, and recovery process.
VMFS, NFS, and external arrays
Broadcom documents a VCF 9 brownfield method for using preconfigured external datastores as principal storage. The existing datastore is configured on the vSphere cluster first, then the environment is converged or imported. This can be a practical path for Fibre Channel, iSCSI, NFS v4.1, FCoE, and NVMe over Fabrics designs that are not exposed in every greenfield workflow.
The operational caveat is significant. For some non-lifecycle-managed cluster or host operations, administrators may need to perform the infrastructure change in vCenter first and then synchronize inventory in VCF Operations. If this sequence is not followed, later lifecycle operations can be blocked.
That is not a reason to reject external storage. It is a reason to write the Day-2 runbook before adopting it.
vVols
vVols require special caution because the lifecycle boundary extends beyond VMware components. The exact array release, VASA Provider version, certificates, Protocol Endpoint behavior, storage policy mapping, replication integration, backup product, and future vSphere or VCF target must all remain compatible.
A Broadcom community discussion raised concerns about the future upgrade path for environments using vVols as primary storage and the difficulty of changing primary storage without building a new domain and migrating workloads. That discussion is a useful risk signal, but the community statement should not be converted into an authoritative deprecation claim without current Broadcom and array-vendor documentation.
The safe approach is to require written validation for the exact VCF 9.1, vCenter, ESX, array, VASA Provider, replication, and backup combination. If the future lifecycle or exit path remains ambiguous, side-by-side migration is safer than importing the ambiguity into VCF.
VCF Installer and Management-Platform Prerequisites
Brownfield transformation fails most often in the dependencies that teams assume are already “good enough.” VCF 9.1 is less forgiving because it has to trust, inventory, deploy, and lifecycle-manage components across a larger control plane.
VCF Installer placement and reachability
The VCF Installer appliance must be deployed on a network that can reach the ESX hosts and the virtual-machine management network used for deployment. For convergence, it also needs reliable access to the existing vCenter and every required external service.
Validate before the change window:
IP routing and firewall policy from the VCF Installer to vCenter, ESX hosts, DNS, NTP, depot or proxy, certificate services, and management networks.
Forward and reverse DNS for every component.
Stable NTP from all appliances and hosts.
Adequate storage and compute for temporary deployment artifacts and new management appliances.
Access to the required VCF 9.1 binaries.
Credentials, privileges, thumbprints, and certificate trust.
Log collection and support-bundle storage.
VCF Operations, SDDC Manager services, and VCF Management Services
For import, an existing VCF 9.1 instance must already have healthy fleet and instance management. Do not add a brownfield domain to an unhealthy control plane.
Broadcom’s current 9.1 upgrade guidance describes VCF Management Services as mandatory for VCF and identifies a baseline requirement of at least 12 IP addresses, with additional capacity needed for some extension scenarios. The exact design must be checked against the current 9.1 planning documentation, but the architectural message is clear: management services are a real infrastructure footprint, not a licensing abstraction.
Confirm:
VCF Operations health and capacity.
SDDC Manager inventory and workflow health for the target VCF instance.
VCF Management Services runtime health, addressing, DNS, certificates, and backup.
License service and entitlement readiness.
Binary-management and depot status.
Monitoring and log-management readiness.
Administrative RBAC and break-glass access.
Backup completion for the existing VCF management plane before adding a domain.
Binary management and proxy readiness
VCF 9.1 validation can fail when the required NSX install image is not present in the local repository. The workflow verifies the exact binary required for the target operation.
Download and validate all required binaries before the maintenance window. In restricted environments, test the proxy or offline-depot workflow end to end, including certificates, allow lists, metadata retrieval, image download, checksum validation, and available disk space.
DNS, naming, NTP, certificates, and PKI
Treat naming and trust as implementation dependencies:
Use lowercase FQDNs for VCF components.
Create forward and reverse records before deployment.
Ensure every component resolves consistently from the VCF Installer, VCF Operations, SDDC Manager, vCenter, ESX hosts, and management networks.
Remove duplicate network-object names that could resolve an inventory path to more than one object.
Verify time synchronization and acceptable skew.
Validate certificate subject alternative names, chain trust, revocation access, and private-key ownership.
Confirm that custom SSO domains and privileged accounts are supplied correctly.
Document certificate-renewal ownership after VCF adoption.
Broadcom has documented a VCF 9.1 import failure caused by uppercase letters in NSX FQDNs. This is the kind of issue that appears cosmetic in a spreadsheet and becomes a hard workflow failure in production.
Identity and existing federation
Enhanced Linked Mode must be deactivated before import or convergence to VCF 9. VCF Operations assumes the cross-domain visibility and fleet-management role that ELM previously provided.
Identity discovery should include:
Current SSO domains and replication state.
Identity sources and group mappings.
Custom roles and permissions.
Service accounts and credential vaulting.
Federation and multifactor authentication.
Automation credentials and certificate-based integrations.
Emergency local accounts.
Audit-log and access-review requirements.
Do not remove ELM without first documenting how administrators, automation, and support teams will navigate and authenticate across the future VCF fleet and domains.
VCHA, inventory folders, and object naming
VCF 9.1-specific preflight includes several practical checks:
Remove unsupported vCenter High Availability configuration and residual VCHA adapters before convergence.
Move target clusters to the datacenter root when affected by the current nonrecursive cluster-discovery limitation.
Ensure the management network selected for VCF Services Runtime has a unique name in the vCenter datacenter inventory.
Validate that the correct custom SSO administrator account is used.
Confirm the network gateway is explicitly defined for required VMkernel adapters.
These are not reasons to avoid VCF. They are reasons to run discovery against the actual 9.1 workflow and known-issues set rather than a generic vSphere checklist.
Firewall and SSH requirements
Broadcom documents that the brownfield import validation process requires SSH access to the vCenter Server Appliance and connectivity on ports 22 and 443 between the VCF management plane and vCenter. A firewall rule or disabled SSH service can present as a timeout in VCF Operations.
Enable only the access required for the documented workflow, validate it from the actual source appliances, record the temporary or permanent rule ownership, and return services to the approved security state after the workflow when Broadcom documentation permits.
In-Place Transformation Versus Side-by-Side Migration
The central risk decision is whether to change the production control plane in place or build a new control plane beside it.
Decision areaIn-place import or convergenceSide-by-side rebuild and migrationCapital and temporary capacityLower initial duplicationRequires target capacity before migrationWorkload movementLimited for the platform-adoption eventRequired for each application waveControl-plane riskExisting production management plane is changedNew control plane is validated separatelyRollbackBecomes more complex as VCF and NSX changes accumulateSource remains the rollback platform until acceptanceTechnical debtOften carried forward unless remediated firstCan be excluded from the target by designDomain boundariesConstrained by existing vCenter layoutCan be redesigned cleanlyStorage transitionExisting datastore can be retainedNew storage can be introduced deliberatelyNetwork transitionMust coexist with existing vDS and workloadsNew network can be built and tested before cutoverMaintenance windowsPlatform and prerequisite windows affect the sourceMigration windows are workload based after target validationOperational coexistenceShorter if transformation succeedsLonger dual-platform operating periodRecovery confidenceDepends on multi-component rollback designStronger because source remains intact
In-place transformation is not automatically reckless. It can be the right answer for a clean, well-governed estate. Side-by-side is not automatically wasteful. It can be cheaper than recovering from an in-place failure that leaves vCenter, NSX, lifecycle inventory, and storage operations in an ambiguous state.
Use a risk-adjusted comparison that includes temporary hardware, migration effort, dual operations, rollback probability, outage cost, and technical-debt removal. Do not compare only the number of hosts purchased.
Application Migration and Maintenance Windows
Broadcom’s VCF 9 adoption guidance states that import and convergence generally require minimal downtime for running virtual machines because the workflows mainly deploy and configure management components. That statement must be interpreted carefully.
The complete program can still require significant maintenance activity for:
vCenter upgrades.
ESX upgrades and host-image conversion.
Transition from vSphere Lifecycle Manager baselines to images.
Firmware and driver remediation.
ELM deactivation.
VCHA removal.
vSphere Standard Switch to vSphere Distributed Switch migration.
NSX host preparation and TEP deployment.
MTU and physical-fabric changes.
Storage driver, multipathing, VASA Provider, or array-plugin changes.
Certificate replacement and trust remediation.
Management-appliance relocation.
Backup, monitoring, logging, and automation integration.
Plan the program as separate maintenance domains:
Foundation remediation window: versions, hardware, images, DNS, PKI, identity, and inventory cleanup.
Network preparation window: vDS, MTU, uplinks, VLANs, NSX addressing, and host preparation.
VCF adoption window: import or convergence workflow and management-component deployment.
Management relocation window: move vCenter or NSX appliances if the validated placement design requires it.
Application migration windows: required for side-by-side transformation or for moving workloads away from the future management cluster.
Operational acceptance window: backups, lifecycle tests, certificate tests, monitoring, alerting, support, and recovery validation.
For stateful applications, validate more than VM power state. Confirm database consistency, application clustering, storage paths, backup agents, replication, licensing, time, DNS, load balancers, firewall policy, latency, and monitoring identity.
Rollback Is a Series of Boundaries, Not One Button
The cleanest rollback point is before the environment is changed. After that, rollback becomes progressively more complicated.
Broadcom publishes a procedure for removing an imported domain in specific VCF 9 scenarios. That procedure includes conditional NSX handling, SDDC Manager inventory cleanup, and vCenter managed-object cleanup. The existence of such a procedure is important evidence: removal is a controlled decommissioning or support workflow, not proof that import is transactionally reversible.
A production rollback plan should define:
The last point at which the workflow can be stopped without cleanup.
Which components are created or modified at every stage.
Whether NSX is dedicated to the imported domain or shared.
How host preparation would be removed if required.
How vCenter and domain inventory would be reconciled.
Which Broadcom support case and escalation path will be active during the change.
Which backups are restorable and how long restoration takes.
How application owners will decide to continue, pause, or reverse a migration wave.
What happens if the control plane is healthy but the operational model is not accepted.
Never define rollback as “take a snapshot of the vCenter.” A vCenter snapshot does not reverse changes in NSX, ESX host state, VCF inventory, certificates, storage systems, external automation, or application dependencies.
Backup and Recovery Before Transformation
A brownfield VCF program should not begin until the team can recover both the source environment and the target management plane.
At minimum, complete and validate:
File-based backup of every vCenter involved.
Export of every vSphere Distributed Switch configuration.
NSX Manager backup when NSX already exists.
SDDC Manager and VCF management-plane backups for the existing VCF instance.
Configuration backup for storage arrays, VASA Providers, SAN zoning, network switches, load balancers, firewalls, DNS, NTP, PKI, and identity services.
Application-consistent workload backups for critical systems.
Recovery documentation for vCenter, NSX, SDDC Manager services, and management-domain dependencies.
Credentials and certificates required during restoration.
A tested SFTP or other repository with independent retention and access controls.
A support bundle and inventory snapshot before the change.
An offline copy of the approved component versions, images, drivers, and firmware metadata.
A backup is not validated because a scheduled job is green. Run a recovery exercise that proves the team can locate the backup, authenticate to the repository, deploy a replacement appliance, restore configuration, recover trust, and validate dependent services.
For side-by-side migration, the original environment remains part of the recovery design until the new VCF domain and every migrated application have passed acceptance. Do not decommission source storage, networking, licenses, backups, DNS, or monitoring immediately after the last VM moves.
Decision Tree for the Safest Path
Use this decision tree after discovery, not before it.
The decision tree is deliberately conservative. It assumes that uncertainty about supportability, rollback, or future lifecycle is a reason to pause or isolate the transformation rather than force an in-place workflow.
Phased Implementation and Validation Plan
A safe VCF 9.1 brownfield program is a sequence of evidence gates. Each phase should have explicit entry criteria, exit criteria, and a rollback point.
Establish the architecture decision
Objective: Decide whether the target is an imported VI workload domain, a converged management domain, a side-by-side VCF build, or continued vSphere operation.
Key activities:
Define business outcomes and the VCF capabilities required.
Identify the intended fleet, instance, domain, site, and identity boundaries.
Classify the current vCenter boundary.
Compare in-place and side-by-side risk.
Define recovery, support, staffing, licensing, and temporary-capacity assumptions.
Record an architecture decision with conditions that would change it.
Exit criteria: The target domain model and transformation method are approved by virtualization, network, storage, security, identity, backup, application, and operations owners.
Rollback point: No environment change has occurred.
Build the authoritative brownfield inventory
Objective: Produce a versioned evidence pack for every component and dependency.
Key activities:
Export vCenter, cluster, host, VM, network, datastore, tag, permission, certificate, and plugin inventory.
Map all clusters under each vCenter.
Record ELM, VCHA, SSO, identity, and certificate state.
Record vDS, standard switch, VMkernel, uplink, VLAN, MTU, and NSX state.
Record storage protocols, array and VASA versions, drivers, firmware, multipathing, and replication.
Validate hardware compatibility and target image composition.
Identify duplicate names, nested clusters, stale objects, unsupported extensions, and custom VIBs.
Exit criteria: No material component or dependency is represented as “unknown.”
Rollback point: Discovery changes are read-only.
Remediate prerequisites outside the VCF workflow
Objective: Remove conditions known to make import or convergence fail or create an unsupportable target.
Key activities:
Upgrade components through supported sequences.
Convert lifecycle baselines to validated images.
Align firmware, drivers, and OEM add-ons.
Deactivate ELM using the documented procedure.
Remove VCHA and residual adapters when converging.
Migrate from standard switches to vDS where required.
Fix DNS, reverse lookup, lowercase FQDNs, NTP, PKI, and certificate trust.
Make network-object names unique.
Move target clusters to the datacenter root when required by the current 9.1 limitation.
Validate vCenter SSH and HTTPS reachability from the VCF management plane.
Download all required binaries.
Create and test backups.
Exit criteria: Current VCF 9.1 prechecks and known-issue checks pass in the representative environment.
Rollback point: Each remediation item has its own documented reversal or recovery procedure.
Validate in a lab that resembles production
Objective: Prove the workflow against the conditions most likely to fail in production.
The lab should reproduce more than versions. Reproduce the production characteristics that create risk:
Custom SSO domain.
Lowercase and reverse DNS.
Existing vDS and VLAN-backed port groups.
Representative uplink and MTU design.
NSX-absent and NSX-present paths as applicable.
External storage and storage plugins.
vVols and VASA Provider integration when relevant.
Duplicate-name cleanup.
Cluster folder placement.
Proxy or offline depot.
Certificate authority and trust chain.
Backup and restore repositories.
Representative third-party VIBs and host-image composition.
Test workflow failure as well as success. Intentionally block a dependency, remove a binary, break DNS, or fail a validation in the lab so the team learns where logs, tasks, and support data are located.
Exit criteria: The team can complete the workflow, explain every infrastructure change, recover from a controlled failure, and execute post-transformation validation.
Rollback point: Lab environment can be rebuilt.
Run a production pilot
Objective: Validate the operating model with a low-risk but representative domain.
Choose a pilot that is operationally meaningful. An empty cluster proves deployment but not adoption. The pilot should include:
Realistic host hardware and image management.
Representative VLAN-backed networking and, if planned, overlays.
Representative storage and backup.
At least one noncritical application with a known owner and test plan.
Monitoring, logging, ticketing, identity, certificate, licensing, and lifecycle integration.
A planned maintenance event after import to prove Day-2 workflows.
A recovery exercise for at least one management component.
Exit criteria: The domain is not merely visible. It has passed lifecycle, networking, storage, backup, monitoring, certificate, identity, support, and application acceptance.
Rollback point: Pilot-specific, documented with Broadcom support involvement where removal or NSX cleanup could be required.
Transform production in controlled waves
Objective: Apply the validated pattern without turning the program into one large change.
Group environments by:
vCenter boundary.
Hardware generation.
Host-image pattern.
Storage type.
NSX state.
Site and network design.
Application criticality.
Maintenance window.
Recovery tier.
Do not put the most complex vVols, stretched, GPU, Supervisor, or third-party-integrated cluster in the first wave. Prove the standard pattern first, then handle exceptions as separate architecture decisions.
Exit criteria: Each wave passes the same acceptance checklist, with no deferred critical findings.
Rollback point: Defined per wave, application, domain, and transformation stage.
Stabilize and transfer to operations
Objective: Make the imported or converged domain an operationally accepted VCF service.
Validate:
VCF Operations inventory and health.
Domain, cluster, host, vCenter, and NSX lifecycle visibility.
Binary-management and depot workflows.
Certificate and password-management workflows.
Backup schedules and recovery documentation.
vDS and NSX realized state.
Storage health and vendor integrations.
Monitoring, logging, alert routing, and support bundles.
Licensing and core allocation.
RBAC, privileged access, and audit evidence.
Capacity and maintenance reserves.
Change, incident, problem, and escalation runbooks.
Application-owner signoff.
Exit criteria: Platform operations formally accepts the domain, application owners accept the workloads, and the original rollback environment is retained until the agreed stabilization period ends.
Preflight Checklist
Use this as a decision gate before opening the production change.
Architecture and boundary
The VCF fleet, instance, management-domain, and workload-domain model is documented.
The selected vCenter and all clusters beneath it belong in one target domain.
Site, regulatory, business-unit, and maintenance-window boundaries are compatible.
Import, convergence, side-by-side, or remain-on-vSphere decision is approved.
Conditions that force a switch to side-by-side are documented.
Versions, hardware, and lifecycle
Current 9.1 supported-component and convergence documentation has been checked.
vCenter, ESX, NSX, and VCF management components are on supported paths.
Every host and device is compatible with the target release.
Clusters use validated image-based lifecycle management.
OEM add-ons, firmware, storage drivers, network drivers, and custom components are included.
Maintenance capacity and evacuation time are proven.
Network and NSX
All vDS, standard switches, uplinks, VLANs, LACP, MTU, and VMkernel routes are documented.
The standard-switch-to-vDS transition is complete when required.
The NSX design states whether the environment remains VLAN-backed, adds overlays, or uses both.
NSX Manager placement, sizing, IPs, DNS, certificates, and backups are ready.
TEP pools, MTU, transport zones, and physical-fabric reachability are validated when overlays are enabled.
Distributed port-group names are unique where workflow resolution requires it.
Existing workload connectivity has a before-and-after validation plan.
Storage
Principal and supplemental storage are identified for every cluster.
Array, controller, HBA, NIC, firmware, driver, and multipathing combinations are supported.
vSAN health, capacity reserve, resynchronization, fault domains, and encryption are clean.
NFS or iSCSI routing, authentication, and failover are tested.
vVols have written array, VASA, backup, replication, and VCF lifecycle validation.
Day-2 host, cluster, and inventory synchronization procedures are documented for external storage.
Recovery and data-protection tests are complete.
Identity, naming, certificates, and services
ELM is deactivated when required.
VCHA and residual adapters are removed for convergence.
Custom SSO accounts and privileges are validated.
All component FQDNs are lowercase.
Forward and reverse DNS are correct from every management zone.
NTP is consistent.
Certificate SANs, chains, revocation access, and trust are validated.
Cluster placement and inventory names satisfy current 9.1 workflow limitations.
Required IP addresses for VCF Management Services and new appliances are reserved.
VCF management plane
VCF Installer placement and reachability are validated.
Existing VCF Operations and SDDC Manager services are healthy for import.
VCF Management Services are healthy and correctly sized.
Required binaries, including NSX, are downloaded and verified.
Proxy or offline-depot access has been tested.
Ports 22 and 443 between the management plane and vCenter are validated for the workflow.
Licensing, monitoring, logging, backup, and support access are ready.
Recovery and change control
vCenter file-based backups are complete and recoverable.
vDS configurations are exported.
NSX and existing VCF management-plane backups are complete.
Application-consistent backups are complete.
The rollback boundary is defined for each workflow stage.
Broadcom and hardware or storage vendor escalation paths are active.
Go, pause, rollback, and support-escalation decision makers are named.
The production pilot passed the same architecture pattern.
Post-Transformation Acceptance Checklist
Do not declare success when the workflow reaches 100 percent. Declare success when the platform and its workloads are operable.
VCF domain and lifecycle
The domain is visible in the correct VCF instance and organization.
All expected clusters and hosts are present exactly once.
Component versions and target images are correct.
Lifecycle prechecks complete successfully.
A non-disruptive lifecycle or compliance operation has been tested.
Binary management and depot access work.
No critical workflow task remains failed, canceled, or orphaned.
vCenter and management appliances
vCenter services, SSO, certificates, plugins, RBAC, and APIs are healthy.
vCenter and NSX Manager placement matches the approved design.
Management appliances have reserved capacity and restart priority.
Backup jobs complete to independent repositories.
Recovery documentation reflects the final topology.
Network and NSX
Existing VLAN-backed VM traffic passes application tests.
vDS uplinks, teaming, LACP, VLANs, MTU, and Network I/O Control match the baseline.
NSX Manager cluster and compute-manager connections are healthy.
Expected transport nodes, TEPs, transport zones, and segments exist.
Overlay, distributed firewall, edge, and north-south tests pass when used.
Logging, monitoring, alarms, and certificate-expiration checks are active.
Storage and data protection
Every datastore is mounted consistently across intended hosts.
Multipathing, paths, queue depth, storage policies, and VASA status are healthy.
vSAN health and resynchronization are clean.
Backup, restore, replication, and snapshot workflows pass.
Array and backup plugins operate against the post-transformation vCenter and certificate state.
Storage Day-2 procedures and VCF inventory synchronization are tested.
Applications and operations
Application owners have completed functional and performance validation.
Stateful systems pass consistency, replication, backup, and failover tests.
Monitoring, logging, CMDB, ticketing, automation, and security integrations are updated.
Capacity dashboards include the new management overhead and maintenance reserve.
Incident, change, certificate, password, lifecycle, and recovery runbooks are approved.
Operations owns the environment and the support escalation path.
The source environment remains available until the stabilization exit criteria are met.
Practical Recommendation
For most enterprises, the safest default is not a universal choice. It is a risk hierarchy.
Import is the preferred path when an existing VCF 9.1 instance is healthy and the brownfield vCenter is already a good VI workload-domain boundary. It preserves workloads and infrastructure while bringing the environment under VCF lifecycle management. It should still be treated as a platform-adoption change with NSX, placement, storage, and rollback design.
Convergence is the preferred path when no VCF instance exists and the current environment is intentionally suitable to become the management domain. The bar should be higher than for import because the reused cluster becomes the foundation for the VCF instance.
Side-by-side rebuild is the preferred risk-control path when the environment contains incompatible boundaries, lifecycle debt, uncertain storage support, fragile networking, insufficient management capacity, or stringent rollback requirements. It costs more capacity and migration effort, but it avoids turning old technical debt into VCF-managed technical debt.
Remaining on supported vSphere or VMware vSphere Foundation is the preferred governance path when VCF capabilities are not yet required or the organization cannot operate the additional control plane responsibly.
The most supportable transformation is the one that reaches a known target architecture with a documented operating model and a credible recovery path. A green import task is only one piece of that evidence.
Conclusion
Brownfield vSphere adoption into VMware Cloud Foundation 9.1 should be designed from the target operating model backward.
Import is appropriate when an existing VCF instance is ready to own the environment and the current vCenter already represents a valid VI workload-domain boundary. Convergence is appropriate when the existing vSphere estate can responsibly become the management domain of a new VCF instance. Side-by-side rebuild is safer when the source contains boundary problems, lifecycle inconsistency, storage uncertainty, fragile networking, or rollback requirements that cannot be satisfied in place. Remaining on supported vSphere or VMware vSphere Foundation is valid when the organization is not ready for the VCF management model.
The hidden consequences matter more than the wizard label. NSX introduction creates a new control plane. Existing distributed switches and VLAN-backed networks may remain, but host preparation, TEPs, MTU, certificates, and operational ownership still require design. Storage may be supported, but its lifecycle, plugin, driver, and recovery chain must also be sustainable. The vCenter VM and new NSX appliances may remain in the original failure domain unless placement is deliberately changed. Rollback becomes more complex as VCF inventory, lifecycle, NSX, and host state are modified.
Treat successful discovery as the beginning, successful validation as permission to proceed, and successful import as the midpoint. The transformation is complete only when lifecycle, networking, storage, backup, recovery, monitoring, identity, operations, and applications have all been accepted.
External References
[1] 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
[2] Broadcom TechDocs: Converging Your Existing vSphere Infrastructure to a VCF or VVF 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
[3] 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
[4] Broadcom TechDocs: Deploy VCF InstallerCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/deployment/deploying-a-new-vmware-cloud-foundation-or-vmware-vsphere-foundation-private-cloud-/preparing-your-environment/deploy-the-vmware-cloud-foundation-installer-appliance.html
[5] Broadcom TechDocs: VCF Components FQDNs and IP addressesCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/planning-and-preparation/vcf-components-fqdns-and-ip-addresses.html
[6] 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
[7] Broadcom Knowledge Base: Importing an Existing vCenter to Create a Workload Domain in VMware Cloud FoundationCanonical URL: https://knowledge.broadcom.com/external/article/441529/importing-an-existing-vcenter-to-create.html
[8] VMware Cloud Foundation Blog: How to Converge a VMware vSphere Environment to VMware Cloud Foundation 9.0Canonical URL: https://blogs.vmware.com/cloud-foundation/2026/02/05/how-to-converge-a-vmware-vsphere-environment-to-vmware-cloud-foundation-9-0/
[9] VMware Cloud Foundation Blog: Converging VMware vSphere to VMware Cloud Foundation 9.0: The Top 10 Questions AnsweredCanonical URL: https://blogs.vmware.com/cloud-foundation/2026/04/16/converging-vmware-vsphere-to-vmware-cloud-foundation-9-0-the-top-10-questions-answered/
[10] Broadcom Knowledge Base: Upgrade Sequence and Related Issues for VMware Cloud Foundation and VMware vSphere Foundation 9.1Canonical URL: https://knowledge.broadcom.com/external/article/440630/upgrade-sequence-and-related-issues-for.html
[11] Broadcom Knowledge Base: Supporting all Principal Storage Options in VMware Cloud Foundation 9Canonical URL: https://knowledge.broadcom.com/external/article/416270
[12] Broadcom Knowledge Base: NSX 9.x is only supported as part of a VCF 9.x deploymentCanonical URL: https://knowledge.broadcom.com/external/article/401775/nsx-9x-is-only-supported-as-part-of-a-vc.html
[13] Broadcom Knowledge Base: VCF 9.1 brownfield upgrade support for VCF Operations and Automation on NSX VLAN segmentsCanonical URL: https://knowledge.broadcom.com/external/article/443842/vcf-91-brownfield-upgrade-support-for-vc.html
[14] Broadcom Knowledge Base: Existing vCenter import fails to discover clusters nested in folders VCF 9.1 InstallerCanonical URL: https://knowledge.broadcom.com/external/article/445464/existing-vcenter-import-fails-to-discove.html
[15] Broadcom Knowledge Base: Import vCenter to VCF 9.1 fails if the NSX FQDN includes uppercase lettersCanonical URL: https://knowledge.broadcom.com/external/article/442909/import-vcenter-to-vcf-91-fails-if-the-ns.html
[16] Broadcom Knowledge Base: VCF-VVF 9.1 brownfield installation fails with error: An error occurred in task Bootstrap VCF Services Platform when a VCHA adapter is present on the imported vCenter VMCanonical URL: https://knowledge.broadcom.com/external/article/442355/vcfvvf-91-brownfield-installation-fails.html
[17] Broadcom Knowledge Base: VCF 9.1 deployment fails to bootstrap VCF Services Runtime when a network name resolves to multiple vCenter network objectsCanonical URL: https://knowledge.broadcom.com/external/article/448501/vcf-91-deployment-fails-to-bootstrap-vcf.html
[18] Broadcom Knowledge Base: Validation fails with NSX install image not found during vCenter import to VCF 9.1Canonical URL: https://knowledge.broadcom.com/external/article/448062/validation-fails-with-nsx-install-image.html
[19] Broadcom Knowledge Base: Brownfield Import of vCenter into VCF Operations as a Workload Domain Fails with a Validation TimeoutCanonical URL: https://knowledge.broadcom.com/external/article/419927/brownfield-import-of-vcenter-into-vcf-op.html
[20] Broadcom Knowledge Base: How to remove a Imported domain from VCF 9.0Canonical URL: https://knowledge.broadcom.com/external/article/436924/how-to-remove-a-imported-domain-from-vcf.html
[21] Broadcom TechDocs: File-Based Restore for SDDC Manager, vCenter, and NSXCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/fleet-management/backup-and-restore-of-cloud-foundation/file-based-restore-for-sddc-manager-vcenter-server-and-nsx-t-data-center.html
[22] Broadcom TechDocs: Export the Configuration of the vSphere Distributed SwitchesCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/fleet-management/backup-and-restore-of-cloud-foundation/file-based-backups-for-sddc-manager-and-vcenter-server/export-the-configuration-of-the-vsphere-distributed-switches.html
[23] Broadcom Community: Converging to VCF 9.xCanonical URL: https://community.broadcom.com/vmware-cloud-foundation/discussion/converging-to-vcf-9x
[24] Broadcom Community: What happens to the vCenter VM when it’s imported as a new VCF Workload Domain?Canonical URL: https://community.broadcom.com/vmware-cloud-foundation/discussion/what-happens-to-the-vcenter-vm-when-its-imported-as-a-new-vcf-workload-domain
[25] Broadcom Community: Upgrade path for VCF 9 with vVols as primary storageCanonical URL: https://community.broadcom.com/vmware-cloud-foundation/discussion/upgrade-path-for-vcf-9-with-vvols-as-primary-storage
[26] Broadcom Knowledge Base: Missing TEP VMkernel ports on ESXi hosts after importing vCenter environment to VCF 9 and configuring NSXCanonical URL: https://knowledge.broadcom.com/external/article/436531/missing-tep-vmkernel-ports-on-esxi-hosts.html
[27] Broadcom Knowledge Base: VCF 9.x Import Pre-check Failed to Retrieve Trusted Root Certificates Due to SSO Domain MismatchCanonical URL: https://knowledge.broadcom.com/external/article/441490/vcf-9x-import-precheck-failed-to-retriev.html
[28] Broadcom Knowledge Base: Upgrading to VCF 9.0 requires Distributed Switch as a minimum requirement/componentCanonical URL: https://knowledge.broadcom.com/external/article/430625/upgrading-to-vcf-90-requires-distributed.html
VMware Cloud Foundation 9.1 Release Notes: What Changed for Operators
VMware Cloud Foundation 9.1 became available on May 12, 2026, as build 25377994. The release covers infrastructure efficiency, Kubernetes operations, private AI,…
The post Brownfield vSphere to VMware Cloud Foundation 9.1: Import, Converge, or Rebuild? appeared first on Digital Thought Disruption.