Brownfield VCF Adoption: Converting vSphere to VCF-Managed

VCF 9.0Advancedvcdx-distinguished⏱ 75 min

This lab covers brownfield adoption — migrating an existing vSphere environment to VCF management. VCF Import Tool supports 6.7+. NSX deployment is required on target clusters (can be non-disruptive if existing NSX-V is present; otherwise deployed fresh).

Objectives

Assess existing vSphere environment for VCF readiness (version, storage type, networking, licensing)
Plan VCF Import process including NSX deployment, workload domain boundaries, and IP addressing
Execute brownfield conversion design exercise using VCF Import Tool workflow and RCAR framework

Prerequisites

Access to vSphere 6.7+ environment (can be Holodeck lab with a deployed vSphere cluster, or existing production environment for assessment). VCF 9.0 instance (separate physical cluster or Holodeck VCF instance). Internet connectivity for downloading VCF Import Tool.

Prior labs: holodeck-02 or holodeck-03 (VCF 9.0 management domain for import destination), vcf-evolution-01 (architectural understanding of VCF 9.0)

Required skills:

vSphere cluster management (networking, storage, VM inventory assessment)
NSX architecture and deployment (NSX-V or NSX-T familiarity, network segmentation)
IP addressing and network planning (TEP ranges, vMotion networks, management networks)
VCF Import Tool usage (pre-flight validation, cluster import, workload domain assignment)
Risk assessment and change management (brownfield conversions are high-risk; mitigation planning critical)

Lab Environment

Two separate environments: (1) Existing vSphere cluster (brownfield source) running vSphere 6.7+, 3+ ESXi hosts, vSAN or external storage (FC, NFS, iSCSI acceptable). (2) VCF 9.0 management domain (import destination) deployed in Holodeck or production lab. Network: Brownfield cluster must be routable to VCF management domain (IP reachability, no security policy blocking HTTPS/SSH).

graph TB
  subgraph Brownfield[Existing vSphere]
    vC[vCenter 6.7-8.0]
    ESXi1B[ESXi 1]
    ESXi2B[ESXi 2]
    ESXi3B[ESXi 3]
    vC -->|mgmt| ESXi1B
    vC -->|mgmt| ESXi2B
    vC -->|mgmt| ESXi3B
  end
  subgraph VCFEnv[VCF 9.0 Management Domain]
    SDDCMgr[SDDC Manager]
    VCenterVCF[vCenter]
    NSXMgrVCF[NSX Manager]
  end
  Brownfield -->|Network Reachability| VCFEnv
  SDDCMgr -->|Import Discovery| vC
  Client[Operator with VCF Import Tool] -->|HTTPS| SDDCMgr
  Client -->|HTTPS| vC

IP Addressing

Network	Purpose	VLAN
`10.1.0.0/24`	Existing vSphere cluster management (brownfield source)	VLAN 100 (example)
`10.2.0.0/24`	Existing vSphere vMotion network (brownfield source)	VLAN 101 (example)
`10.3.0.0/24`	NSX TEP (Tunnel Endpoint) range for brownfield cluster post-import	VLAN 102 (example, new network)
`10.0.0.0/20`	VCF management domain (destination)	VLAN 1644 (example)

Credentials

System	Username	Password
Existing vCenter (Brownfield)	`administrator@vsphere.local or SSO user`	vCenter SSO credentials; used by VCF Import Tool to discover clusters
SDDC Manager (VCF 9.0)	`administrator@vcf.sddc (or Broadcom SSO)`	SDDC Manager credentials; used to execute import
Each ESXi host (Brownfield)	`root`	Root credentials; used for NSX deployment and host management during import

Tasks

Task 1 Assess Existing vSphere Environment for VCF Readiness

compatibility

Brownfield environments are messy — mixed vSphere versions, heterogeneous storage, legacy NSX-V, old vCenter, custom networking. VCDX candidates must be able to audit an environment and identify what's compatible vs. what's a blocker. This task trains you to ask the right questions: 'Can we import this cluster? What's the minimum effort? What's the maximum risk?'

Step 1

Host inventory showing all hosts meet minimum requirements: vSphere 6.7+ (ideally 7.0+), modern CPU (post-2010 Intel/AMD), compatible network adapters

Step 2

Verify vSphere version compatibility with VCF 9.0: VCF 9.0 supports vSphere 6.7 - 8.0. Document: [Cluster vCenter Version | Supported for Import? | Pre-Upgrade Required?]. If vCenter is 6.5, it must be upgraded to 6.7+ before import. If vCenter is 8.0, it's compatible.

Compatibility check: All hosts are 6.7 or higher; if lower, document pre-upgrade path (e.g., 6.5 → 6.7 → 9.0)

Step 3

Storage inventory showing capacity, available space, and vMotion support. vSAN is preferred; external arrays (FC/NFS/iSCSI) are supported but require different pre-flight checks (LUN mapping, VMFS version, etc.)

Step 4

Check storage type constraints: VCF 9.0 requires vSAN OR external shared storage. Pure local storage (no vSAN, no shared storage) is NOT supported. Document: [Host | Storage Type | Shared? | vSAN Capable?]. If any host has only local disks (RAID1 mirror for OS only), it cannot be imported as-is.

Storage compatibility assessment: All hosts have either vSAN or external shared storage; no local-storage-only hosts that would block import

Step 5

Assess existing networking: Does the cluster have NSX-V deployed? NSX-T? Plain VLAN networking? Document: [Networking Model | NSX-V Deployed? | NSX-T Deployed? | VLANs Configured | Distributed Switch (vDS)?]

Networking inventory showing current architecture (NSX-V, NSX-T, or vanilla); note any legacy configurations that will require cleanup during import

Step 6

Check for NSX-V: If NSX-V is present, document version and edge cluster configuration. NSX-V to NSX-T migration is non-disruptive (new NSX-T can coexist with NSX-V during import). Document: [NSX-V Version | Edge Cluster? | DLR Configured? | ESG Count | Current Policies]

NSX-V assessment showing configuration state; plan for coexistence with NSX-T during import or plan for NSX-V removal pre-import

Step 7

Verify networking prerequisites: Can you create new VLANs for NSX TEP traffic? Are there IP ranges available (e.g., 10.3.0.0/24)? Can NSX Manager reach all ESXi hosts (HTTPS/SSH)? Document: [Requirement | Current State | Feasible?]

Network readiness assessment: Available IP ranges for NSX TEP, available VLANs for TEP, network reachability confirmed

Step 8

Check licensing status: Document vSphere licensing model (socket-based, core-based?). Check if all hosts are properly licensed (not in trial mode or unlicensed). VCF Import requires valid vSphere licenses to carry forward.

Licensing inventory showing all hosts are licensed; no trial/grace period hosts (which would require relicensing post-import)

Step 9

Assess VM inventory: Count VMs in the cluster, note workload types (development, test, production?). Large clusters (500+ VMs) will take longer to import and carry higher risk. Document: [VM Count | By Workload Type | Memory Allocated | Storage Allocated | Critical VMs?]

VM inventory showing cluster size, workload distribution; plan import sequencing (move lower-risk VMs first, critical VMs last)

Step 10

Synthesize readiness assessment: Create a RACI matrix showing what's compatible, what requires pre-work, and what's a blocker. Mark as: GREEN (ready to import), YELLOW (requires minor pre-work), RED (blocker, pre-work required). Example: vSphere 6.7 = GREEN, vSphere 6.5 = RED (pre-upgrade to 6.7 required).

Readiness checklist with GREEN/YELLOW/RED status for each compatibility dimension; clear action items for YELLOW and RED items

Validation Gate

Check: All 10 substeps completed with comprehensive environment assessment

Expected: Readiness assessment document showing what's compatible, what requires pre-work, and estimated effort to prepare brownfield cluster for VCF import

Common Errors

Assumes old vSphere (6.5 or earlier) is compatible; doesn't plan for pre-upgrade

Cause: Not checking VCF 9.0 minimum requirements (vSphere 6.7+)

Fix: Always verify vCenter version against VCF release notes. If vCenter is 6.5, plan upgrade to 6.7 first (separate project timeline before VCF import can begin).

Overlooks local-only storage; assumes all ESXi have shared storage

Cause: Not auditing storage backend on each host; confusing 'datastore exists' with 'storage is shared'

Fix: Check each ESXi host: 'esxcli storage filesystem list' and determine if datastore is local (unique per host) or shared (accessible from all hosts). Local-storage hosts cannot be imported into VCF.

Plans NSX-T deployment but no IP space available for TEP network

Cause: Assumes IP ranges are available without auditing network plan

Fix: Document all in-use IP ranges (mgmt, vMotion, iSCSI, etc.). Reserve NSX TEP range BEFORE import (e.g., 10.3.0.0/24). Confirm with network team that range is available and VLANs can be created.

Forgets to check licensing; assumes licenses are valid

Cause: Not verifying license assignment on each host

Fix: Check vCenter > Administration > Licensing > Licenses. All hosts must have valid licenses assigned (not in grace period, not expired). Trial licenses carry over but VCDX panelists will ask why you didn't validate licensing upfront.

Task 2 Plan VCF Import: NSX Deployment, Workload Domain Boundaries, IP Addressing

manageability

Import planning is where you decide: Which clusters become which workload domains? Where do we deploy NSX? How do we minimize disruption to workloads? VCDX candidates must think holistically — import isn't just about running the tool; it's about designing the target state. This task forces you to create a detailed design document, not a hasty checklist.

Step 1

Define workload domain boundaries: The brownfield cluster can be imported as a single workload domain, or split into multiple domains (if large). Plan: [Domain Name | Cluster(s) | VI Type | vCenter | NSX Manager (shared or dedicated?)] Example: 'VI-PROD' (3 hosts, production workloads), 'VI-DEV' (2 hosts, dev/test workloads).

Workload domain design showing cluster-to-domain mapping; rationale for splitting (compliance, resource isolation, independent scaling)

Step 2

Plan NSX deployment approach: Option 1 (Non-disruptive): Deploy NSX-T to brownfield cluster without removing NSX-V (if present). NSX-V and NSX-T coexist for migration period (e.g., 6 months). Option 2 (Clean break): Remove NSX-V, deploy NSX-T fresh. Document: [Approach | Duration | Risk | Downtime Required]

NSX deployment plan showing chosen approach (coexistence vs. replacement), justification, and timeline for NSX-V sunsetting (if applicable)

Step 3

Plan NSX Manager placement: NSX Manager can be deployed as a new instance (centralized for management domain) or dedicated per workload domain. Document: [Domain | NSX Manager Instance | Management Domain Shared? | Scaling Implications]

NSX architecture showing whether NSX Manager is centralized or distributed; implications for operations, scaling, and multi-site federation

Step 4

Plan IP addressing for NSX: NSX TEP (Tunnel Endpoint) requires a dedicated network (not used by other systems). Plan: [Network | TEP VLAN | TEP IP Range | Netmask | Gateway | Why This Range?] Example: 'TEP VLAN 102, 10.3.0.0/25 (128 IPs), supports up to 125 ESXi hosts'.

NSX IP plan showing TEP network, VLAN, range, and capacity for current + future hosts

Step 5

Plan vMotion network for import: During import, workloads may need to move between hosts. Plan: [vMotion Network | Current Config | Post-Import Config | Changes Needed?]. If vMotion network stays the same, no changes. If you're restructuring networking, document the plan.

vMotion network continuity plan showing whether vMotion network persists through import or is reconfigured

Step 6

Plan management network for imported cluster: Once imported, the cluster will be managed by SDDC Manager (instead of standalone vCenter). Plan: [Management VLAN | Current IP Range | Post-Import IP Range | SDDC Manager Reachability]. Document how SDDC Manager will reach the imported cluster's vCenter and ESXi hosts.

Management network plan showing SDDC Manager reachability to imported cluster; any network changes or firewall rules needed

Step 7

Plan workload migration strategy (if needed): If brownfield cluster has 500+ VMs and you're restructuring networking, plan how/when to migrate workloads. Document: [VM Cohort | Migration Sequencing | Dependency Analysis | Rollback Plan]. Example: Move dev VMs first (low risk), then non-critical prod, finally critical prod.

Workload migration sequencing showing batches, dependencies, and risk mitigation

Step 8

Plan NSX logical network design post-import: How many segments will you create? Tier-0 gateway? Tier-1 gateways? Distributed firewall policies? Document: [Segment Name | VLAN/Overlay | Subnet | T0 or T1 Gateway | Policies (if any)]

NSX logical network design showing segment strategy, routing model, and security policies

Step 9

Create pre-import checklist: [Item | Pre-Req | Status | Owner]. Example: 'vCenter upgraded to 6.7', 'NSX IP range reserved', 'vMotion network validated', 'vSAN health green', 'Backup of brownfield vCenter taken'. Mark all items as DONE before proceeding to import.

Pre-import checklist with all items signed off; clear green light to execute import

Step 10

Create import runbook: Step-by-step procedure for executing VCF Import Tool. Outline: Pre-flight validation, cluster discovery, cluster import, NSX deployment, workload migration, validation. Each step includes: Command/Action, Expected Output, Rollback Procedure.

Detailed import runbook suitable for handing to operator; includes contingency procedures for failure scenarios

Validation Gate

Check: All 10 planning substeps completed with comprehensive design document

Expected: VCF Import plan (workload domains, NSX deployment, IP addressing, workload migration, pre-import checklist, runbook) ready for execution approval

Common Errors

Plan assumes NSX-V and NSX-T can coexist without traffic routing conflicts; workloads can migrate transparently

Cause: Underestimating complexity of dual-network operation; assuming VMs automatically migrate from NSX-V segments to NSX-T segments

Fix: Key insight: NSX-V and NSX-T are separate data planes. VMs must be manually migrated from NSX-V logical networks to NSX-T segments. Plan explicit migration windows and test VM connectivity during transition. This is non-disruptive if planned carefully; chaotic if not.

IP addressing plan forgets to reserve TEP network; overlaps with existing management network

Cause: Not coordinating with network team; assuming IP ranges are flexible

Fix: TEP network is critical and non-negotiable. Reserve it BEFORE import. Coordinate with network team to allocate a non-overlapping subnet and VLAN. Document it in the import plan.

Workload domain design creates too many small domains (one per 3-host cluster); operational overhead explodes

Cause: Not considering operational cost of managing multiple SDDC instances, NSX instances, vCenter instances

Fix: Consolidate into fewer, larger domains where feasible (3-4 domains is typical for mid-size enterprise). Each domain adds operational burden (monitoring, backup, upgrade complexity).

Import runbook assumes everything goes perfectly; no contingency for mid-import failure

Cause: Not planning for failure scenarios (network issue during import, storage inaccessible, etc.)

Fix: Add failure handling to runbook: 'If import stalls at 50%, check: vCenter connectivity, SDDC Manager certificate validation, NSX Manager reachability. If any component unreachable, pause and investigate before continuing.'

Task 3 Execute Brownfield Conversion Design Exercise Using VCF Import Tool and RCAR

architecture

Execution is where theory meets reality. This task walks you through the VCF Import Tool workflow (discovery → validation → import → post-import migration). You'll handle edge cases (mixed vSphere versions, external storage, NSX-V coexistence) and document decisions using RCAR framework. The goal is a polished design document that would survive VCDX panel scrutiny.

Step 1

Discover brownfield cluster with VCF Import Tool: Launch Import Tool in SDDC Manager UI. Authenticate to brownfield vCenter. Tool discovers cluster: [Cluster Name | Host Count | vSphere Version | Storage Type | Networking | Compatibility Status]. Document discovery results.

Import Tool discovery report showing cluster details and compatibility assessment (GREEN = importable, RED = blocker)

Step 2

Validate pre-import requirements: Import Tool checks: vSphere version, vSAN health, certificate validity, DNS resolution, network reachability. Document validation results: [Check | Status | Action if Failed]

Pre-import validation report showing all checks passed (GREEN); if any RED, list remediation steps and re-run validation

Step 3

Handle edge case: Cluster has mixed vSphere versions (Host 1 = 6.7, Host 2 = 7.0, Host 3 = 8.0). Tool should accept cluster (all versions within supported range). Document: [Host | vSphere Version | Supported?] and plan for vSphere upgrade to match after import (optional but recommended for consistency).

Mixed-version compatibility assessment showing import is feasible despite version heterogeneity; post-import upgrade plan documented (if chosen)

Step 4

Handle edge case: Cluster uses external FC storage (not vSAN). Import Tool should handle this. Document storage configuration: [LUN | Size | Datastore Name | VMFS Version | Shared?]. Verify datastore is accessible from all hosts (shared).

External storage compatibility confirmed; datastore shared and accessible from all hosts; no local-storage-only hosts

Step 5

Handle edge case: NSX-V is deployed on brownfield cluster. Plan coexistence during import: NSX-T will be deployed alongside NSX-V. Document: [NSX-V State | NSX-T Deployment Plan | Coexistence Duration | NSX-V Sunsetting Timeline]

NSX coexistence plan showing how NSX-V and NSX-T will coexist during migration; timeline for NSX-V deprecation

Step 6

Create workload domain configuration in Import Tool: Define domain name (e.g., 'VI-PROD'), vCenter instance, NSX Manager (new or existing), storage type (vSAN or external). Document: [Domain Name | vCenter IP | NSX Manager | Storage Backend | NSX License Model]

Workload domain configuration in Import Tool showing domain parameters and NSX setup plan

Step 7

Plan NSX TEP network in Import Tool: Configure NSX Manager to use TEP VLAN 102, IP range 10.3.0.0/25. Verify tool validates IP range is available and no VLAN conflicts. Document: [TEP VLAN | TEP Subnet | Host TEP IPs (auto-assigned?)] and confirm SDDC Manager accepts configuration.

NSX TEP configuration validated in Import Tool; IP range confirmed available; no VLAN conflicts

Step 8

Create RCAR (Requirements, Constraints, Assumptions, Risks) document for the import: (a) Requirements: vSphere 6.7+, shared storage, network reachability, valid certificates. (b) Constraints: Mixed-version hosts must upgrade to same version post-import, NSX-V and NSX-T coexist for 6 months, SDDC Manager cannot be rolled back after import completes. (c) Assumptions: Network team will provide TEP VLAN, workloads are movable without downtime. (d) Risks: Import hangs midway (mitigation: test pre-flight validation), workload VMs lose connectivity during NSX migration (mitigation: test NSX-V-to-T segment mapping), post-import performance degradation due to NSX overlay (mitigation: performance baseline pre-import).

Comprehensive RCAR document grounded in the brownfield environment's specifics; all risks have documented mitigation strategies

Step 9

Dry-run import in Holodeck (if available): Execute import workflow on a non-prod copy of brownfield cluster (or simulator). Walk through: Pre-flight validation → Import initiation → Cluster join into SDDC Manager → NSX deployment → Workload validation. Document any issues or unexpected behaviors.

Dry-run execution report showing import workflow succeeded in non-prod; any issues and workarounds documented for production run

Step 10

Finalize design document: Synthesize all previous steps into a polished 5-10 page design that includes: Executive Summary (business case for VCF adoption), Current State Assessment (brownfield environment details), Target State Architecture (VCF domain design, NSX topology, IP plan), Migration Strategy (workload sequencing, rollback points), RCAR, and Runbook. This document should be suitable for presentation to architecture review board or VCDX panelists.

Polished brownfield-to-VCF design document demonstrating architectural maturity, edge case handling, and mitigation planning

Validation Gate

Check: All 10 execution substeps completed; design document and RCAR finalized

Expected: Ready for brownfield VCF import; design document can withstand VCDX-level architectural scrutiny; all edge cases and risks are documented with mitigations

Common Errors

RCAR is generic and doesn't reflect the specific brownfield environment (e.g., risks mention 'storage failure' but don't mention external FC array specifics)

Cause: Using a template RCAR instead of tailoring to actual environment

Fix: RCAR must be grounded in the brownfield assessment. Example: 'Risk: External FC array goes offline during import → no shared storage accessible → import fails. Mitigation: Ensure FC array has redundant paths, monitor array during import, have FC admin on standby.'

Design assumes NSX-V and NSX-T can coexist without any traffic disruption; workloads automatically migrate

Cause: Underestimating complexity of network plane migration

Fix: Explicitly plan: Which workloads move from NSX-V to NSX-T first? Test segment mapping (NSX-V VLAN X → NSX-T segment Y). Plan explicit cutover windows. This is NOT automatic; it requires careful orchestration.

Design document lacks rollback strategy; assumes import always succeeds

Cause: Not planning for failure scenarios

Fix: Add section: 'Rollback Procedures'. If import fails at pre-flight, simply don't proceed (no data changes). If import fails during cluster join, SDDC Manager may have partial state (risky). Test rollback in dry-run.

Assumes all workload VMs can be vMotioned freely during import; no consideration for VM dependencies or licensing

Cause: Not auditing workload constraints (database affinity, license server location, etc.)

Fix: Before import, identify VMs with constraints: Databases with affinity rules, license servers, highly stateful applications. Plan workload migration to respect these constraints. Some VMs may need planned downtime or might not migrate at all (acceptable if risk is documented).

Final Validation

You have completed a comprehensive brownfield VCF adoption assessment, planning, and design exercise. You've learned to assess existing vSphere environments for VCF readiness, identify blockers and pre-work, plan NSX deployment and IP addressing, and create a polished design document with RCAR framework. You've also handled edge cases (mixed vSphere versions, external storage, NSX-V coexistence) — critical skills for real-world deployments. VCDX panelists will expect you to articulate brownfield migration complexity and demonstrate risk mitigation strategies.

✓ Environment readiness assessment (Task 1) → Comprehensive audit of brownfield vSphere cluster; compatibility check against VCF 9.0; GREEN/YELLOW/RED status for each component

✓ Import planning (Task 2) → Workload domain design, NSX deployment strategy, IP addressing plan, workload migration sequencing, pre-import checklist, runbook

✓ Design execution (Task 3) → VCF Import Tool workflow executed (or simulated); edge cases handled; RCAR framework applied; final design document completed

✓ Edge case handling → Mixed vSphere versions, external storage, NSX-V coexistence all addressed with documented mitigations

✓ RCAR framework → Detailed Requirements, Constraints, Assumptions, Risks tailored to brownfield environment; all risks have documented mitigations

Cleanup / Restore

• Archive design document and RCAR for future reference (knowledge base entry for similar brownfield migrations)

• If dry-run was executed in Holodeck, snapshot the post-import VCF environment as 'brownfield-import-post' for future labs or training

• Schedule post-implementation retrospective (if production migration occurs): What went well? What was harder than expected? How do we improve next time?

Design Reflection (VCDX)

A VCDX panelist will ask: 'Tell us about a brownfield or migration project. How did you assess the existing environment? What risks did you identify and how did you mitigate them?' Your answer should include: (1) Specific compatibility checks you performed (vSphere version, storage type, networking, licenses). (2) A concrete blocker you identified (e.g., vSphere 6.5 requires pre-upgrade before VCF import) and how you resolved it. (3) Edge cases you handled (mixed versions, external storage, NSX-V coexistence). (4) RCAR framework applied to the migration (specific requirements, constraints, assumptions, and risks for your environment). (5) How you minimized disruption to running workloads (non-disruptive NSX deployment, phased migration strategy). (6) Post-import validation that confirmed success without data loss.

Requirements

Comprehensive assessment of brownfield vSphere environment: vSphere version, storage type, networking model, licensing, VM inventory
VCF 9.0 compatibility matrix: Identify supported vs. unsupported configurations; blockers and pre-work items
Workload domain design: Cluster-to-domain mapping with justification for split or consolidation
NSX deployment strategy: Non-disruptive deployment approach, NSX Manager placement, TEP network planning
IP addressing plan: Management, vMotion, NSX TEP networks with VLAN and subnet allocation
Workload migration sequencing: Risk-ordered batches (dev first, prod last), dependency analysis, rollback points
Pre-import checklist: All pre-requisites validated and signed off before import begins
Import runbook: Step-by-step procedure with expected outputs and rollback procedures
RCAR framework: Requirements, Constraints, Assumptions, Risks tailored to brownfield environment
Design document: Polished 5-10 page architecture suitable for review board or VCDX panel

Constraints

VCF 9.0 supports vSphere 6.7+ only; earlier versions require pre-upgrade (time and risk)
Shared storage is mandatory (vSAN or external); local-storage-only clusters cannot be imported
NSX deployment (NSX-T) requires dedicated TEP network; IP space may be constrained in brownfield environments
Mixed vSphere versions within cluster are supported for import but should be unified post-import for operational consistency
NSX-V and NSX-T cannot share the same overlay network; migration must be explicit and sequenced
SDDC Manager import is one-way; once cluster is imported, reverting to standalone vSphere is difficult and loses VCF management capabilities
Workload VMs may have licenses or affinity constraints that limit mobility during migration

Assumptions

Brownfield vSphere environment is stable and healthy (no ongoing issues that would complicate migration)
Network team can provide dedicated VLAN and IP range for NSX TEP within 2-4 weeks
vCenter in brownfield cluster is reachable from SDDC Manager (HTTPS, SSH connectivity)
Workloads running on brownfield cluster are movable without business-critical downtime constraints (or downtime windows are acceptable)
NSX-V (if present) is in stable state and not actively being modified; safe to coexist with NSX-T for 6 months during migration
Licensing will be transferred; no license re-purchasing required post-import
Brownfield cluster has no custom vSphere configurations (custom portgroups, security policies) that would be lost during import

Risks

vSphere pre-upgrade fails → import is blocked indefinitely → MITIGATION: Plan pre-upgrade as separate project with adequate time buffer before import window
TEP network IP range overlaps with existing network → NSX deployment fails or routing loops occur → MITIGATION: Validate IP ranges with network team before import, document in design
External FC storage array loses connectivity during import → cluster cannot be imported, workloads at risk → MITIGATION: Ensure storage redundancy, schedule import during stable period, have storage admin on standby
NSX-V-to-NSX-T migration disrupts workload connectivity → VMs lose network access, applications fail → MITIGATION: Test NSX coexistence in dry-run, migrate workloads in small batches, have rollback plan (revert VMs to NSX-V if needed)
Import completes but SDDC Manager cannot reach imported vCenter post-import → imported cluster is orphaned, cannot be managed → MITIGATION: Validate SDDC Manager → vCenter connectivity in pre-import checklist, perform post-import connectivity test before declaring success
Workload VM licenses are tied to hardware IDs that change during migration → VMs become unlicensed → MITIGATION: Contact software vendors before migration, prepare license re-keying procedures

Self-Assessment Discussion Prompts

You're assessing a brownfield vSphere 6.5 cluster for VCF import. It's not supported (VCF requires 6.7+). How do you present the situation to the customer? What's the timeline and cost impact of pre-upgrading to 6.7 first?
Brownfield cluster has 800 VMs spread across 5 datacenters connected via WAN. Your plan is to import all clusters at once and deploy NSX-T centrally. Your manager says: 'This is too complex. Simplify it.' How do you reduce complexity without compromising the architecture?
During dry-run, NSX-V and NSX-T coexist. A workload VM is connected to NSX-V segment VLAN 100. You need to migrate it to NSX-T segment 'prod-segment'. The VM must remain powered on. Walk through the exact steps (network reconfiguration, MAC address considerations, policy mapping). What could go wrong?
Post-import, SDDC Manager shows the cluster as 'Healthy', but vSAN cluster shows 'Degraded — unsynced objects'. What could be happening? Is the import a success or partial failure? How do you investigate?

Extensions

Extend Design to Multi-Region Brownfield Migration

Plan brownfield VCF adoption across 3 geographically dispersed datacenters (US-East, US-West, Europe). Document: workload domain boundaries per region, NSX federation strategy for multi-site segments, IP addressing avoiding conflicts across regions, phased migration sequencing (region by region).

harder

Handle Legacy NSX-V Migration to NSX-T During Import

Detailed runbook for non-disruptive NSX-V → NSX-T migration during VCF import. Document segment mapping, edge node migration, policy translation (NSX-V rules → NSX-T firewall rules), and rollback procedures if migration goes wrong.

harder

Build Automated Brownfield Assessment Tool

Write a PowerShell or Python script that audits a vSphere environment and generates a VCF readiness report. Script should check vSphere versions, storage types, licensing, networking prerequisites, and produce a GREEN/YELLOW/RED compatibility summary. This mirrors real-world automation.

harder

Plan Brownfield to VCF Migration with Performance Baseline

Extend design to include pre-import and post-import performance baselines. Document: CPU/memory/network/storage utilization before and after NSX deployment. Analyze NSX overlay impact on performance. Identify any performance degradation and mitigation strategies.

harder

⚠ Known Pitfalls (from Community KB)

Assumed vSphere 6.5 cluster was compatible; didn't plan for pre-upgrade COMMON

Problem: Operator discovered during import planning that vSphere 6.5 is NOT supported by VCF 9.0. VCF requires 6.7 minimum. Pre-upgrade to 6.7 adds 4-6 weeks to project timeline (vCenter upgrade, testing, cutover).

Resolution: Always check VCF release notes for minimum vSphere version. If brownfield cluster is below minimum, plan pre-upgrade as separate project phase before VCF import can begin.

Attempted NSX-T deployment but no IP range available for TEP network COMMON

Problem: Network team couldn't provide a TEP VLAN and IP range within import timeline. Import was delayed waiting for network team to allocate resources.

Resolution: Reserve NSX TEP network EARLY (during assessment phase, not during import phase). Coordinate with network team at the start of brownfield assessment, not the day before import.

Mixed vSphere versions in cluster caused unexpected compatibility issues post-import COMMON

Problem: Cluster had 3 hosts: one on 6.7, one on 7.0, one on 8.0. Import succeeded, but SDDC Manager recommended all hosts be on same version post-import for consistency. Operator had to schedule post-import vSphere upgrades.

Resolution: Plan post-import vSphere upgrade to unify all hosts to same version (e.g., 8.0). This is optional but recommended for operational consistency. Document in design as post-import action.

NSX-V and NSX-T coexistence caused unexpected traffic routing CRITICAL

Problem: Workload VMs connected to NSX-V VLAN 100 attempted to communicate with NSX-T segment 'prod'. Traffic was dropped because routing between the two networks was not configured.

Resolution: During NSX coexistence, you MUST explicitly configure routing between NSX-V and NSX-T networks (usually via NSX-V edge or T0 gateway with inter-VRF routing). This is not automatic. Test in dry-run before production migration.

Post-import, SDDC Manager could not reach imported vCenter due to certificate issue COMMON

Problem: Import completed successfully, but SDDC Manager's subsequent API calls to vCenter failed. Certificate validation error: vCenter's SSL cert was old (issued to old FQDN), SDDC Manager couldn't verify it.

Resolution: Before import, ensure vCenter certificate is valid and has correct SANs (Subject Alternate Names). If certificate is about to expire or uses old FQDN, renew before import.

References

VMware Cloud Foundation Planning & Preparation GuideTier 1 — Official
Essential for understanding VCF 9.0 requirements, supported configurations, and import prerequisites. Section on 'Importing Clusters' covers VCF Import Tool workflow.
VCF Import Tool User GuideTier 1 — Official
Official guide for VCF Import Tool. Covers discovery, validation, import procedure, troubleshooting, and rollback.
NSX-V to NSX-T Migration GuideTier 1 — Official
Comprehensive guide for non-disruptive NSX-V to NSX-T migration. Critical if brownfield cluster has NSX-V deployed.
VCF Supported Hardware (HCL)Tier 1 — Official
VCF 9.0 Hardware Compatibility List. Use to validate that brownfield ESXi hosts are supported for import.
vSphere Upgrade GuideTier 1 — Official
If brownfield vSphere requires pre-upgrade (e.g., 6.5 → 6.7), this guide covers the upgrade path.
William Lam — Brownfield VCF Adoption ExperiencesTier 3 — Expert Blog
Community blog covering real-world brownfield VCF migrations, common pitfalls, and lessons learned.

Mark complete