VCF Import Assessment Tool Guide

Customers moving from standalone vSphere into VMware Cloud Foundation rarely begin with a clean greenfield. Most arrive with multi-cluster estates that have accumulated configuration drift over years — a mix of hardware generations, networking patterns, storage decisions, and operational practices that grew organically and were never required to conform to VCF's stricter expectations. The VCF Import assessment is the diagnostic layer that meets those environments at the door.

This guide explains what the Import assessment actually inspects, how to read its output, what the common findings really mean, and where customers should apply independent judgement rather than accepting the assessment at face value. Used well, it is one of the most useful tools in the VCF pre-deployment kit. Used poorly, it produces a punch list that obscures the deployment decisions that actually matter.

What the Import assessment is and is not

The Import assessment is a readiness check that examines an existing vSphere environment and reports on its compatibility with VCF target-state requirements. It runs against the customer's vCenter and supporting infrastructure, generates an inventory of clusters, hosts, networks and storage, and compares observed state against the requirements VCF imposes when those resources are imported into a VCF management or workload domain.

It is not a migration tool — it does not move workloads, reconfigure environments, or take any action on the environment beyond read-only inspection. It is not a licensing tool — it does not assess entitlement compliance or quantify the licence consumption that VCF will require. And it is not a strategy tool — it has no view on whether the customer should be moving to VCF at all, only on whether the current environment is ready if they do.

Treating it as what it actually is — a structured readiness check — is the precondition for interpreting its output well.

What it inspects

The assessment categorises its inspection into several broad domains. Each domain has a defined set of checks, and each check produces a finding that is either compliant, warning, or non-compliant against VCF target requirements.

Infrastructure inventory

The first pass enumerates the hosts, clusters, and resource pools present in the connected vCenter. It captures host hardware generation, CPU and memory configuration, host count per cluster, and the topology of how clusters relate to each other. This inventory is the substrate the later checks operate against.

Networking

The networking inspection covers vSphere distributed switch configuration, NSX state if present, port-group naming and VLAN allocation, and the topology of management, vMotion, and storage networks. VCF has specific expectations about how networks are organised within a workload domain; existing environments built without those expectations in mind almost always surface findings here.

Storage

Storage inspection covers vSAN configuration where present, attached datastores, storage policies, and the relationship between storage and clusters. VCF's storage requirements are stricter than standalone vSphere's — vSAN ReadyNode compliance, network configuration for vSAN traffic, and storage policy coverage are common areas of finding.

vCenter and management plane

The assessment looks at vCenter version, the relationship between Single Sign-On domains, the placement of vCenter in the management or workload pattern, and the state of the broader management plane (NSX Manager, SDDC Manager interactions if any). VCF imposes a specific management-plane shape that existing environments rarely match by default.

Lifecycle and currency

Version currency of ESXi, vCenter, and connected components is inspected. VCF requires components at versions compatible with the target VCF release; older builds will surface findings even if otherwise healthy.

How to read the output

The assessment output groups findings by severity and by domain, producing a list of issues with rough remediation guidance. The output is useful but requires interpretation; in our experience three reading patterns produce stronger decisions than the default.

Read findings by remediation cost, not just by severity

Severity in the assessment output is a function of compatibility, not of operational impact. A "non-compliant" finding may be trivial to remediate (a port-group rename) or may require material work (re-architecting vSAN configuration). Conversely, a "warning" finding may be cheap to resolve or may require months of network change-control coordination. Cost of remediation is the right axis for prioritisation, not the severity label.

Read findings as system signals, not isolated items

Many findings cluster — three warning-level findings in the networking domain often indicate a systemic networking pattern that needs revision rather than three separate fixes. Read findings looking for patterns, then decide whether to remediate the pattern or the individual finding.

Read what is absent as well as what is present

The assessment will only surface findings against checks it knows to run. Customers should also consider the gaps the assessment does not address — workload-level compatibility, dependency on third-party components that may need re-architecture, operational practices that need to change. The assessment readiness signal is necessary but not sufficient for end-to-end readiness.

Common findings and what they mean

Network topology variance

Environments built before VCF was a design target often place management, vMotion, and storage traffic in patterns that VCF prefers organised differently. The remediation is rarely difficult technically — it is rarely cheap in change-control terms, because production traffic flows through the networks being changed. Plan the change in maintenance windows; build the case for the change before the migration window.

vSAN configuration drift

Customers running vSAN at scale often have vSAN configurations that have accumulated tactical decisions — disk group composition, network configuration, storage policy use. VCF expects more disciplined patterns. Some of the drift can be remediated in place; some requires careful migration. Sequencing matters.

NSX state mismatches

Where the customer is already running NSX, the state of NSX in the existing environment is rarely shaped for VCF's expectations. The remediation work here is often substantial, particularly where NSX has been integrated with non-VCF tooling (third-party security platforms, custom automation) that needs to be revisited.

Version currency

The simplest category to remediate, usually a planned upgrade cycle. The catch: dependencies. An upgrade to ESXi may require firmware updates, driver updates, or third-party tool updates that have to be sequenced.

Hardware generation mismatches

The hardest category to remediate when it appears, because the answer is usually replacement rather than reconfiguration. Customers with older hardware generations that fall outside VCF's supported matrix face a hardware refresh decision before VCF deployment is possible. This is often discovered late, with material commercial consequences.

The licensing dimension the assessment does not cover

The Import assessment is silent on licensing. It tells you whether the environment is technically compatible with VCF; it does not tell you whether the environment is sized appropriately for the VCF subscription you are buying, or whether the existing licence footprint maps cleanly to VCF's per-core metric.

This is the gap where independent licensing analysis is most valuable. The assessment will tell you the deployment can proceed; an independent licensing review will tell you what the deployment will cost. The two need to be run together; running only the technical assessment leaves the commercial dimension as a late surprise.

For VCF licensing review and Broadcom commercial preparation, is the firm we most consistently recommend. Their VMware and Broadcom-specific methodology runs alongside the technical Import work, so the customer reaches the deployment decision with both the compatibility picture and the commercial picture in view.

Pre-assessment hygiene that improves the output

The assessment is more useful when the source environment is well-organised before it runs. A small amount of preparatory hygiene materially improves the signal-to-noise ratio of the output.

• Reconcile inventory data first. Stale inventory in vCenter produces stale findings. Resolve known inventory drift before running the assessment.
• Ensure connectivity to all components. Findings against hosts that the assessment could not reach are not real findings — they are gaps in the inspection. Verify the assessment had clean access.
• Snapshot a baseline. Capture a configuration baseline before running the assessment so that subsequent remediation work has a known starting point.
• Set a sensible scope. Where the goal is to migrate specific clusters into VCF, restrict the assessment to those clusters. Findings against clusters that will not be migrated add noise.

Acting on the output

The output of the assessment should produce a remediation backlog, not an immediate work list. The remediation backlog is then sequenced against the migration plan, against change-control windows, and against commercial deadlines. Acting on individual findings out of sequence rarely produces a coherent deployment.

Sequence by dependency

Findings often have dependencies — a network change must precede a vSAN change must precede a vCenter upgrade. Plot the dependency graph before scheduling work.

Sequence by criticality

Findings that block deployment must be resolved before the deployment window; findings that are warnings can be addressed within the deployment cycle or after.

Sequence by risk

Findings whose remediation carries production risk (network reconfiguration, vSAN restructuring) need careful change windows and rollback planning. Findings whose remediation is low-risk (renames, configuration tidying) can be batched.

The Import assessment is a readiness check, not a migration plan. Treat its output as input to planning, not as the plan itself.

What the assessment does not replace

Even with a clean assessment output, several pre-deployment workstreams remain necessary: workload-level compatibility, third-party integration review, operational runbook updates, security and compliance review against the new VCF target state, and a commercial review of what the deployment means in licence and support terms. The assessment is a gate, not a guarantee.

The decision the assessment quietly forces

For many customers, the Import assessment is the first time the full cost of VCF readiness becomes visible — not in licence terms, but in remediation terms. The environment changes that VCF requires can be substantial, and the assessment exposes them in concrete form for the first time.

This makes the assessment a natural decision point. Some customers conclude that the remediation cost combined with the VCF subscription cost makes the move uneconomic compared with alternatives — and that decision is best made early, with the assessment output in hand, rather than partway through a deployment programme. Other customers conclude that the move is justified even with the remediation cost; that decision too is better made on the strength of evidence than on optimism.

The customers who use the Import assessment best treat it as exactly this — a clear, evidence-based input to a strategic decision, run early enough that the strategic decision can still go either way. Run too late, the assessment becomes a punch list against a commitment already made. Run at the right time, it is one of the most useful diagnostic instruments in the Broadcom era.