Cloud Migration Strategy for South African Enterprises

Cloud migration programmes are usually scoped as an inventory exercise. Someone produces a spreadsheet of workloads, assigns each one a disposition, and the programme is measured by how many rows have moved. Two years later the organisation is running two operating models instead of one, the monthly cloud invoice is larger than the data centre it replaced, and the promised improvement in delivery speed has not materialised.

The programmes that work are sequenced differently. They treat the migration as a platform build with workloads as its first customers, and they resist moving anything of consequence until the platform can support it safely.

The landing zone is the first deliverable

A landing zone is the set of foundational decisions every subsequent workload inherits: account and subscription topology, network design and connectivity back to on-premise systems, identity federation, encryption and key management, logging and retention, tagging for cost allocation, and the guardrails that prevent a well-meaning engineer from exposing a storage bucket.

Building this properly takes six to ten weeks on either Google Cloud or Microsoft Azure. Retrofitting it after thirty workloads have landed takes considerably longer and requires touching all thirty. The temptation to start with a visible workload migration is understandable, because a landing zone produces no demonstration. It is still the wrong order.

Two decisions inside the landing zone are worth extra deliberation because they are expensive to reverse. The first is the account or subscription boundary, which determines how cleanly you can delegate autonomy to product teams while retaining central control of spend and security posture. The second is the network topology and how private connectivity to remaining on-premise systems is terminated, because this shapes latency for every hybrid integration you will build for the next several years.

Data residency and regulatory posture

Both Google Cloud and Microsoft Azure operate South African regions, which has removed most of the residency friction that earlier programmes had to engineer around. The caveat is that regional service coverage is not uniform. Before committing an architecture, confirm availability in the specific region for every managed service in the design, including the less obvious ones: managed streaming, specific database engine versions, accelerator families, and any AI service you intend to call.

Where a required service is unavailable locally, you have three honest options: change the design to use a service that is available, accept cross-region processing with a documented lawful basis and the latency it implies, or defer the workload. What you should not do is leave the gap undiscovered until integration testing.

For regulated workloads, treat the Protection of Personal Information Act and any sector-specific requirements as design inputs rather than as an approval gate at the end. In practice this means classifying data at the point of ingestion, deciding on a per-class basis where processing may occur, and encoding those rules as policy in the landing zone so that they are enforced rather than merely documented.

Choose a disposition per workload, deliberately

The standard dispositions remain useful, provided each is chosen for a reason rather than by default.

• Rehost suits workloads with a defined end of life, or where the business case is exiting a data centre lease rather than improving the application. Rehosting a workload you intend to keep for a decade simply relocates its problems.
• Replatform, typically moving to managed databases, container platforms, and managed messaging, is where most of the durable operational benefit sits. It reduces the surface area your teams must patch and operate without requiring an application rewrite.
• Refactor is justified where the application is a genuine differentiator and its current architecture is the constraint on delivery speed. It is the most expensive disposition and should be reserved for a small number of systems.
• Replace with a software-as-a-service product is often the right answer for commodity capability, and is frequently under-considered because it sits outside the migration team's remit.
• Retain and retire deserve as much analysis as the others. Every workload that can be decommissioned instead of migrated is the cheapest possible outcome, and inventories reliably contain more of these than anyone expects.

Cost control is an architectural property

Cloud spend that surprises an organisation is almost always the result of decisions made during migration rather than of provider pricing. Three habits prevent most of it.

First, allocate every rand from day one. Tagging conventions enforced by policy in the landing zone, with dashboards that attribute spend to a named owner, turn cost from a central finance problem into an engineering signal. Teams that can see their own consumption manage it.

Second, size for the workload rather than for the incumbent hardware. Lifting a virtual machine specification that was procured for a five-year refresh cycle into an environment billed by the hour guarantees over-provisioning. Right-sizing after migration is possible but rarely prioritised once the workload is stable.

Third, separate steady-state capacity from bursts. Reserved or committed-use pricing for the predictable baseline, combined with on-demand or spot capacity for peaks such as model training and batch processing, typically reduces compute spend materially without any change to the application.

Modernise the operating model, or keep the old costs

The technical migration is the smaller half of the programme. If change control, release approval, environment provisioning, and incident response continue to work as they did in the data centre, the organisation will have purchased elasticity it cannot use. Platform engineering practices matter here: self-service environment provisioning within guardrails, infrastructure defined as code and reviewed like application code, deployment pipelines owned by the teams that write the software, and observability that makes production behaviour legible without a ticket.

Define the target operating model alongside the landing zone and migrate a small number of teams onto it before scaling. The measure of a successful migration is not how many workloads moved. It is whether the organisation can now change its systems faster and more safely than it could before, at a cost it can explain.