Right-Sizing by Average CPU in a Peak-Season Retail Estate
A national retail chain is planning to migrate 220 applications and 140 VMware VMs to a public cloud region. A discovery tool reports that 35% of VMs have average CPU below 5%, but 18 workloads exceed 85% memory utilization at month-end close. Automated dependency mapping covers only 60% of the estate; the rest is based on interviews with application owners, three of whom have left. The migration factory has ten engineers and can move eight to ten servers per weekend with validation. The business freeze runs from November 1 to December 31 for peak season, and no production changes are allowed. One warehouse management system requires under 45 ms round-trip latency to on-premises label printers; the MPLS contract has three years remaining. The CIO wants to right-size every VM to the smallest instance that fits the discovery average to reduce cost.
1. Evaluate the CIO's right-sizing proposal. What sizing approach would you recommend and why?
Read the worked answer
Reject average-CPU-only right-sizing. Average CPU below 5% can coexist with memory pressure, and 18 workloads already exceed 85% memory at month-end. Sizing to the discovery average would under-provision those systems and create peak-season outages. Use P95/P99 CPU, peak memory, IOPS, network, and concurrency; keep the 18 memory-heavy workloads on memory-optimized instances with headroom. For the rest, right-size in two steps: migrate with a safety buffer, then tune after 30 days of production telemetry. Do not shrink below the current physical core count for latency-sensitive systems. Also separate cost levers: reserved capacity, storage tiering, and shutting down non-production schedules often save more than aggressive VM downsizing. The CIO's goal is valid, but the method must be evidence-based and reversible. Put the sizing assumptions in the wave design and require application owner sign-off for any workload below its current memory footprint.
2. How should the team handle the incomplete dependency mapping before committing workloads to waves?
Read the worked answer
Incomplete dependency mapping is a schedule risk, not a reason to guess. Run agent-based or network-flow discovery for at least three weeks on the remaining 40%, prioritizing the 18 memory-heavy and warehouse-adjacent systems. Combine that with application-owner workshops, CMDB reconciliation, and test transactions that exercise upstream and downstream interfaces. For any application with unknown dependencies, do not put it in an early wave; classify it as retain until proven. Use a dependency gate: no workload enters a wave until its inbound and outbound flows are documented, including batch files, DNS, and authentication. For the warehouse system, the 45 ms label-printer requirement may force a hybrid pattern: keep the latency-sensitive print path on-premises and migrate the rest, or re-architect printing locally. The three departed owners are a control gap; assign a business sponsor who can accept residual risk in writing.
3. Build a realistic wave plan through the November-December freeze, showing capacity math and sequencing.
Read the worked answer
Build backward from the freeze. If the factory can move 8-10 servers per weekend, a realistic plan completes roughly 110-130 VMs before November 1, not all 140, because validation and dependency gates consume capacity. Run about 20 weeks of waves: wave 0 pilot 8 servers in weeks 1-2; waves 1-6 at 10 servers per weekend through October, with a no-migration buffer the last two weekends for stabilization. Sequence low-dependency, stateless workloads first; put the warehouse system last or keep it hybrid. Do not schedule production cutovers during November-December; use the freeze for documentation, retraining, and post-migration optimization only. After January 1, finish the remaining VMs in two waves before the next peak planning cycle. Publish the capacity math to the CIO: the constraint is not weekends, it is validated dependency and application sign-off.