In many South African organisations, Azure is the answer before anyone has asked the question. The staff sign in with Microsoft accounts, the email and documents live in Microsoft 365, the finance team has an enterprise agreement, and the IT team's certifications are mostly Microsoft ones. Choosing Azure feels less like a decision than a continuation.
Often that instinct is right. The value Azure offers these organisations is real, and it is not the logo. It is the work that disappears when identity, security, data, development and operations already share one set of concepts. But the same instinct can also stop a comparison before it starts, and carry a workload onto Azure that would be better, cheaper or simpler somewhere else.
This part is about telling the two apart. Mopane Group is fictional, and its workloads and figures are illustrative. Mopane, the South African group we follow through this series, runs Microsoft 365 and Entra ID across all its divisions, has a platform team of eight whose strongest skills are Microsoft ones, and wants to know which workloads belong on Azure.
Where Azure's advantage actually comes from
Azure's case is strongest when the organisation already runs on Microsoft concepts: Entra ID identities, Active Directory, Windows Server, SQL Server, .NET, Microsoft 365, Power Platform, Fabric, Defender or a Microsoft enterprise agreement. The benefit is reduced friction at the joins:
- Identity. Users, groups, conditional access and privileged roles are already defined. A new Azure workload inherits them instead of building a parallel identity model.
- Security operations. If Defender and Sentinel are already the security team's tools, Azure workloads arrive with signals the team already reads.
- Data. Information that already lives in SharePoint, Teams, Dynamics 365 or Fabric is closer, in both network and governance terms.
- Development. Teams using Azure DevOps or GitHub with existing landing zones, policy-as-code and pipelines can ship to Azure without inventing a new delivery path.
- Licensing. Existing Windows Server and SQL Server licences with Software Assurance can reduce Azure compute costs through Azure Hybrid Benefit, which only matters if the workload genuinely needs those products.
- Hybrid governance. Azure Arc can bring servers and Kubernetes clusters outside Azure under the same policy, inventory and monitoring.
Azure deserves a leading score when several of these are true at once. One on its own is rarely enough.
Mopane's Azure workloads
Two of Mopane's workloads pass that test comfortably.
The group intranet and internal line-of-business apps (leave requests, procurement approvals, store-operations dashboards) are built largely in Power Platform, use Entra identities and draw on SharePoint and Microsoft 365 data. Placing their back ends and integration services anywhere other than Azure would mean re-plumbing identity and data access for no gain. This is Microsoft gravity doing honest work.
Policy administration for Mopane Financial Services is the more demanding case. In Part 1 it was the only option to pass every hard gate. The vendor supports Azure; the Financial Services team already operates Entra, Defender and SQL Server; and the regulator's expectations around outsourcing, access control and evidence map cleanly onto controls the team already runs. Azure wins here not because Mopane is a Microsoft shop, but because every specific requirement points the same way.
Notice what is not on the list. The loyalty app is built by a team that ships reliably on AWS. Retail analytics wants a service Azure does not offer in the same form. Those are decided in Part 3, and Microsoft gravity does not get a vote.
Azure Local: Azure where the cloud cannot be the only runtime
Some workloads cannot depend entirely on a public cloud region: a factory line, a mine site, a hospital or a retail distribution centre that must keep running when the WAN is down. For these, Microsoft offers Azure Local, formerly Azure Stack HCI, which runs on customer-owned hardware at the customer's site and uses Azure Arc as its control plane. Microsoft positions it for latency-sensitive and mission-critical processing, local AI inference, regulatory requirements, and operations that must continue through network interruption. At the time of writing (October 2026), its disconnected operations mode is generally available, so a site can keep running local workloads with no connection to Azure at all.
That makes it relevant wherever public cloud is part of the platform but cannot be the only place the workload runs. It is also a distributed infrastructure platform with real hardware, licensing and operational costs. Mopane's plant team evaluates it in Part 5 against a simpler alternative, and the comparison is closer than the brochure suggests.
The South African caveat: zones are not a second region
At the time of writing (October 2026), Azure's South Africa North region in Johannesburg has three availability zones, and South Africa West in Cape Town has none and is restricted: access is granted on request for specific scenarios such as disaster recovery. Our Azure in South Africa guide covers the service-by-service gaps between the two regions, so this part sticks to the design consequence.
Availability zones protect against a data-centre-scale failure inside a region. They do not protect against losing the region. That leaves three honest options for regional recovery, and each needs to be written down with its own recovery time and data-loss figures:
- The restricted local region, if your workload is eligible and access has been granted. Confirm that every service the recovery depends on is actually available there, because zone and service support differ between the two regions.
- Backups restored to another location, which is slower but does not depend on restricted access.
- An approved region outside South Africa, which raises latency, data-transfer cost and legal questions. POPIA allows cross-border transfer under the conditions in section 72, and sector rules may add more. That is a question for your legal and compliance advisers.
A design document that says "paired regions in South Africa" without saying which of these it means, and how it was tested, is incomplete. For Mopane's policy administration system, the decision statement in Part 1 deliberately relies on a tested backup-and-restore path rather than assuming access to South Africa West. If access is granted later, it becomes a faster option, not the only one.
Zone support is also service-specific. A database tier, a gateway SKU or a managed service may support zone redundancy in one region and not in another, or only in a premium tier. Check each service the workload depends on, not the region as a whole.
AI makes the caveat sharper
AI services add another layer. A model can appear in a catalogue while its deployment options, capacity, data-processing location or feature set in South Africa differ from what the catalogue implies. Some deployment types process prompts in a wider geography than the resource's own region. Check the specific model, version and deployment type, and where the inference actually happens, before a design depends on it. The same applies to analytics services and anything in preview. Our reference on AI model availability in South Africa goes through what "available" really means.
When Azure should not win
Microsoft gravity becomes a problem when it ends the comparison rather than informing it. Azure should not win automatically when:
- the workload's defining capability is demonstrably better on another provider;
- the engineering team that owns the workload is productive and well governed on another platform;
- migrating would preserve Microsoft licensing but increase application or operating complexity;
- a required service is not available locally and the cross-border alternative fails a hard gate;
- Azure Local would add an expensive distributed platform where ordinary server virtualisation meets the requirement.
There are also reasons that only look like reasons: the licences are already owned, it is the familiar logo, a partner prefers it, or the service appears in a catalogue somewhere. None of them answers the question that matters.
The test is marginal value. Ask what Azure makes simpler, safer, faster or cheaper for this particular workload, then measure it. For Mopane's intranet the answer is concrete: no new identity model, no new data integration, no new delivery path. For the loyalty app the honest answer is "nothing the team needs", and moving it would cost a quarter of engineering time to arrive where it already is.
A sensible default, held loosely
Choose Azure as the default enterprise platform when Microsoft integration is a real dependency and the organisation can establish a governed landing zone, clear cost ownership and repeatable delivery. Then allow a workload to go elsewhere when its advantage survives a like-for-like comparison and the organisation can support the resulting operating model.
That is Mopane's position. Azure is the paved road: new internal workloads land there by default, with the platform team's guardrails already in place. Exceptions are allowed, but they must pass the same gates and produce the same decision statement. "We prefer it" is not an exception. "The team ships twice as fast there, and here is the evidence" can be.
Common mistakes
- Treating owned licences as a platform decision. Licences reduce one cost line; they do not make the workload fit.
- Writing "paired regions in South Africa" into a design. South Africa West is restricted; say which recovery option you mean and test it.
- Assuming zone redundancy is a region-wide feature. It varies by service and tier.
- Assuming an AI model in the catalogue runs locally. Check the deployment type and processing location.
- Moving a productive team's workload to Azure for consistency. Consistency is worth something, but rarely a quarter of engineering time.
- Reaching for Azure Local when plain virtualisation would do. The edge platform has to earn its operating cost.
A decision you can defend
We choose Azure for Mopane's intranet and internal applications because they already depend on Entra ID, Microsoft 365 data and Power Platform, and placing their back ends on Azure removes identity and data integration work entirely. The main risks are cost growth from unmanaged Power Platform and Azure consumption, and concentration of internal workloads on one provider. We will control them through landing-zone policy, tagging and a monthly cost review owned by the platform team, and by keeping data exports and infrastructure definitions current. We will reconsider when an internal workload's needs diverge from the Microsoft estate, or when costs exceed the agreed range.
What to take from this part
Azure's advantage is integration, not the badge. It is strongest when identity, data and tooling already share Microsoft concepts.
Ask about marginal value. What does Azure make simpler, safer, faster or cheaper for this workload?
Zones are not a region. South Africa West is restricted, so write down your regional recovery option and test it.
Check AI and preview services individually. Catalogue presence is not local processing.
Make Azure the paved road, not the only road. Exceptions pass the same gates.
Next in the series: When AWS or Google Cloud should lead.
How CloudNala can help
We help organisations test whether Azure's advantage is real for a given workload, design landing zones that make it the easy path when it is, and write recovery designs that are honest about South Africa West. Where another platform is the better fit, we say so, and help you decide whether the exception is worth its operating cost.
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