Why this paper exists
Most cloud migrations do not fail in the move. They fail in the months afterwards — when costs creep, access sprawls, environments multiply, and nobody can say with confidence what is running, who can touch it, or whether it is compliant. The technology worked. The governance did not exist.
This is written for South African business and technology leaders who are past the question of whether to use the cloud and are now facing the harder questions: how to move without breaking things, how to keep the bill predictable, and how to stay in control when more than one vendor, environment, or client lives in the same estate. It is the long-form companion to our shorter overview, Moving to Azure: a practical migration guide.
The strategic case — and the honest limits
Azure earns its place when there is a real business driver: ageing on-premise hardware reaching end of life, weak or untested backups, a need for resilience and remote access, a custom application that needs somewhere proper to run, or a governance and compliance burden that manual processes can no longer carry. If none of those apply, “move to the cloud” is a slogan, not a strategy.
The honest limit is this: Azure does not make a badly-run environment well-run. It relocates it, often at higher cost, because cloud makes it trivially easy to provision resources and surprisingly easy to forget them. The value is unlocked by discipline — a migration method and a governance model — not by the platform alone.
Where your data lives: the South African regions
South Africa has a genuine advantage that businesses elsewhere on the continent do not. Microsoft has operated Azure data centres in the country since 2019, across two regions:
- South Africa North (Johannesburg) — the primary region. It carries the fuller catalogue of services and supports availability zones, which place resources in physically separate facilities within the region for higher resilience.
- South Africa West (Cape Town) — a restricted, paired region used principally for in-country disaster recovery rather than primary workload placement.
For most production workloads, South Africa North is the default and South Africa West is the DR partner. The practical consequence is that South African data can stay in South Africa, which materially simplifies the POPIA conversation. A note of precision worth keeping: not every Azure service is available in every region, so the target architecture should confirm service availability in South Africa North early, and plan a fallback (usually a European region) for any service that is not yet local.
The migration methodology: Microsoft’s Cloud Adoption Framework
Serious migrations follow a method rather than improvising server by server. Microsoft’s Cloud Adoption Framework (CAF) provides one, and its sequence is worth internalising: prepare the organisation, plan and discover the estate, build a secure foundation (the landing zone), then migrate and modernise. The order matters — the foundation comes before the workloads.
Choosing a strategy per workload
Each workload gets a deliberate migration strategy. Microsoft frames these as a set of “R” options. In practice, most workloads take one of the first two:
- Rehost (“lift and shift”) — move as-is to Azure virtual machines. Fastest and lowest risk; the common starting point.
- Replatform (“lift, adjust, and shift”) — make small changes to adopt a managed service, such as moving a database to Azure SQL, without rewriting the application.
- Refactor / Rearchitect / Rebuild — progressively deeper change, justified only when the workload’s value warrants the investment.
- Replace — retire the workload in favour of a SaaS product.
- Retire — switch off what is no longer used (migrations routinely surface forgotten servers).
- Retain — deliberately keep a workload on-premise for now, managed centrally.
Microsoft’s own guidance is refreshingly blunt about sequence: for most workloads, rehost or replatform first, get it running in Azure, and modernise afterwards. Trying to redesign everything mid-move is how timelines and budgets break.
Discovery before decisions
Good migrations are built on evidence, not memory. Azure Migrate discovers your servers using a lightweight appliance, captures real performance data (CPU, memory, disk, throughput), and — crucially — maps dependencies between systems. That dependency map is where the hidden risk lives: the scheduled job nobody documented, the integration that quietly keeps finance running, the database two other systems depend on. Surface those before cutover, not during it.
Governance: the part that actually pays off
This is the heart of the paper and the part most migrations skip. Governance is what separates a controlled platform from a sprawling, expensive mess — and it is the discipline a multi-vendor, multi-client, or multi-environment estate cannot survive without. Azure provides real constructs for it.
Landing zones
A landing zone is a pre-built, repeatable foundation — identity, networking, security, and governance configured to a known-good standard — so that every new workload lands in a controlled environment instead of a blank, unmanaged subscription. Building the landing zone first is the single highest-leverage decision in a migration. Retrofitting structure onto a sprawling estate later costs many times more.
Management groups
Management groups sit above subscriptions in a hierarchy, letting you apply policy and access consistently across many subscriptions at once. For a business running separate environments (development, test, production) or separate clients, this is how you keep them organised and differentiated without managing each by hand.
Azure Policy: automated guardrails
Azure Policy enforces organisational standards automatically. It can require that resources are deployed only to approved regions (keeping data in South Africa), that every resource carries a cost-centre tag, or that a security baseline is met — and it can auto-remediate drift when something falls out of line. This replaces the slow, manual change-review process with rules that simply hold. Guardrails, not gates.
Least-privilege access and just-in-time elevation
Role-based access control (RBAC) grants people only the permissions their role needs. Paired with just-in-time privileged access — where elevated rights are granted temporarily, only when required, and reviewed regularly — it dramatically shrinks the standing attack surface. In a multi-vendor estate, where several parties touch the environment, this is not optional hygiene; it is the difference between accountable access and an open door.
Multi-vendor governance
The hardest environments are not single-tenant ones. They are estates where multiple vendors, internal teams, and clients share infrastructure — each with different needs, risk profiles, and compliance obligations. Azure supports this through archetype-based management-group structures, per-environment policy, and clear RBAC boundaries, so a regulated client and an internal sandbox can coexist under one governed roof without contaminating each other. Designing that structure deliberately is the work that protects everyone in it. It is the capability we consider our most defensible — see Azure migration and governance.
Controlling cost: FinOps from day one
Cloud cost is not a bill you receive; it is a discipline you practise. The levers are real and significant, but only if someone pulls them deliberately.
- Reservations and savings plans. Committing to one or three years of compute can reduce cost substantially — Microsoft cites savings of up to around 72% versus pay-as-you-go — for steady, predictable workloads. The trade-off is commitment, so reserve the stable core and keep variable workloads flexible.
- Azure Hybrid Benefit. If you already own Windows Server or SQL Server licences with Software Assurance, you can apply them to Azure rather than paying for the licence twice. For licence-heavy workloads this is one of the largest available savings.
- Rightsizing, tagging, and budgets. The ongoing FinOps work: match resource sizes to real usage, tag every resource to an owner or cost centre so spend is attributable, and set budgets with alerts that fire before the month runs away.
A South African pitfall deserves a flag: outbound data transfer (egress) is billed, and the rates for our region are not the cheapest globally. A chatty cross-region integration or a poorly placed backup target can quietly accumulate real cost. Architecture and region choice are cost decisions, not just technical ones.
POPIA and the shared-responsibility line
Azure supports POPIA compliance and offers in-country data residency, but it is important to be precise about what that means. Residency answers where data sits. Compliance answers how you govern it — who can access it, how long you keep it, how it is secured, and how you would prove all of that. Microsoft provides the infrastructure, the local regions, and contractual safeguards. Your business remains the responsible party for configuration and governance.
This is exactly where governance and compliance meet: Azure Policy keeping data in approved South African regions, RBAC controlling who can reach it, tagging and logging making retention and access auditable. Compliance is not a document you write at the end. It is an outcome of how the environment is built.
A practical migration playbook
Pulling it together, a sound Azure migration runs roughly as follows:
- Discover and assess. Inventory every workload and map dependencies with real data. Decide a migration strategy (rehost, replatform, and so on) per workload.
- Design the landing zone. Identity, networking, security baseline, management-group structure, policy, and cost guardrails — before any workload moves.
- Estimate cost honestly. Base the estimate on real workload data, then model the savings levers (reservations, Hybrid Benefit) and the egress exposure.
- Migrate in controlled phases. Pilot the riskiest or most representative workload first. Keep a tested rollback for each phase.
- Operate and optimise. Once stable, modernise where it pays, review cost monthly against budgets, and keep governance current as the estate grows.
How Rizonetech approaches this
We treat Azure migration as a governance project that happens to move some servers, not a server move that happens to need governance. The work starts with a readiness review — a plain-language picture of workloads, dependencies, risks, cost assumptions, and migration sequence — and the landing zone and guardrails go in before the estate grows. This is founder-led, hands-on work: the architecture, the security boundaries, and the governance model are designed by the person accountable for them, not handed down a chain.
If a custom application is part of the picture, its design and the Azure architecture should be planned together — see our guide to custom Laravel development. And if Microsoft identity and licensing are in scope, the Microsoft 365 guide covers the identity side that Azure governance builds on.
The next step
If you are weighing a move to Azure, or you are already there and the environment has outgrown its governance, start with a readiness review rather than a migration quote. It gives you a factual base for every decision that follows — and it is the point at which we can tell you honestly whether the move is worth it, and whether we are the right partner to do it with.
Published 16 June 2026. Last updated 16 June 2026.