Site icon Digital Thought Disruption

Brownfield vSphere to VMware Cloud Foundation 9.1: Import, Converge, or Rebuild?

Paul Bryant

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.

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 characteristic
ImportVI 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 change
ConvergeNew 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 itself
Side-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 accepted
Remain 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:

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:

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:

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:

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:

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:

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:

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 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:

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:

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:

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:

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 posture
vSANStrong integration with VCF lifecycle and domain designHCL, firmware, controller, network, capacity reserve, resynchronization, encryptionImport or converge when health and lifecycle are clean
VMFS 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 adoption
VMFS on iSCSISupported through brownfield patterns when preconfiguredVMkernel routing, CHAP, multipathing, network isolation, driver and firmwareTest host remediation and storage path recovery in the pilot
NFSSupported 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 support
vVolsPreserves policy-driven array integrationVASA Provider lifecycle, certificates, Protocol Endpoints, replication, backup, future primary-storage changeRequire written support confirmation and a tested exit path
Other 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:

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:

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:

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:

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:

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 migration
Capital and temporary capacityLower initial duplicationRequires target capacity before migration
Workload movementLimited for the platform-adoption eventRequired for each application wave
Control-plane riskExisting production management plane is changedNew control plane is validated separately
RollbackBecomes more complex as VCF and NSX changes accumulateSource remains the rollback platform until acceptance
Technical debtOften carried forward unless remediated firstCan be excluded from the target by design
Domain boundariesConstrained by existing vCenter layoutCan be redesigned cleanly
Storage transitionExisting datastore can be retainedNew storage can be introduced deliberately
Network transitionMust coexist with existing vDS and workloadsNew network can be built and tested before cutover
Maintenance windowsPlatform and prerequisite windows affect the sourceMigration windows are workload based after target validation
Operational coexistenceShorter if transformation succeedsLonger dual-platform operating period
Recovery 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:

Plan the program as separate maintenance domains:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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

Versions, hardware, and lifecycle

Network and NSX

Storage

Identity, naming, certificates, and services

VCF management plane

Recovery and change control

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

vCenter and management appliances

Network and NSX

Storage and data protection

Applications and operations

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

Exit mobile version