Farm-supply distributor: the month-end batch and the $210,000 refresh
A regional farm-supply distributor runs its own data center with 40 physical servers. The ERP pricing batch runs for three days at every month end; for the rest of the month those same servers sit roughly 70 percent idle. A like-for-like hardware refresh quote lands in eight months at about $210,000, and finance has already booked it as a capital expense. Separately, the company wants to launch a dealer e-commerce pilot next quarter. Marketing has warned that a single promotion could multiply traffic tenfold within days, and nobody can forecast the baseline. The CIO has been told to "move to the cloud" but wants the business case written in terms the CFO will accept, and is nervous that a wholesale lift-and-shift will simply reproduce today's idle capacity as a recurring bill. There is no cloud team in-house; the two operations engineers have never opened the AWS console.
1. Which cloud characteristic directly addresses the month-end batch pattern, and how would you put a number on it for the CFO?
Read the worked answer
The relevant characteristic is elasticity with pay-as-you-go consumption: capacity can be added for the three-day peak and released afterwards, so you pay for server-hours rather than for owned boxes.
Quantify it in fleet-hours. Suppose the batch needs all 40 servers during the peak and the remaining workload needs 12 the rest of the month:
- Fixed fleet: 40 servers x 730 hours = 29,200 server-hours per month.
- Variable fleet: (40 x 72) + (12 x 658) = 2,880 + 7,896 = 10,776 server-hours, about 63 percent fewer.
Then be honest about what that comparison leaves out, because the CFO will ask: idle on-premises capacity is not free (power, cooling, rack space, and the refresh amortised over its life), but the cloud bill also carries data transfer, storage, licence portability questions for the ERP, and the cost of the skills the company does not yet have. Present the fleet-hour figure as the shape of the saving, not the final number, and note that the saving only materialises if the batch tier actually scales down after day three rather than being left running.
2. The CFO thinks in capital and depreciation. How do you explain the capex-to-opex shift, and why does the $210,000 refresh quote matter to the decision?
Read the worked answer
Frame it as a change in who carries the risk of guessing wrong. Today the company buys 40 servers, depreciates them over several years, and pays for peak capacity every hour of every month whether or not the batch is running. Cancelling or deferring the refresh converts a committed capital outlay plus a multi-year depreciation schedule into a variable operating expense that tracks consumption.
The $210,000 matters for three reasons. First, it is an avoidable outflow, so the cloud comparison should be against the refresh plus power, space and support, not against a zero baseline. Second, it is a bet on a demand forecast: if the dealer e-commerce pilot succeeds, the on-premises fleet is the wrong size on day one, and the refresh has to be repeated. Third, it changes the budget conversation, because operating expense has to be governed - without tagging, budgets and periodic review, variable spend drifts upward and no one notices until the invoice arrives.
Say plainly that cloud is not automatically cheaper; a lift-and-shift of 40 idle servers reproduces the problem as a monthly bill.
3. The company must migrate a stable ERP and launch an unpredictable e-commerce pilot. Which migration approach for each, and what is the main risk you would flag?
Read the worked answer
Treat them differently because their uncertainty is different.
ERP: rehost first, then rightsize. The application is stable, poorly understood by a team with no cloud experience, and not a source of competitive advantage. A lift-and-shift gets the refresh cancelled and buys time; then rightsize instance families against measured utilisation, move the database to a managed engine if the licence allows, and retire the servers that turn out to be doing nothing. Trying to re-architect the ERP in the same project multiplies risk on the workload the business cannot afford to lose.
E-commerce pilot: build for elasticity from the start (managed compute, managed database, static content from object storage and a CDN) because the demand forecast is unknown and a tenfold promotion spike is exactly what on-premises capacity cannot absorb. Keep it loosely coupled from the ERP so a promotion surge cannot take down order processing.
Main risk to flag: a team with no cloud experience owning both at once. Sequence them, or bring in help for the pilot, and set a cost guardrail before the second workload goes live.