The cloud is not another data centre: the commercial model changed

Many cloud disappointments begin with a reasonable instruction: move what we have and change as little as possible.

The instruction is not foolish. Changing as little as possible reduces the risk of the move itself, and when a data-centre contract is ending, risk on the day matters. But the same instruction carries everything else across too: servers sized for a peak that rarely comes, test environments nobody switches off, approvals that take a fortnight, dependencies nobody has drawn, and costs nobody owns. In the data centre those habits were mostly invisible, because the money had already been spent. In the cloud they arrive on an invoice every month.

That is the subject of this seven-part series. The cloud can be faster, more resilient and better equipped than a data centre, but it is not cheaper by default, and it is not simply somewhere else to put servers. It is a different commercial model, and the organisations that get value from it change the way they buy, build, own and pay for technology alongside the move.

Bushbuck Brands is fictional, and its systems and figures are illustrative. Bushbuck is a South African FMCG distributor headquartered in Isando, with about 1,800 staff, three distribution centres and some 9,000 independent retailers and spaza shops among its customers. Its 22-person IT team runs about 140 applications on roughly 320 virtual machines in a leased co-location facility in Johannesburg. The co-location contract ends in June 2027, and the storage array is already out of support. We follow Bushbuck through the whole series.

Bushbuck's surprise

Between February and May 2026, Bushbuck moved its first wave of 46 applications to a public cloud region in South Africa. To keep the move safe, the team copied each server's size exactly: a VM with 16 virtual CPUs and 64 GB of memory on-premises became a VM with 16 virtual CPUs and 64 GB in the cloud.

The migration went well. Nothing broke. Six months later, the monthly cloud bill was running at about R1.9 million, against a business case that had promised R1.3 million. The financial director asked the obvious question: why does the cloud cost more than the data centre did?

The honest answer is that the cloud was charging Bushbuck, accurately, for the estate it had chosen to run. The rest of this part explains why.

Owned capacity is a sunk cost; metered capacity is not

An on-premises server is usually bought for peak demand plus several years of growth. Once it is bought, its unused capacity is largely a sunk cost. A server running at ten per cent costs roughly the same as one running at eighty, because the money left the building when the purchase order was signed. The incentive is to buy generously, because running short later is painful and running long costs nothing extra.

Cloud turns capacity into a continuing meter. An oversized instance running at ten per cent still generates a full charge for every hour it runs. The generous sizing that was prudent in the data centre becomes a recurring cost in the cloud, paid every hour for capacity nobody uses.

Bushbuck's average CPU utilisation across the first wave was about 9%. On-premises, that was a sign of healthy headroom. In the cloud, it meant paying for roughly ten times the compute the workloads needed, every hour of every day.

This is the first and most important shift: in a data centre, the capacity decision is made once, at purchase. In the cloud, it is made continuously, every time something runs, scales or is left on. Whoever controls those decisions controls the bill.

Four changes arrive together

The meter is the most visible change, but it is not the only one. Four things change at once, and an organisation that adapts only one of them tends to be disappointed by all four.

Capacity moves from a forecast to a dial. That is only useful if someone turns the dial: scales down at night, switches off test environments at weekends, and resizes what turned out to be oversized.

Change moves from a queue to a pipeline. If every resize still needs a change ticket and a fortnight's wait, nobody will bother, and the oversized server stays oversized.

Ownership moves from a single infrastructure cost centre to the teams who build and run each service. When the whole bill lands on one IT budget line, nobody who can change a design ever sees the cost of it. Part 6 of this series is about that shift in detail.

Finance moves from an annual capital decision to a monthly operating conversation. The bill now moves with usage, design choices and, for South African organisations, the exchange rate.

The bill is shaped by more than CPU

The instinct, when a cloud bill surprises, is to look at the price of compute. At Bushbuck, compute prices were not the problem. When the platform lead and the financial controller broke down the R600,000 gap between bill and business case, the drivers looked like this.

• VM sizes copied like for like. The largest single driver, and the direct result of the "change as little as possible" instruction. The warehouse management system, for example, was rehosted on machines sized for its old on-premises peak, years of growth included.
• Non-production running 24/7. About 40% of Bushbuck's virtual machines were development, test or training environments. They were used for perhaps fifty hours a week and billed for 168.
• Duplicate backups. The old backup agent was still running inside the VMs, copying data to storage, while the cloud's own backup service was also protecting them. Two copies, two bills, and nobody had decided which one was authoritative.
• Log retention left at the default. Diagnostic logs were kept for two years because that was the setting someone chose during the pilot. Nobody had asked what the logs were for.
• Nightly data transfer. A reporting server still in the co-location facility pulled data from the cloud every night. Data coming into a cloud region is generally free on the major providers; data going out to the internet is charged. Bushbuck had designed a daily egress bill without noticing.
• The rand. Cloud services are priced in US dollars. Bushbuck pays in rand. When the rand weakened over the period, the bill rose with no change in usage at all.
• Public IP addresses. Most VMs had been given a public IPv4 address out of habit. AWS has charged for every public IPv4 address, attached or not, since February 2024, and the other providers price public addresses too. Small per address, but not small across a few hundred.

None of these is exotic. All of them are commercial behaviour designed into the architecture: scaling rules, data transfer, observability retention, backup copies, non-production schedules and licensing shape the bill as much as the size of the CPU. That is why cost cannot be left to finance alone, and why the earlier piece on why South African businesses are still overpaying for cloud finds the same pattern in organisation after organisation.

So why move at all?

None of this means Bushbuck should not have moved. The co-location contract was ending and the storage array was out of support. Staying where it was was not an option on the table.

It means the value of cloud has to be stated honestly. Cloud value can come from speed (new environments in minutes instead of weeks), resilience (several availability zones in one region, which a single co-location cage cannot match), managed capability (databases, analytics, identity and AI services that would take years to build), experimentation (trying an idea for a week without buying hardware for five years) and reach. Lower infrastructure cost is possible, but it is not automatic. It is earned through design and ownership, and a business case that assumes it will simply happen is a business case that will be wrong.

For South African organisations, two local factors sharpen this. First, the currency: a cost base priced in dollars and paid in rand carries exchange-rate risk that an owned server, bought once, did not. Second, the reasons for moving are often specific: load-shedding exposure in a server room, a co-location contract ending, a failing storage array, scarce infrastructure skills. Those are good reasons, and they should be written into the business case as the reasons, rather than an assumed saving that the design does nothing to produce. Where the question is which platform to choose in the first place, our series on choosing a cloud platform in South Africa starts from the workload rather than the provider.

What Bushbuck did next

Bushbuck did not panic, and it did not start a rewrite. It did three things within a month:

1. It gave every rehosted application an exit ticket, recording why it was moved as-is and when it would be reviewed. Part 2 covers this.
2. It put a name against every material line of the bill, so that the people who could change a design could see what it cost.
3. It changed the question. Instead of "why is cloud more expensive than the data centre?", the monthly review now asks "what does it cost us to ship one order line, and is that number improving?" Part 5 explains why that question is better.

Within a quarter, switching off non-production at night and at weekends, removing the duplicate backup agent and setting log retention by purpose had taken a visible slice off the bill without touching a line of application code. The larger savings needed the harder decisions that the rest of this series is about.

Common mistakes

• Writing "cloud is cheaper" into the business case as an assumption. It is cheaper only when the design and the ownership make it so; write down which changes will produce the saving.
• Copying server sizes from on-premises. Those sizes were set for a sunk-cost world with years of headroom built in. In the cloud, the headroom is billed hourly.
• Treating cost as a finance problem. Finance can see the bill but cannot change the architecture that creates it.
• Ignoring the meters that are not compute. Logs, backups, data transfer, public addresses and idle environments add up quickly and rarely appear in the original estimate.
• Forgetting the currency. A rand budget for a dollar bill needs either headroom or a hedge, and someone who watches it.

A decision you can defend

We will keep Bushbuck's wave 1 applications in the cloud rather than reconsidering the move, because the co-location exit and the unsupported storage array make returning more expensive and riskier than fixing what we carried across. We accept a bill above the business case for the next quarter while we rightsize, schedule non-production and remove duplicate backups. We will review when the first ninety-day optimisation reviews are complete, and present the result as cost per order line shipped, not as a total.

What to take from this part

Owned capacity is a sunk cost; metered capacity is billed every hour. The prudent sizing of a data centre becomes recurring waste in the cloud.

Four things change together. Capacity, change, ownership and finance all have to adapt, not just the hosting.

Architecture creates the bill. Scaling rules, transfer, retention, backups, schedules and licences matter as much as CPU price.

Cloud value is real, but lower cost is earned. State the actual reasons for moving and design for the saving you expect.

Next in the series: Lift-and-shift is a migration wave, not a destination.

How CloudNala can help

We help organisations understand why a cloud bill looks the way it does: breaking it down by driver, separating design choices from price, and turning the result into a short list of changes with named owners. Where a migration is still being planned, we help write a business case that states the real reasons for moving and the specific design and ownership changes any saving depends on.

Work with CloudNala

CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.

Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.

Request a Cloud Review or write to us at consult@cloudnala.co.za