Strategy and classification
Which classes of data may live where, which options in the table above are open to each, and what that means for the shape of the estate. The output is a decision per class, with the policy it came from cited.
The cloud practice
Cloud services in Saudi Arabia
Most cloud programmes are described as a migration and are actually four things: a decision about where each class of data may live, a foundation to land workloads on, the move itself, and the years of operating what moved. This page is the practice around all four; the move has a page of its own.
In short
The cloud practice, and where the migration page ends
Interkey provides cloud services to organisations in Saudi Arabia across the whole of a cloud programme: the strategy that decides where classes of data may live, the landing zone and guardrails that workloads land on, the operation of the estate once it is there, and the cost discipline that keeps it affordable in year three. The work is delivered from Riyadh, and it is indifferent to provider: the classification decides the target, not a preference.
One part of that programme has its own page and is not repeated here. Deciding what to do with each application — leave it, retire it, rehost, replatform or rewrite — and then executing the move is cloud migration. Running containers once there is the container platform. This page is about everything a migration needs to already exist, and everything it leaves behind to be operated.
The reason to separate them is that the migration is the visible project and the foundation is the invisible one, and programmes budget for the visible one. A migration onto a landing zone that was improvised for the first workload is rebuilt within two years, and the rebuild is done live.
The options here
Where a workload can run from Saudi Arabia, and what decides it
The set of options is larger in this market than the usual cloud conversation assumes, and every row is the right answer for some class of data. Which classes is the first question of the engagement, and it is answered by your classification policy rather than by Interkey.
| Option | What it is | What decides it |
|---|---|---|
| Hyperscaler region inside the Kingdom | A global provider’s services, delivered from infrastructure located in Saudi Arabia | The default for workloads whose data must stay in-Kingdom but may sit with a global operator. Which providers currently operate such regions changes, and the list is checked at scoping rather than published here. |
| Hyperscaler region abroad | The same services from a region outside Saudi Arabia | Only for data classes your policy allows to leave. Often the widest service catalogue; never the answer for the classes it is not allowed for, however convenient. |
| Local provider | A Saudi-operated cloud, typically narrower in services and closer in accountability | Workloads where the operator’s jurisdiction matters as much as the data’s location, and where the service catalogue needed is modest. |
| Private, on infrastructure you operate | Your own data centre or colocation, run with cloud operating discipline | The classes that may not leave systems you control. Cloud-style automation still applies, and the container platform is usually how it arrives. |
| Hybrid | Several of the above, deliberately, with the boundaries designed | Most real estates. The work is the boundaries: identity across them, network between them, and one operating model rather than one per location. |
The order
Foundations before workloads
The landing zone is the part no business sponsor asks for and every migration needs. Each step below is only safe once the one before it holds.
-
Classify
Every class of data mapped to where it may live, from your policy. Until this exists, no architecture decision is safe, and the migration page says the same thing for the same reason.
-
Identity
One identity model across every location in the estate, with roles that map to real teams and no shared administrative credential. The control that every later control depends on.
-
Network and boundaries
Connectivity between locations, segmentation inside them, and the paths data may and may not take. Designed once, before the first workload, because retrofitting it means re-addressing what already moved.
-
Guardrails
Policy as configuration: what may be created where, by whom, with which tags, at what cost ceiling. Enforced by the platform rather than by review, so a mistake is refused rather than discovered.
-
Land workloads
Now the migration has somewhere to go. Each workload arrives into an account structure, an identity model and a network that already exist, which is the difference between a move and an improvisation.
Year three
The bill is an architecture outcome
Cost control that starts after the move is a rescue, not a discipline
Cloud cost surprises are rarely caused by price. They are caused by architecture decisions taken without a cost dimension: an environment nobody switched off, storage that was never tiered, data crossing a boundary that charges for it, and capacity sized for the launch and never revisited. Each is reasonable on the day and expensive by year three.
The practice treats cost as a design input and an operating metric. At design time, every workload carries an estimate and a tag that says who owns the bill. In operation, the estate is reviewed on a cadence against those tags, with the questions that actually save money: what is running that nobody uses, what is sized for a peak that never came, and what is crossing a boundary that could be avoided. This is ordinary operations work, and it is one of the reasons the managed service exists.
Scope
How the work is usually shaped
Four shapes. The first two happen before any migration; the last two happen after it, and are the ones most programmes forget to fund.
Landing zone and guardrails
The account structure, identity, network and policy that workloads land on, built as code so it can be rebuilt, reviewed and extended to a second location without a second design.
Cloud operations
The estate operated after the move: patching, capacity, identity hygiene, guardrail changes through a change process, and the monthly account of what changed and what it cost.
Cost and architecture review
A periodic review of an estate that already exists, against the questions in the cost note above. Frequently bought alone by organisations whose migration finished and whose bill did not.
The Saudi layer
What is specific to this market
Three things shape cloud work here rather than merely translating it.
The option set is genuinely different. An organisation elsewhere chooses between providers; an organisation here chooses between locations first and providers second, and the in-Kingdom option set has changed materially in recent years and keeps changing. A strategy written two years ago is worth re-reading against what is now available.
Residency is answered per data class, not per organisation. The most common design error is a single estate-wide answer — everything in-Kingdom, or everything abroad — when the policy actually gives different answers for different classes and the estate should reflect that. The hybrid row in the table above is where most organisations truly are.
Operating capability is the scarce resource. The foundation can be built as a project. Keeping identity clean, guardrails current and the bill under review for years is a capability, and the programmes that end up with an unmanaged estate are the ones that assumed a team they never hired. Being explicit about who operates the estate after the move is part of the strategy, not an afterthought to it.
Definition of done
What a finished foundation looks like
Each of these is either true or not, and each can be checked by someone who was not involved:
- Every class of data has a written answer to where it may live, and the answer cites the policy it came from
- One identity model spans every location in the estate, with no shared administrative credential anywhere
- The landing zone is defined as code, and a second copy of it could be built from the repository without asking anyone
- A workload that breaks a guardrail is refused by the platform, not caught by a reviewer
- Every running resource carries a tag that says who owns its cost, and the monthly bill can be read by owner
- The boundaries of the hybrid estate are drawn, and the paths data may take across them are the only paths that exist
- The estate has a named operator, whether that is your team or Interkey’s, and an upgrade and review cadence with dates on it
Questions
Questions buyers actually ask
Common question
Which cloud provider do you recommend?
None, before the classification is done, and the answer is often more than one afterwards. The provider follows from where each class of data may live and which services the workloads need; a recommendation made before those two facts are known is a preference. Interkey works across providers and in-Kingdom options, and the strategy engagement exists precisely to make that decision from your policy rather than from anyone’s catalogue.
Common question
We already migrated. Is there anything here for us?
Usually the two shapes most programmes skipped: an architecture and cost review of the estate as it now is, and an operating model for it. Estates that migrated onto a foundation improvised for the first workload tend to show it in their bill and in their identity model, and both can be fixed in place without moving anything again.
Common question
How is this different from the cloud migration page?
That page is about the move: one decision per application and the sequence that executes it. This page is about what the move needs to already exist — the classification, the landing zone, the guardrails — and what it leaves behind to be operated. A programme needs both, and they are estimated and staffed differently, which is why they are two pages rather than one long one.
Common question
Can part of the estate stay on our own infrastructure?
Yes, and for some data classes it must. The private row in the options table is a first-class option rather than a concession, and the work is applying cloud operating discipline to it — automation, identity, guardrails — so the estate has one operating model rather than a modern half and a legacy half. The container platform is usually how that discipline arrives on-premise.
Common question
Who operates it afterwards?
Whoever the strategy names, and naming them is part of the strategy. If it is your team, the landing zone is built so they can operate it and the handover includes the runbooks. If it is Interkey, the managed service takes the estate on an agreed scope. What is not acceptable is the third answer, which is that nobody decided.
From the insights library
The neighbouring decisions
Practice
Cloud migration
The move itself: one decision per application, including leave-it-alone, and the sequence that gets the estate there.
TechnologyDocker and Kubernetes
The container platform that lands on the foundation, and the managed-versus-self-managed decision residency usually settles.
GuideObservability data residency in Saudi Arabia
The same classification question, asked of the telemetry the estate produces rather than of the workloads.
Explore related solutions
Next step
Start with where the data may live
Describe the estate, the classes of data in it, and whether there is a classification policy today. The strategy conversation starts there, before any provider is named.
Or directly
+966-11-2180999 info@interkey.com.saTawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia