Before you move workloads to the cloud: a South African readiness checklist

The infrastructure question is largely settled. Microsoft Azure, Amazon Web Services (AWS), Google Cloud and Oracle all run cloud regions in South Africa, and Johannesburg and Cape Town are the continent's main cloud hubs. What is rarely settled is readiness: an accurate inventory, a clear Protection of Personal Information Act (POPIA) position, connectivity that will not buckle, and a budget that survives the exchange rate.

This checklist covers six areas to work through before any workload moves. Answer them honestly and you will know whether you are ready, what to fix first, and which workloads belong in the first wave.

1. Workload discovery: know what you actually run

You cannot move what you have not counted. Asset registers in most organisations drift a long way from reality: servers nobody claims, a reporting database built years ago, a file share the finance team cannot live without.

Discovery has to come from the infrastructure itself, not from memory or a spreadsheet. Run a discovery tool for at least two to four weeks so you capture month-end, payroll runs and quarterly peaks. Then sit with application owners and confirm what the tooling found.

For every workload, capture:

• What it is and who owns it. A named business owner, not just "IT".
• What it runs on. Operating system, version, central processing unit (CPU), memory, storage and actual utilisation, not provisioned size.
• How critical it is. Recovery time objective (RTO) and recovery point objective (RPO), in hours, agreed with the business.
• What data it holds. Especially personal information, financial records and anything a regulator cares about.
• Licensing. Some licences do not transfer to cloud, or cost more there. Check before you assume.
• The likely route. Rehost, replatform, refactor, replace with software as a service (SaaS), retain on-premises, or retire.

That last column matters more than people expect. A good discovery exercise usually finds workloads that should simply be switched off. Retiring them is the cheapest migration you will ever do.

2. Dependency mapping: find what breaks when you move it

Workloads rarely fail in isolation. They fail because something they quietly depended on stayed behind. The enterprise resource planning (ERP) system moves to the cloud, but the label printer in the Durban warehouse still talks to a server in the Midrand comms room, and nobody knew until dispatch stopped.

Map dependencies from network flow data, not from architecture diagrams. Diagrams show what was designed; flow logs show what actually happens. Look for:

• Application-to-database links, including shared databases used by more than one system.
• Identity dependencies, such as Active Directory, single sign-on and service accounts with hard-coded credentials.
• Integrations and batch jobs: file transfers, application programming interface (API) calls, and overnight extracts to the South African Revenue Service (SARS), banks or medical aids.
• Hard-coded addresses. Internet protocol (IP) addresses and hostnames buried in configuration files are a common cause of failed cutovers.
• Latency-sensitive pairs. Two systems that exchange thousands of small messages a second will behave very differently if one moves to Cape Town and the other stays in Johannesburg.

Group tightly coupled workloads into move groups. Everything in a move group goes together, or it does not go at all. These groups become the building blocks of your migration waves.

3. Security and residency: settle the rules before the first workload lands

The cloud provider secures the platform. You still secure everything you put on it: identities, configuration, data and access. Most cloud breaches start on the customer side of that line, usually a misconfigured storage bucket or an over-privileged account.

POPIA does not force personal information to stay in South Africa. Section 72 allows cross-border transfers on specific grounds, such as adequate protection in the receiving country or a binding agreement. Sector rules can go further. The National Data and Cloud Policy, gazetted in May 2024, requires government data relating to national security and sovereignty to stay on infrastructure inside South Africa. Banks have operated under the Prudential Authority's Directive 3 of 2018 on cloud computing and data offshoring since October 2018, and in July 2025 the Financial Sector Conduct Authority (FSCA) and the Prudential Authority issued joint best practice for the wider financial sector.

We cover classification, operator agreements and section 72 in detail in Designing a POPIA-aligned cloud strategy in 2026. For migration readiness, confirm you have:

• A data classification for every workload in scope.
• A documented lawful basis for any data leaving South Africa.
• A landing zone with identity, logging, encryption and network guardrails built before the first workload arrives.
• Multi-factor authentication (MFA) on every administrative account, with no shared admin logins.
• Centralised logging that someone actually watches.
• An incident response plan that covers cloud, including Information Regulator notification.

4. Connectivity and power: the cloud is only as good as the road to it

Moving a server to the cloud moves the risk to your network link. If the line from your office or plant goes down, a perfectly healthy cloud region is useless to your staff.

• Size the link for the migration, not just steady state. Moving tens of terabytes over a 100 megabit-per-second line takes weeks. Work out the transfer time before you commit to a cutover date, and consider offline transfer appliances for large first loads.
• Use private connectivity for anything critical. Azure ExpressRoute, AWS Direct Connect and Google Cloud Interconnect bypass the public internet. In South Africa they are usually reached through carrier-neutral data centres such as Teraco's Johannesburg campuses. AWS also runs a local zone in Johannesburg for latency-sensitive workloads in Gauteng.
• Build in two of everything at the edge. Two internet service providers (ISPs) on physically separate routes, two firewalls and a tested failover. Fibre cuts from construction and cable theft are not rare events here.
• Do not plan as if power is solved. Eskom reported 341 consecutive days without load shedding in April 2026, but its own outlook for 2026 to 2030 flags a high likelihood of shortfalls returning in 2029 and 2030, and local load reduction still cuts supply in some areas. The cloud region will stay up; your branch router and users' homes may not. Keep uninterruptible power supply (UPS) and backup power on the network equipment that connects people to the cloud.

5. Cost controls: budget in rand, watch it monthly

Cloud is not automatically cheaper. It is cheaper when you size it properly, switch things off when nobody is using them, and know who is spending what. Without that discipline, the first few invoices tend to produce a difficult conversation with the chief financial officer (CFO).

South African organisations carry one extra risk: many cloud services are priced in US dollars, so a weaker rand raises the bill even when usage stays flat. Build an exchange-rate buffer into the business case, and ask your provider or reseller whether rand billing or fixed-rate commitments are available.

Put these controls in place before the first workload goes live:

• A total cost of ownership (TCO) model that includes dual running. You will pay for old and new environments at the same time during migration.
• Right-sizing from real utilisation. A server provisioned for 32 gigabytes of memory but using 6 should not move as a 32.
• Mandatory tagging. Every resource carries a cost centre, owner and environment tag.
• Budgets and alerts per team, with alerts at 50%, 80% and 100% of monthly budget going to a named person.
• Schedules for non-production. Development and test environments that run only in working hours cost roughly a third of ones left on all week.
• Commitments only after you stabilise. Buy reserved instances and savings plans after two or three months of steady usage, not on day one.
• Watch data egress. Moving data out of the cloud, between regions or back on-premises is charged.
• A monthly cost review where finance and IT look at the same numbers. This is the core of financial operations (FinOps), and it works as a habit, not a project.

6. Migration sequencing: move in waves, easiest first

A big-bang cutover puts the whole business at risk on one weekend. Waves let you learn on low-risk systems and arrive at the critical ones with a tested process. A sequence that suits most mid-sized South African estates:

1. 1.Foundation. Landing zone, identity, networking, guardrails, logging, backup and cost controls. No workloads yet.
2. 2.Pilot. Two or three low-risk, loosely coupled workloads. The goal is to prove the runbook, not to save money.
3. 3.Early waves. Internal tools and non-customer-facing systems, grouped by move group.
4. 4.Core waves. Customer-facing and revenue-generating systems, scheduled away from month-end, year-end and peak trading such as Black Friday and December.
5. 5.Decommission. Switch off the old servers and end the contracts and licences. Until you do, you are paying twice.

Every wave passes a go/no-go gate: a tested rollback plan, business sign-off, a defined cutover window and named people on call. If any of those is missing, the wave waits.

Where to start

Most organisations can answer three or four of these six areas with confidence. The other two are where migrations stall, overspend or get rolled back.

Our Cloud & Infrastructure practice runs this readiness work as a fixed-scope engagement. The Hybrid Cloud Migration Framework starts with a six-week assessment covering workload discovery, dependency mapping and wave planning, then moves to wave-based delivery with rollback at every step. If you are not sure where you stand, the free Digital Maturity Assessment takes under ten minutes.