POST-BROADCOM SERIES
Control Plane & Execution Physics Transition Model
>_ Architecture Principle
Migration is a control-plane and execution-physics transition. Relocating the VMDK is the absolute last layer you should move.
Platform transitions — VMware to Nutanix AHV, sovereign KVM, or hybrid-cloud exit ramps — consistently produce catastrophic Day 2 operational and performance regressions for the same reason: engineers execute them as VM moves. That framing ignores two structural anchors that govern whether the migration succeeds or stalls.
The first is control-plane coupling — the backup APIs, IAM integrations, and monitoring hooks that remain tightly bound to ESXi long after the workloads nominally move. The second is execution physics — the fact that moving from a centralized SAN to HCI turns your Top-of-Rack switches into the storage backplane, and if you haven’t modeled the CVM tax and scheduler rules before cutover, you will encounter Migration Stutter.
This series treats migration as a dependency graph and an execution translation. Each part covers one layer of that model — in the order you should actually address them.
Before committing to a migration path, the platform decision itself deserves the same architectural rigor. Proxmox vs Nutanix vs VMware: The Post-Broadcom Constraints No One Explains covers the constraint model that should frame the destination choice before the execution work begins.
>_ GitHub Repository
Broadcom Exit Strategy — Working Models & Decision Artifacts
Canonical architecture references, blast-radius maps, dependency-first migration model, and the PDF Playbook.
Post-Broadcom Migration Architecture: The Dependency Model
Migration must proceed in reverse order of compute dependencies.
The dependency layer order below is not a project phase sequence — it is the architectural reality of how these systems are coupled. Moving compute before the foundation layers are abstracted produces exactly the three failure signatures this series exists to prevent.
Failure Signature 01
The API Break
Recovery gaps emerge when backup controllers can’t reach new hypervisor APIs — missing vCenter hooks, broken snapshot chains.
Failure Signature 02
Migration Stutter
I/O spikes during rebuild saturate East-West switches. P99 tail latency stalls databases. The CVM controller tax was never modeled.
Failure Signature 03
The IAM Mismatch
Operational tooling fragments because RBAC policies don’t translate 1:1 between vCenter and Prism/KVM. Automation breaks silently.
You’ve Seen the Exit Paths.
Now Model Your Timeline.
The deployment model narrows your options. Your renewal date, your dependency profile, and your team’s execution capacity determine which path is actually viable — and how fast you need to move. The triage session maps that against your specific environment.
Exit Path Scoping & Timeline Model
Detailed execution planning for your migration — dependency audit, dual-spend model, platform recommendation, and migration timeline scoped to your Broadcom renewal window and team capacity.
- > Renewal window and dual-spend analysis
- > Platform recommendation for your stack
- > Workload wave sequencing and cutover plan
- > NSX policy translation scope estimate
Architecture Playbooks. Every Week.
The Broadcom situation moves fast. New licensing intelligence, platform updates, and migration execution patterns land in The Dispatch weekly — before they’re published anywhere else on the site.
- > Broadcom licensing updates & renewal intel
- > AHV migration execution breakdowns
- > NSX → Flow policy translation patterns
- > Real migration failure-mode case studies
Zero spam. Unsubscribe anytime.
The Post-Broadcom Series
Five parts. One execution layer each. Read in sequence.
Beyond the VMDK: Translating Execution Physics
“Lift-and-shift” is a business term, not an engineering one. When you migrate from vSphere to AHV, you are re-homing an execution thread into a fundamentally different kernel environment. This part covers the ESXi vs. AHV scheduler model, the shift from %RDY to %st as the contention metric, and why treating AHV as “vSphere with a different UI” is how you end up in a Migration Stutter at 2am.
>_ Read Part 01The Controller Tax: Modeling Hyperconverged Resource Contention
The CVM is the most consistently under-modeled component in a Nutanix migration. It is a resident tenant on every node — consuming CPU, memory, and network bandwidth to manage the storage fabric. This part covers CVM sizing physics, the performance overhead it introduces under I/O load, and how to model it accurately before production exposes it.
>_ Read Part 02Migration Stutter: Handling High-I/O Cutovers Without Data Loss
East-West network saturation, storage rebuild amplification, and I/O sequencing during live cutovers — modeled before the maintenance window opens.
>_ Read Part 03Policy Translation: Mapping VMware DRS & SRM to Flow
DRS affinity rules, SRM failover policies, and micro-segmentation logic don’t port automatically. This part covers the full policy translation model — decision rules, audit framework, and post-migration drift risk across DRS, SRM, and NSX.
>_ Read Part 04Upgrade Physics: Designing for Rolling Maintenance in AHV
Post-migration Day 2 operations — rolling upgrade sequencing, rebuild traffic modeling during maintenance windows, and drift detection on the new platform.
>_ Read Part 05Canonical Architecture References
The strategic and performance foundations this series builds on.
>_ Strategic Blueprint
Broadcom Exit Strategy
The decision framework — which exit path fits your environment and the fiscal case for acting now vs. deferring.
>_ Execution Reality
Why Licensing Isn’t the Real Risk
Where migrations actually fail — not at the pricing layer, but at the operational coupling layer.
>_ Data Physics
Sizing for the CVM: The HCI Controller Tax
Why mis-sized CVMs kill AHV performance under load and how to validate sizing before production cutover.
>_ Connected Architecture
The Full Execution Stack
The series is the execution layer. The pages below are the architectural targets, performance foundations, and platform deep dives.