"Cloud first" is one of the most useful and most misread phrases in technology strategy. Read properly, it means that cloud is considered first for every new workload, and that keeping something on premises needs a reason. Read badly, it means that every workload must leave the building, and that anyone arguing otherwise is resisting change.
The bad reading produces bad outcomes. Factory systems are moved into a region they cannot reach during a fibre cut. Stable, fully utilised server estates are migrated at a cost the business never recovers. And the people who knew the local platform best are sidelined just when their knowledge is needed most.
The opposite failure is just as real. "We keep it on premises" can be a decision nobody has examined in years, defended by a cost comparison that leaves out half the costs. This part sets out when local is genuinely the right answer, what it really costs, and how to keep the decision honest over time.
Mopane Group is fictional, and its workloads and figures are illustrative. Mopane is the South African group we have followed through this series. Its packaging plant in Ekurhuleni runs a manufacturing execution system (MES) and machine-line controllers on shift work that has to continue through WAN outages and load-shedding. The plant has generators. Its network to the outside world is less dependable than its power.
Five defensible reasons to stay local
There are five reasons that hold up under scrutiny. A workload can have more than one.
- Disconnected operation. The process must continue when the wide-area network is unavailable. A packaging line that stops every time the plant's fibre is cut is not a cloud success story.
- Deterministic latency. Control systems, imaging, trading or equipment interactions cannot tolerate the measured network path, including its worst moments, not just its average.
- Physical adjacency. Data volume, devices or machinery make local processing necessary. High-resolution camera feeds from a production line are cheaper to process beside the line than to ship to a region and back.
- A control requirement. Law, contract, sovereignty or a proven threat model requires controls that are not available in an acceptable public-cloud design. "Proven" matters here: the requirement should be written down and attributable, not inferred.
- Economic fit. Stable, high utilisation and a mature operations team can produce a lower lifecycle cost locally, once resilience, hardware refresh, facilities, security and staffing are all included.
Legacy compatibility can also justify keeping something local for now. An old application that cannot run elsewhere without a rewrite is a real constraint. But it should have an owner and a review date. "The application is old" is an explanation, not a permanent strategy.
Two reasons are notably absent from the list. "The hardware is not yet depreciated" is a sunk cost, not a reason; it matters for timing, not for direction. And "cloud looked expensive on the first quote" is usually a sign that the quote was for the wrong design. Neither should decide where a workload lives.
On-premises is a service, not a room
The most common error in on-premises versus cloud comparisons is comparing a cloud bill with the price of servers. A reliable local platform is a service, and every part of that service costs money whether or not anyone writes it down:
- capacity management and hardware lifecycle, including the refresh every five to seven years;
- patching, vulnerability management and identity integration;
- backup, immutable recovery copies and tested disaster recovery;
- monitoring and on-call support;
- facilities: power, generators, fuel, cooling, physical security and insurance;
- spares and vendor support contracts;
- the people who do all of this, and the cost of replacing them when they leave.
If those costs are omitted, the comparison is false in favour of on-premises. If the cloud side omits migration, re-engineering, egress, premium support and the new skills required, it is false in the other direction. The rule from Part 1 applies: compare like with like, using the same demand, resilience and support assumptions for every option.
Private cloud is more than virtualisation
The term "private cloud" is used loosely. A rack of virtualised servers managed through a ticket queue is not a private cloud. It is virtual hosting.
Private cloud adds self-service, standardisation, automation and policy to dedicated infrastructure: a team requests an environment through an interface or an API, it arrives configured to standard in minutes, and its cost is attributed to them. The distinction matters because a slow ticket queue on expensive hardware delivers neither the speed of cloud nor the simple economics of plain hosting. If an organisation is going to keep a material estate local, the question is whether it will invest in the automation that makes it behave like a platform, or accept that it is hosting and price it accordingly.
Public-cloud technology on premises
The hyperscalers and Oracle all now offer ways to run their technology in your building. Azure Local extends Azure infrastructure and management into customer-owned locations, using Azure Arc as its control plane. AWS Outposts brings managed AWS infrastructure and APIs on site, connected to a parent AWS region through a service link. Google Distributed Cloud includes an air-gapped option for regulated and sovereign workloads. Oracle Cloud@Customer places Oracle cloud and database services in a customer data centre.
They solve different problems, and they have different connectivity, hardware, scale, support and pricing models. They are not interchangeable, and none of them is a casual branch-office solution. Before shortlisting any of them, ask four questions.
- What keeps working when the public-cloud region or the WAN is unreachable? The answers differ sharply. At the time of writing (October 2026), Azure Local supports disconnected operations as a generally available capability, while AWS Outposts is designed to stay connected to its parent region through a service link and depends on it for management and some operations. Get the answer for the specific product and configuration in writing.
- Which control plane, identity, licence and telemetry dependencies remain external? A local runtime with a remote control plane is a hybrid system, and its failure modes are hybrid failure modes.
- What is the smallest supported footprint, and what does it cost at realistic utilisation? Minimum configurations can be substantial. Google, for example, states that an air-gapped Google Distributed Cloud production system can run on as few as four racks, and publishes evaluation pricing starting at USD 300,000 a month. That is the right scale for a sovereign national platform and the wrong one for a plant that needs six servers. Outposts also comes in rack and server form factors that support different services, so check the list for the Cape Town region against what the workload needs.
- Who replaces failed hardware, and who owns the incident end to end? In South Africa, the answer to "how quickly can a part get to Ekurhuleni" is as important as the answer to "what is the SLA".
Mopane's plant: an honest decision
Mopane's platform team, strongest in Microsoft technology, initially assumed Azure Local was the natural answer for the plant. It would give them Azure-style management of the plant's servers, central governance through Azure Arc and a single operating model with the rest of the group.
The four questions changed the conclusion. The plant's estate is small and stable: six servers running the MES, a historian database and the line controllers' supervisory software, with little change from year to year. The MES vendor supports its product on ordinary virtualisation and has not certified it on anything else. The plant's priority is that the lines keep running through a fibre cut, which the existing local virtualisation platform already does. And the team's honest assessment was that Azure Local would add a distributed platform to learn and support at a site where nobody on the platform team is based.
So the plant stays on a refreshed local virtualisation platform, with two changes that address the real risks. Plant servers are now enrolled in Azure Arc for inventory, patch compliance and security monitoring, which gives central visibility without making the plant depend on a cloud control plane to run. And production data flows from the historian to the group's cloud analytics platform on a schedule, with a local buffer, so that analytics benefit from the plant's data while the plant never depends on the cloud to produce.
That is a hybrid design with one clear boundary. Part 6 returns to what makes a boundary like that worth its cost.
For a different workload the answer would differ. A regulated database with a hard locality requirement might be exactly what Cloud@Customer is for. A mine or factory that needs local Kubernetes, frequent application change and central governance might genuinely benefit from Azure Local or a comparable edge platform. The requirement chooses the technology.
Keep the decision reversible
An on-premises decision should not be permanent by default. Write down the triggers that reopen it:
- hardware refresh is due;
- vendor support for the hardware or software ends;
- utilisation changes materially, up or down;
- a suitable managed service launches in a South African region;
- connectivity to the site improves, for example with a diverse second fibre route;
- regulation or a customer contract changes;
- the operating team can no longer sustain the platform, whether through attrition or growth.
Mopane's plant decision is recorded with a review date in three years, aligned to the next hardware cycle, and a named owner in the manufacturing division.
Common mistakes
- Reading "cloud first" as "cloud only". It produces migrations that cost more and work worse than what they replaced.
- Comparing a cloud bill with server prices. On-premises costs include facilities, staff, recovery and refresh.
- Calling virtual hosting a private cloud. Without self-service and automation it has neither cloud speed nor hosting economics.
- Buying an on-premises cloud appliance for a small, stable estate. The minimum footprint and operating model may exceed the problem.
- Keeping legacy systems local with no review date. Temporary becomes permanent by default.
- Assuming a local runtime means local independence. Check which control plane, identity and licence dependencies remain external.
A decision you can defend
We keep the plant MES and line-control supervisory systems on a refreshed local virtualisation platform because the lines must keep running through WAN outages, the estate is small and stable, and the MES vendor supports this platform. The main risks are local operational knowledge concentrated in two people, hardware failure response times, and drift from group security standards. We will control them through Azure Arc enrolment for patch and security visibility, a support contract with defined parts response times, and documented runbooks. We will reconsider at the next hardware refresh, if the MES vendor certifies another platform, or if the plant gains a second diverse fibre route.
What to take from this part
Cloud first means cloud considered first. Keeping a workload local needs a reason, and five reasons hold up.
On-premises is a service. Price facilities, people, recovery and refresh, or the comparison is false.
Ask four questions of any cloud appliance. What works disconnected, what stays external, the minimum footprint, and who fixes the hardware.
Every local decision needs a review trigger. Otherwise it quietly becomes permanent.
Next in the series: Hybrid and multicloud without architecture theatre.
How CloudNala can help
We help organisations test on-premises and private-cloud decisions honestly: building a like-for-like lifecycle cost model, checking which of the five reasons actually applies, and evaluating edge and on-premises cloud options against the specific site, connectivity and support realities, including the cases where the simplest local platform is the right answer.
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.
Book a Cloud Platform Decision Review or write to us at consult@cloudnala.co.za