Somewhere in your commercial contracts there is probably a sentence naming where your customers’ data is held. Most of the time nobody reads it. It gets read when a regulated buyer sends a security questionnaire, when a regulator asks a direct question, or when someone in your own company finally checks — and the answer turns out to be a region a developer picked from a dropdown years ago.
What happens next is the part I am asked to cost, usually in a hurry. And the answer is almost never the one people expect, because moving a running system from one cloud region to another is not a setting you change. It is a migration. It has a bill, a downtime window, a testing programme and a set of conversations with people outside your company.
I wrote separately about where Gulf businesses should host and why. This is the companion piece: what it costs when the answer you already have is wrong.
It is worth remembering how young this problem is in the Gulf. The first hyperscaler region in the Middle East opened in Bahrain in 2019. Any system built here before then was hosted in Europe or the United States by necessity rather than by choice — and a good number of them are still there, running happily, until the day somebody asks where the data is.
Four bills nobody budgets for
When a migration gets estimated internally, the estimate usually covers engineering time. That is the smallest of the four costs, and the only one the engineering team can see from where they sit.
Three of the four land on people who were never in the room when the region was chosen: the finance director who sees the transfer charges, the commercial lead who has to agree the outage, and whoever owns the customer relationships that name a hosting location in writing.
Egress: the bill that grows while you wait
Cloud providers charge little or nothing to put data in and a metered rate to take it out. That asymmetry is not a trick; it is the pricing model, and it is public. AWS, for example, gives every account 100 GB of free data transfer out per month, aggregated across services and regions, and meters what you send beyond it.
For an application serving pages, 100 GB is generous. For a migration it is nothing. You are not sending a month of traffic — you are sending everything you have ever stored, once, in a compressed period of time, and often twice if you rehearse the move before you commit to it.
The number that matters is therefore not a rate. It is your total stored volume, and it only goes one way. A database that grows by a modest amount each month has quietly been increasing the cost of a decision you have not made yet. Put your actual figures into the provider’s pricing calculator before you accept anybody’s estimate, including mine — the answer is specific to your data, not to your industry.
The cutover window is a commercial decision
Every migration plan contains a moment where the old system stops accepting writes and the new one starts. You can make that moment short with replication and a rehearsed cutover, but you cannot make it zero without building for it in advance, and building for it in advance costs more than most systems are worth.
The question that decides the plan is not technical. It is: how long can this business be unable to take an order, issue an invoice or answer a customer? An hour on a Friday night is a different project from four hours at month end, and both are different from a bank that has told its regulator when its systems are available.
Get that answer in writing from whoever owns the revenue, before the architecture is designed. I have watched teams engineer a fifteen-minute cutover that nobody needed, and I have watched a four-hour window get agreed in a meeting and then discovered to be commercially impossible three days before the date.
What a region move actually touches
Servers move easily. It is everything attached to them that produces the surprises, and the surprises cluster in four places.
The second card is the one that changes plans. Cloud regions are not interchangeable: providers ship a core set of services with every new region and add the rest over time, which is why the published services-by-region list exists at all. A newer region may simply not carry something you depend on. That is not a blocker you discover during a cutover; it is one you discover during planning, if you plan.
It is also worth checking that the region you are moving to exists rather than has been announced. The official region list distinguishes launched regions from announced ones, and architecture decisions should be made against what exists today.
The third card is the one that runs on somebody else’s calendar. If a bank, a payment gateway or a government portal has your current IP addresses in an allow-list, your migration date depends on their change process. Start those requests before you book anything.
The arithmetic of deciding early
Here is the part I would put on a wall. The requirement — host this data in a particular country, or be able to prove where it is — does not change over time. Only the cost of satisfying it changes, and it changes by an order of magnitude at two specific moments: when you launch, and when you sign a customer who cares.
This is why I keep pushing the residency question to the front of engagements rather than treating it as a compliance review at the end. It is the same instinct that makes a published regulatory deadline useful: a date you can see is a date you can build against, and it is much cheaper to build against it than to react to it.
What I would do this week
- Write down where your data physically is. Not the provider — the region. If nobody can answer in ten minutes, that is the finding.
- Read what you have already promised. Search your contracts, privacy notice and completed security questionnaires for a location. People are usually surprised by at least one of the three.
- Measure the volume. Total stored data, today, in gigabytes. That single number sets the floor on what a move costs and it grows while you postpone.
- Ask the revenue owner for a window. How long can we be down, on which day, at what notice. Get it before you need it.
- List who holds your IP addresses. Every external party with a firewall rule pointing at you is a dependency on their change process.
None of that is a project. It is an afternoon, and it converts a vague anxiety into a number you can act on — or ignore deliberately, which is a legitimate choice once you know the size of it. Where it turns into a project, it usually belongs inside the wider systems-and-data work rather than being run as an emergency of its own.
If you want a second opinion on an estimate you have been given, or you are choosing a region now and would rather get it right while it is still free, tell me what you are running. Some of this is the sort of decision nobody in the room is quite qualified to make, which is usually why it gets deferred until it is expensive.
Dates move. I keep a tracker of every dated compliance obligation across the GCC, each one checked against the regulator’s own source.
Frequently asked questions
Can we just run in both regions and switch over gradually?
Sometimes, and it is the gentlest path when it works. It requires your data layer to support replication across regions, and it means paying for both environments during the overlap plus the transfer between them. It also does not remove the moment where writes have to stop in one place and start in the other — it shortens it. Treat it as a way to buy a smaller downtime window, not a way to avoid one.
Is a CDN or edge caching enough to satisfy a residency requirement?
No, and this is a common misunderstanding. A content delivery network changes where copies of your content are served from; it does not change where your database of record lives. Residency rules are generally written about the data, not the delivery. Ask the question about the system of record and answer it there.
How long does a region migration take in practice?
For a straightforward application with one database and a handful of integrations, planning and rehearsal are measured in weeks and the cutover in hours. The number moves with the count of external dependencies, not with the size of the servers. Every integration with a party outside your company adds calendar time you do not control.
Our provider says the move is easy. Are they wrong?
They are usually right about their own layer and silent about yours. Lifting compute and storage between regions is well-trodden. The cost sits in re-testing your integrations, the outage your business has to absorb and the notice your contracts require — none of which is your provider’s to estimate. Ask them, in writing, what their estimate excludes.
We are pre-launch. How much should we care about this?
More than feels proportionate, because it is the only moment the decision is free. Ask which regulators could plausibly claim your data in three years, whether you intend to sell to government or financial customers, and whether the region you are choosing carries the services you will need. An hour now, or a project later.