Once an organisation accepts that in-country hosting is now technically viable, the conversation usually swings too far. Somebody proposes repatriating the estate, a migration plan appears, and the project stalls under its own weight. The useful question is narrower: which specific workloads are worse off where they currently are?

There are four, and everything else can stay put.

1. Data with an obligation attached

Personal data on Somali citizens and customers, held by an institution subject to the Data Protection Act, is the clearest case. Not because the Act mandates localisation in every circumstance — it is more nuanced than that — but because “where is it and how is it protected” is a question with a regulator behind it, and an in-country facility produces an answer you can evidence in one sentence.

The same logic applies to anything a donor agreement, a licence condition or a ministry contract specifies. Read those documents before designing anything; a surprising number contain residency language that nobody has operationalised.

2. Systems whose users are here

An application used by staff in Mogadishu, hosted in a European region, pays an intercontinental round trip on every interaction. For a page load that is tolerable. For a system somebody uses forty times a day, it is a tax on every one of those interactions, and it compounds with any application that requires several exchanges to do anything.

The sorting question is simple: where are the people who use this? If the answer is Somalia, and the system is in Frankfurt, that is a latency cost being paid daily for no benefit.

3. Content that is served repeatedly

Anything delivered many times to many local viewers — media, software updates, a public-facing portal — crosses a submarine cable once per request when it is hosted abroad. Caching or originating it in country means it crosses once. For a broadcaster or a platform with local audience, this is usually the largest single line in an international transit bill and the easiest to fix.

4. The restore point

Backup is where in-country hosting earns its place most quietly. A restore across an international link is bounded by that link’s throughput, and restoring a meaningful dataset over international capacity can take longer than the outage you are recovering from — a fact organisations typically discover during the outage.

A restore point inside the country, in a different building from production, is both faster to recover from and easier to defend as a continuity arrangement.

What should stay exactly where it is

Systems with international user bases. Platforms deeply integrated with a global cloud provider’s own services, where “moving” means rebuilding. Workloads with no residency obligation and no local audience. Anything running well, at acceptable cost, that nobody has a concrete reason to touch.

“We should host everything locally” is as unconsidered a position as “we should host everything in the cloud”. Both skip the sorting step, and the sorting step is the whole of the work.

The hybrid that usually results

Most organisations that do this properly end up with a split: regulated data and locally-used systems in country, global platforms where they are, and a deliberate connection between the two. That is not a compromise — it is the correct answer, and it is only reachable by asking the question workload by workload rather than as a policy.

The practical starting point is an inventory. What exists, where it physically sits, who uses it, and whether anything in writing constrains where it may live. Most organisations have never assembled that document, and assembling it usually settles the strategy without much further argument.