The "40% cheaper" claim at a promotion-driven retailer
A regional retailer runs 46 VMware VMs in its own data centre: 12 web/API servers, 8 application servers, 4 Oracle database servers (3 TB total), 6 batch/ETL nodes, and 16 internal tools. Average CPU utilisation across the estate is 11%. Twice a year, during promotion campaigns, the web and application tiers reach 70-80% for about 9 hours. The CIO has read that public cloud is roughly 40% cheaper and wants a full migration inside one quarter. Finance has already signed a three-year lease on the data-centre space, with a CNY 600,000 break fee. The Oracle licences are core-based and cannot be moved to a shared, multi-tenant environment without repricing. Huawei Cloud does not offer Oracle as a managed database service, so a move would mean re-platforming or running Oracle on ECS under bring-your-own-licence. The 16 internal tools have no named owner, no documentation, and are used by about 30 staff. Data egress from the current data centre is already paid for at a flat rate.
1. The CIO's business case assumes all 46 VMs move and that the 40% saving is a property of the cloud. Critique that assumption and say where the saving actually comes from.
Read the worked answer
The 40% figure is being applied to a spend that does not exist yet. Today the retailer pays for capacity it provisioned for two 9-hour windows a year; the money is already spent and is mostly sunk in the lease. Moving the same 46 VMs one-for-one to ECS reproduces that provisioned footprint in a pay-per-use or yearly/monthly bill and adds egress, load balancer, snapshot and support charges. That is a lift-and-shift, and lift-and-shift is normally more expensive, not 40% cheaper.
The saving comes from four specific things, none of which is automatic:
- Right-sizing against the 11% average. Consolidating idle capacity is the biggest lever, and it is available on-premises too. It only becomes a cloud saving if you actually reduce vCPU/RAM in the target flavour.
- Elasticity for the two peak windows. If the web tier scales out for 9 hours twice a year instead of existing year-round, you stop paying for ~8,700 idle hours per instance per year. This is genuinely cloud-specific.
- Converting capex and refresh cycles to opex, which improves cash flow but is not a cost reduction in absolute terms.
- Retiring the lease and hardware refresh - but that is offset by the CNY 600,000 break fee and by Oracle repricing.
So the defensible statement is: a re-architected subset of the estate can be cheaper; a wholesale relocation of 46 VMs cannot be assumed to be. The 40% number should be rebuilt bottom-up per workload class.
2. Classify the 46 VMs into move-first, move-later and keep-on-premises, and justify each decision using the constraints in the setup.
Read the worked answer
Move first - the 12 web/API servers. They are stateless, they carry the entire peak variance (the 70-80% spike), and they are the only tier where elasticity converts directly into avoided spend. They have no data gravity beyond static assets, which go to OBS. This is the lowest-risk, highest-return wave and should run as a pilot with an auto scaling group sized to the 9-hour profile.
Move second - the 8 application servers. Same direction, but only after session state is externalised (for example to DCS Redis), otherwise the tier is not horizontally scalable and the elasticity argument collapses. Expect to find hidden coupling to the Oracle tier during this wave.
Move later or conditionally - the 6 batch/ETL nodes. Batch is often the best cloud fit of all because it tolerates interruption and can use scheduled or spot capacity, but it is tightly coupled to the 3 TB Oracle warehouse. Sequence it after the data decision, not before.
Keep on-premises for now - the 4 Oracle servers. Three reasons: core-based licences cannot move to a shared environment without repricing, Huawei Cloud does not sell Oracle as a managed service, and 3 TB has real migration-window and data-gravity cost. The realistic options are re-platform to a managed MySQL/PostgreSQL-compatible service, or stay put until the licence renewal forces the decision. Do not put this in wave one.
Keep - the 16 internal tools. No owner, no documentation, 30 users. Migrating them produces no saving and creates unbounded support risk; the correct action is to inventory and retire them, not to move them.
3. The CIO wants a single go/no-go date. What would you put in front of them instead, and why is a single cutover date the wrong control?
Read the worked answer
A single cutover date conflates a portfolio of workloads with very different risk profiles into one binary event. It also means the first real test of the target architecture happens at maximum scale with no rollback path, which is exactly the failure mode that turns a migration programme into a cost overrun.
A better control is a small number of decision gates, each with an exit criterion:
- Gate 1 - right-sizing evidence. Thirty days of guest-level CPU, memory and IOPS data for all 46 VMs. Without this, every target flavour is a guess and the business case cannot be validated. Exit when the top 10 workloads have measured p95 profiles.
- Gate 2 - web tier pilot against a real campaign. Move the stateless tier, then replay one promotion window's load profile. Exit when the auto scaling group holds p95 latency at the current baseline with no manual intervention.
- Gate 3 - data decision. A written comparison of re-platforming against staying on Oracle, including licence repricing, the 3 TB migration window, and the cost of running dual systems during transition. This gate can legitimately return "stay".
- Gate 4 - lease economics. A dated decision on whether to trigger the CNY 600,000 break fee, which is only rational once enough load has actually left the data centre.
Each gate has a cost ceiling, so the programme can be stopped cheaply. That is what the CIO actually needs: not one date, but an agreed set of points at which the answer can still be no.