For most of the past decade, running software in Africa meant running it somewhere else — usually Europe, sometimes North America. That is changing. Colocation capacity has grown substantially in several markets, and the large cloud providers have established regions on the continent.
The technical case
Latency is the obvious one, and it matters most for chatty applications that make many sequential round trips. It matters less than people assume for a well-built web application that batches its requests, which is why the latency argument alone rarely justifies a migration.
The stronger technical argument is about the path rather than the distance: infrastructure hosted locally and peered at a local exchange keeps traffic off long international routes that are more expensive and more prone to congestion.
The legal case is often the deciding one
A growing number of national data protection regimes restrict the transfer of personal data abroad, and some sectors — financial services and health data in particular — face residency requirements that are stricter still. For a company subject to those rules, where the data sits stops being an optimisation and becomes a condition of operating.
This is worth establishing before the architecture sets rather than after. Moving a database across a border is a project; choosing which side of it to start on is a decision.
What to weigh honestly
Local capacity is not automatically cheaper, and the managed service catalogue available in a local region is usually narrower than in a mature one. A team that depends on a long list of managed services may find the migration costs more engineering time than the move saves. The realistic answer for many companies is a split: regulated data local, everything else wherever it runs best.
