Choose the workload before the cloud: a South African decision framework

Cloud selection usually starts in the wrong place. A steering committee asks which cloud the organisation should standardise on. Teams pull up provider catalogues, request infrastructure quotes, compare market positions and argue about which logo is safest. Months later there is a decision, and it is only loosely connected to any system that actually has to run.

The trouble is the question. "Which cloud?" has no good answer on its own, because the right home for a payroll integration, a customer-facing app, a factory control system and a regulated policy database are rarely the same. Ask the question at the level of the whole organisation and you get a preference. Ask it about a specific workload and you can get evidence.

This series is about making that decision well in South Africa, where local regions exist but do not settle the architecture, where the bill is often priced in dollars and paid in rand, and where power and connectivity are design inputs rather than footnotes. Over six parts it covers when Azure, AWS, Google Cloud, Huawei Cloud, Oracle Cloud, South African providers, on-premises and hybrid each deserve to win, and when they only look as if they should. This first part sets out the method the rest of the series uses.

The running example

Every part follows the same organisation. Mopane Group is fictional, and its workloads and figures are illustrative.

Mopane is a diversified South African group with a head office in Sandton and about 4,500 staff. Mopane Retail runs around 180 stores, a loyalty app and an e-commerce site. Mopane Manufacturing runs a packaging plant in Ekurhuleni, where a manufacturing execution system (MES) and line controllers must keep working through WAN outages and load-shedding. Mopane Financial Services is a small regulated insurance and credit arm with its own policy administration system. Group functions run on Microsoft 365 and Entra ID, finance runs Oracle E-Business Suite on Oracle Database in an ageing Midrand data centre whose hardware is due for refresh in 18 months, and payroll is a software-as-a-service product.

Group IT has a platform team of eight, strongest in Microsoft technologies; a retail digital team of twelve engineers who build the loyalty app and are already productive on AWS in Cape Town, thanks to an earlier startup acquisition; and a four-person data team that would like to use BigQuery for retail analytics.

The board has asked a reasonable question: which cloud should Mopane be on? The rest of this part explains why the honest answer is "for which workload?"

The unit of decision is a workload

A workload is a bounded business capability with users, information, dependencies, service levels, owners and costs. Mopane's loyalty app is one. So is its policy administration system, and so is the plant's MES. Each has its own answers to the questions that actually decide where it should run:

• Who uses it, from where, and how badly does it hurt when it is slow or down?
• What information does it hold, and which laws, regulators and contracts apply to that information?
• What does it depend on, and what depends on it?
• How fast must it recover, and how much data can it afford to lose?
• Who builds it, who runs it, and what are they good at?
• What will it cost over its whole life, not in month one?

A payroll platform, a public web application, a contact-centre assistant, a core banking integration and a mine-site control system can all legitimately land on different platforms inside one organisation. That is not fragmentation. It is the result of taking each workload's constraints seriously. Fragmentation is what happens when nobody decides deliberately.

What South Africa changes

Local hyperscale regions reduce latency and make some data-location patterns easier. At the time of writing (October 2026), Microsoft runs South Africa North in Johannesburg with three availability zones, while South Africa West in Cape Town has no availability zones and restricted access. AWS runs Africa (Cape Town), af-south-1, with three availability zones; it is an opt-in region that has to be enabled per account, and it is AWS's only Region in the country. Google Cloud runs africa-south1 in Johannesburg with three zones. Huawei Cloud and Oracle each run a Johannesburg region, covered in Part 4.

Those facts prove that infrastructure exists here. They do not prove that a specific database tier, AI model, security feature, backup target or management plane operates entirely inside the country. A service can be sold locally while its control plane, telemetry, support access, failover copy or model inference runs somewhere else. Trace the data path; do not infer it from the region name on the invoice. (For AI models in particular, see our earlier guide to what "available in South Africa" really means.)

Generic global scorecards also miss several factors that weigh heavily here:

• Currency exposure. Many cloud inputs are priced in US dollars even when invoicing is local. A three-year estimate needs a rand sensitivity range, not one spot conversion.
• Connectivity. Latency to a region is one link in a chain that also includes branch networks, mobile users, internet breakouts, private circuits, DNS, identity and third-party APIs.
• Power and network interruption. A local region cannot keep a store or a plant working when its last-mile link and backup power fail. The application needs an explicit degraded mode.
• Skills. A technically elegant platform becomes expensive when every change needs a scarce specialist or an external partner.
• Recovery geography. A second availability zone protects against some failures inside a region. It is not a second South African region, and cross-region recovery can raise cross-border data and latency questions.
• Regulation and contracts. POPIA governs transfers of personal information abroad through the conditions in section 72; it does not impose a blanket rule that all personal information must stay in South Africa (our plain-language explainer covers this). Banks, insurers and other regulated entities must also consider sector guidance, outsourcing requirements and supervisory expectations. This is a question for your legal and compliance advisers, not your architects alone.

Hard gates before weighted scores

The most common tool in cloud selection is a weighted spreadsheet: list the criteria, assign weights, score each provider, add it up. The problem is that a weighted total can hide a fatal defect. A provider can score beautifully on price, innovation and partner ecosystem and still fail the one jurisdiction, feature or recovery requirement the workload cannot compromise. The arithmetic averages the failure away.

So start with five hard gates, and only score the options that pass all of them:

1. Is the design lawful and acceptable to the relevant regulator, customer and contract?
2. Does the exact required service run in the required location, with the required features?
3. Can the design meet latency, bandwidth and dependency requirements, in normal operation and in failure?
4. Can it meet recovery objectives without moving protected data somewhere unacceptable?
5. Can the organisation operate, secure and pay for it for several years?

In practice these break into six stages, each with the evidence it needs:

Each gate gets one of three answers: Pass, Fail or Unknown. The rule that matters most is the simplest: an unknown is not a pass. It is a piece of work someone has to do before the option can stay in the running.

Here is how Mopane's policy administration workload fared. Oracle's cloud failed the service gate because the policy administration vendor does not support it. The on-premises option failed resilience, because the Midrand data centre has no credible recovery site. Google Cloud failed the operating gate: nobody in Financial Services can run it, and the regulator would expect the team to. AWS passed the early gates but is unknown on operating capability and lifecycle cost for this division, and Huawei Cloud is unknown on most of the first three. Azure passed everything, and it is the only option that goes straight to scoring. The others stay in only if someone produces the evidence.

Then score what survives

Once the gates have done their work, score the surviving options from 1 to 5 on dimensions weighted for this workload, and attach evidence to every score. A reasonable default:

The weights are not universal. A regulated core platform might raise resilience, control and exit. A startup product might raise time-to-value and managed-service fit. Weighting is a business decision, not an architect's private formula, so agree the weights before anyone scores a provider, or the weights will quietly bend to fit the favourite.

The workbook below puts both steps together. Mark each gate, then adjust the weights and scores for the options that survive.

The bill procurement cannot see

The cheapest month-one estimate is frequently the most expensive operating model. A comparison is only fair when every candidate is costed against the same demand, resilience and support assumptions, and when the model includes more than virtual machines:

• compute, storage, databases and managed services;
• licences, reservations, savings commitments and minimum spends;
• internet egress, inter-region traffic, private connectivity and network appliances;
• backup, immutable recovery copies, logging, security and observability;
• premium support and partner-managed operations;
• migration, data transfer, refactoring and parallel running;
• FinOps, platform engineering and training;
• currency movement, growth, seasonality and idle capacity;
• exit testing, data extraction and decommissioning.

For Mopane, the line that changed the conversation was currency. A three-year model run at three rand-dollar scenarios showed that the cheapest option at today's rate was not the cheapest at the weakest plausible rate, because more of its cost was dollar-denominated managed services. Neither option was wrong. The board simply made the decision knowing the range, instead of discovering it later. Our cloud cost audit checklist covers the operating side once the platform is chosen.

One group, several homes

Run every workload through the same method and the answer to the board's question becomes clearer, and less tidy than they hoped.

Azure becomes Mopane's primary enterprise platform, because identity, collaboration and most internal applications already live in Microsoft's world. But the loyalty app stays on AWS, where the team that builds it is already productive. Retail analytics may go to Google Cloud, if an evidence spike shows BigQuery earns its place. The Oracle estate is a decision of its own, driven by licensing and recovery. And the plant's control systems stay on site, because they must keep running when the WAN does not. Parts 2 to 5 make each of those calls in detail, and Part 6 asks whether the result is a sensible multicloud estate or an accident.

Common mistakes

• Choosing a cloud for the organisation before defining any workload. The decision has nothing concrete to be tested against.
• Letting a weighted total outvote a failed gate. A high score on price does not make an unlawful data flow acceptable.
• Treating "Unknown" as a provisional pass. Unknowns tend to stay unknown until they become incidents.
• Assuming a local region means local everything. Control planes, support access and failover copies may sit elsewhere.
• Costing month one in today's rand. Currency, growth and exit costs arrive later and all at once.
• Setting weights after seeing the scores. The weights then measure the team's preference, not the workload's needs.

A decision you can defend

Every assessment should end in one paragraph that someone outside the project can challenge:

We choose [platform] for [workload] because [specific platform advantages] satisfy [hard constraints] and improve [measured outcomes]. The main risks are [named risks]. We will control them through [controls]. We will reconsider the decision when [triggers].

For Mopane's policy administration system it reads:

We choose Azure for policy administration because the vendor supports it, it passes every hard gate including recovery within our four-hour RTO, and it reuses the Entra identity and Microsoft security tooling our Financial Services team already operates. The main risks are dependence on restricted access to South Africa West for regional recovery, and dollar-priced database costs. We will control them through a tested backup-and-restore path that does not rely on that access, and a quarterly rand cost review. We will reconsider the decision when the vendor certifies another platform, regional recovery options change, or costs exceed the agreed range for two consecutive quarters.

If a team cannot complete that paragraph with evidence, it has not made an architecture decision. It has expressed a preference.

What to take from this part

Decide per workload, not per organisation. "Which cloud?" only has an answer once you say for what.

Gates first, scores second. A weighted total must never outvote a failed gate.

An unknown is not a pass. It is work someone has to do.

Cost the life, not the month. Include currency ranges, operations and exit.

Finish with a decision statement. If you cannot write it with evidence, you have a preference, not a decision.

Next in the series: When Azure is the right answer, and when it is only the familiar one.

How CloudNala can help

We run cloud platform decisions workload by workload: defining the workload properly, working through the hard gates with the people who hold the evidence, building a like-for-like lifecycle cost model with rand sensitivity, and ending with a decision statement your board, auditors and engineers can all read. Where the honest answer is "more than one platform", we help you decide which differences are worth keeping.

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