Architecture Principle: Migration is a control-plane and execution-physics transition. Relocating the VMDK is the absolute last layer you should move.
This repository contains the working models, decision artifacts, and blast-radius maps for ecosystem transitions post-Broadcom.
Want the full risk-deterministic migration framework and SE whiteboard artifacts? 👉 Download the formatted PDF Playbook here
The continuously maintained architectural specifications live here:
- The Strategic Blueprint: Broadcom Exit Strategy: The Post-Broadcom Migration Architecture
- The Execution Reality: The Architecture of Migration: Licensing Isn't the Real Risk
- The Data Physics: Sizing for the CVM: The HCI Controller Tax
Post-Broadcom Migration Series — Field Engineering Sequence:
| Part | Title | Layer | Status |
|---|---|---|---|
| Part 01 | Beyond the VMDK: Translating Execution Physics | Execution Physics | ✅ Live |
| Part 02 | The Controller Tax: Modeling Hyperconverged Resource Contention | Resource Contention | ✅ Live |
| Part 03 | Migration Stutter: Solving High-I/O Cutovers Without Data Loss | High-I/O Cutover | ✅ Live |
| Part 04 | Policy Translation: Mapping VMware DRS, SRM & NSX to Flow | Policy Translation | ✅ Live |
| Part 05 | Upgrade Physics: Designing for Rolling Maintenance on AHV | Validation & Ops | ✅ Live |
---
## Problem Statement
Platform transitions (e.g., VMware → Nutanix AHV / Sovereign KVM) frequently result in catastrophic Day 2 operational and performance regressions because engineers execute migrations as simple "VM moves."
This ignores two critical system anchors:
1. **Control-Plane Coupling:** Dependencies on backup APIs, IAM, and monitoring remain tightly coupled to the legacy ESXi hypervisor.
2. **Execution Physics:** Moving from a centralized SAN to a distributed Hyperconverged Infrastructure (HCI) turns the Top-of-Rack switches into the storage backplane. If you do not account for the CVM tax and scheduler rules, you will encounter "Migration Stutter."
This framework models migration as a dependency graph and an execution translation—not a compute relocation.
---
## System Model
**The Dependency Layer Order (Top → Bottom):**
1. **Identity / RBAC** (Who can authorize)
2. **Backup & DR** (How we survive failure)
3. **Monitoring & Automation** (How we observe state)
4. **Storage & Network Fabric** (Where the data lives and transits)
5. **Compute / VMDK** (Where the CPU executes)
*Migration must proceed in reverse order of compute dependencies (Top to Bottom).*
---
## Failure Signatures
If compute moves before the foundation layers are abstracted:
- **The API Break:** Recovery gaps emerge because backup controllers cannot talk to the new hypervisor APIs (e.g., missing vCenter hooks).
- **The Migration Stutter:** I/O spikes during replication/rebuilds saturate the East-West network switches, causing P99 tail latency to stall databases because the new HCI controller tax was ignored.
- **The IAM Mismatch:** Operational tooling fragments because RBAC policies do not translate 1:1 between vCenter and Prism/KVM.
---
## Migration Phases
| Phase | Objective | Execution |
| :--- | :--- | :--- |
| **Phase 1** | Operational Independence | Decouple monitoring, logging, and metrics from legacy VMware-specific tooling. |
| **Phase 2** | Backup Independence | Establish storage-agnostic snapshot and replication paths. |
| **Phase 3** | Identity Abstraction | Map AD/Entra groups to the new platform RBAC model (e.g., Nutanix Flow). |
| **Phase 4** | Storage I/O Modeling | Calculate write amplification, the CVM Controller Tax, and network buffer requirements. |
| **Phase 5** | Compute Relocation | Cutover the CPU/RAM execution state. |
---
## Decision Matrix
| Environment | Control-Plane Abstraction | I/O Performance Modeling |
| :--- | :--- | :--- |
| **Enterprise Production (Monolithic DBs)** | ✅ Mandatory | ✅ Mandatory (Focus: Data Locality & CVM Overhead) |
| **Enterprise Production (Scale-out/Microservices)** | ✅ Mandatory | ✅ Mandatory (Focus: Network Throughput) |
| **Greenfield / Dev Environments** | ⚠️ Optional | ⚠️ Optional |
| **Lab Environments** | ❌ Not Critical | ❌ Not Critical |
---
## Non-Goals
- Product comparisons (UI/UX)
- Vendor endorsements
- Synthetic feature benchmarking
*This is a strict control-plane and execution-physics architecture model.*
---
## Support
If this framework clarified your transition strategy and prevented a Day 2 outage, please star the repository.
Architectural frameworks maintained by **[Rack2Cloud](https://www.rack2cloud.com)**.