Every VCF deployment has a handful of decisions that get made early, fast, and without much ceremony — usually somewhere between "the network team finally sent us the VLAN list" and "we have a hard stop, the client wants to go live Friday." Most of those decisions don't matter much in the long run. A few of them are landmines. They don't go off at bring-up. They go off six months later, when there's a production workload sitting on top of them and nobody left from the original deployment to explain why it was built that way.
I want to walk through three I run into constantly, because they're not exotic — they're the same handful of mistakes showing up in slightly different clothes across almost every environment I've inherited or been called in to fix.
The vLCM Image That Looked Fine Until It Didn't
Here's a scenario that should sound familiar to anyone who's run a VCF environment past its first year: cluster's healthy, hosts are green across the board, vSAN's happy. Then the quarterly patch cycle comes around. SDDC Manager kicks off remediation, gets through the first host clean, and the second host fails compliance with some variation of "the image on the host does not match the image set for the cluster."
Nine times out of ten, the root cause traces back to bring-up. Someone built the cluster image with the ESXi base build and called it done, without properly pairing it to the vendor's Hardware Support Manager — Dell's OMIVV, HPE's OneView, whatever the shop runs. Or the HSM was there, but the firmware and driver add-on selected didn't actually match the hardware that got racked, because the BOM changed between the design phase and the actual delivery and nobody updated the image to match.
It passes at bring-up because vLCM isn't checking every component against reality on day one — it's validating what you told it to validate. The mismatch sits there quietly until the next remediation cycle tries to push firmware the HSM doesn't recognize as compatible.
I've spent entire afternoons watching an iSUT service silently sit there not set to AutoDeploy because nobody flipped that flag during the original build, and every remediation attempt after that just spins. None of this is hard to avoid. It's hard to notice you need to avoid it, because the image was never wrong on day one — it was incomplete, and incomplete doesn't show up as a fault until something tries to act on the missing piece.
The Segment Topology Nobody Thought Past Go-Live
NSX-T transport zones decide which hosts can even see which segments. It's foundational plumbing, and like most foundational plumbing, nobody thinks about it again once it's buried under five layers of finished work.
The pattern I see: a deployment team stands up a single VLAN transport zone, throws every segment into it because it's fast and it works, and moves on to the next milestone. Functionally, nothing is broken. VMs talk to each other. The application teams are happy. Everyone signs off.
Eighteen months later the security team — often a different team than the one that signed off originally — wants to apply the Distributed Firewall to isolate a specific application tier. That's when whoever's holding the environment discovers that the segments for that tier were never organized around application boundaries in the first place. They were organized around whichever VLAN was free that week. Writing DFW rules against that structure means either grouping VMs by IP and hoping nobody adds a new one outside the range, or stopping the project to go restructure segments that now have live production traffic running across them.
- Patch cycle remediation failures. SDDC Manager reports the host image doesn't match the cluster image — months after bring-up, on hosts already carrying production load.
- Micro-segmentation requests that don't fit. The security team wants DFW policy on a specific application tier, and the segment topology was never built with tier boundaries in mind.
- "Temporary" HCX network extensions still running. A migration wraps, the workloads move, and the NE appliance just keeps tromboning traffic back to a site that was supposed to be decommissioned.
- Certificate expirations nobody tracked. Default certs on vCenter, SDDC Manager, or NSX-T components were never rotated, and authentication errors show up with no obvious cause.
I genuinely don't think this is a knowledge gap most of the time. I think it's a sequencing problem — segment topology gets treated as a Day 0 checkbox instead of a decision that has to anticipate a Day 180 requirement nobody's asked for yet. The fix costs nothing extra at design time. It costs a maintenance window and an uncomfortable conversation later.
The Network Extension That Was Supposed to Be Temporary
This is the one that gets left alone the longest, because on the surface, nothing looks wrong.
HCX Network Extension stretches an L2 segment from source to destination during a migration. Without Mobility Optimized Networking properly enabled — and without someone explicitly migrating the default gateway location for each workload once it's settled on the new side — every one of those VMs keeps routing through the original source-site gateway. Two VMs that migrated together, sitting on the same host, in the same destination data center, can still be sending traffic on a round trip back to a site that was supposed to be decommissioned eighteen months ago.
I've walked into environments where the original migration was declared "complete" the day the last VM moved, and the network extension just... kept running. Nobody owned closing it out. The cutover plan covered moving the workloads. It didn't cover the part where someone has to flip the router location for forty VMs and then formally decommission the NE appliance. So it sat there, quietly tromboning traffic, until a latency complaint on an app that should've had single-digit-millisecond response times led someone to run a traceroute and discover their "local" database call was leaving the building.
The technology did exactly what it was told to do. Nobody told it to stop.
Was the cluster image validated against the actual racked hardware, not just the BOM on paper?
Is there a hardware support manager properly paired to the image, and has it actually been tested through a remediation cycle?
Were segments organized around application tiers, or around whatever VLAN happened to be free that week?
Is there a named owner and a hard date for HCX network extension decommission — not just a migration wave plan?
What Actually Prevents This
I don't think the fix here is "write better documentation," even though better documentation always helps. The real fix is having someone in the design seat who's already paid the bill for these mistakes once and isn't interested in paying it again. Image composition, segment topology, and NE decommission planning all look like Day 0 details. They're actually Day 180 commitments wearing a Day 0 costume.