The 46-Workload Single-Weekend Mandate
A regional freight-forwarding company must vacate its colocation cage in eight months because the lease will not be renewed. Its estate contains 46 production workloads: 18 hypervisor VMs, 9 physical servers, 12 vendor-hosted applications with local agents, and 7 custom services. Annual infrastructure run-rate is $2.4 million, and the CFO has committed publicly to a 20% reduction in year one. The CIO's plan is a single 36-hour cutover weekend that rehosts all 46 workloads as-is, followed by 'optimization later.' The team has six infrastructure engineers, two application developers, and no cloud architect. Discovery found that 22% of servers have no documented owner, five workloads depend on non-transferable Oracle licenses, and the custom freight-rating engine was written in 2009 with no source code and no active maintainer. Customer shipment records must remain in-country under a regulatory requirement. The board wants a go/no-go decision on the single-wave plan within two weeks.
1. Evaluate the CIO's single-wave rehost plan. What methodology and wave structure would you recommend, and what would you tell the board?
Read the worked answer
The single-wave plan should not be approved as written. Rehosting 46 workloads in one 36-hour window concentrates dependency, licensing, and rollback risk in a team with no cloud architect. Use a stage-gated methodology: assess, plan, design, migrate, validate, optimize, govern. First triage every workload with the 6Rs. Put the 22% unowned servers into a retain/quarantine track until an owner is found; they cannot be migrated safely. Build waves by dependency cluster and business risk, not by server count. Wave 0 should be 6-8 low-risk stateless workloads, used to prove the factory, network, backup, and rollback. Wave 1 handles license-constrained workloads after replatform or repurchase decisions. The rating engine and regulated data go last, with dedicated validation. Give the board a conditional go: approve the program, not the single cutover; require wave exit criteria, a tested rollback per wave, and a 20% cost model validated after wave 0. This preserves the lease deadline while avoiding an all-or-nothing event.
2. Decide the disposition of the freight-rating engine using the 6R framework and justify the decision.
Read the worked answer
Use 6R decision logic. Refactor and replatform both require source code or vendor support; neither exists, so they are out. Retire is unsafe because the engine is revenue-critical. Repurchase is viable only if a commercial rating engine can be configured and tested before the lease ends; that is a parallel track, not a migration tactic. The realistic choice is rehost: move the binary to IaaS with the same OS, runtime, and database drivers, preserving its behavior. Because there is no maintainer, treat it as an appliance: isolate it in its own subnet, snapshot before and after cutover, add external monitoring and log capture, document the runtime inventory, and create a functional regression pack from production test cases. If the license or hardware dongle cannot move, retain it in a small colocation slice and connect privately. Record the residual risk in the register and set a one-year deadline to replace or support it. Do not let the engine ride in a broad wave.
3. Define success metrics and governance for the program so the board can judge progress.
Read the worked answer
Success must be measured beyond 'servers moved.' Use four categories: business continuity (shipment processing volume, SLA attainment), technical (availability, p95 latency, batch completion), financial (run-rate against the $2.4M baseline, unit cost per shipment, license exit savings), and delivery (workloads per wave, defect and rollback rate, dependency discovery completeness). Governance: a steering committee with CIO, CFO, security, and business owners meets every two weeks; an architecture review board approves exceptions; a migration factory lead owns the runbook. Require evidence, not status: test results, reconciliation reports, rollback drills. Track the 22% unowned servers as a risk with named owners. Define a stop rule: if wave 0 misses two exit criteria, pause the next wave. This keeps the 20% target honest and prevents the board from hearing 'done' when only VMs are powered on.