In Saudi Arabia, a cloud migration is a compliance project before it is a technology project: regulation, not capability, decides where each workload is allowed to run. Every provider on your shortlist can technically host you, so what matters is which systems the law permits them to host, where, and in what order you move. What follows is the approach we run with clients: the rules that constrain placement, one gate that sorts every workload, three shapes that survive those constraints, a worked example, the traps, and a first move you can make now.
What Saudi rules decide where your data can live
Three layers of regulation sit between your systems and a global cloud region, each asking a different question.
The first layer is the Personal Data Protection Law. PDPL took effect 14 Sept 2023, full compliance was required by 14 Sept 2024, SDAIA is the regulator, and cross-border transfer is governed by Article 29 and SDAIA’s Transfer Regulations (updated Sept 2024) (Morgan Lewis, 2024). If a system holds personal data, pushing it to a data center outside the Kingdom is a regulated transfer needing documented justification, not a default setting.
The second layer is sector rules. SAMA keeps financial institutions on a short leash regarding where customer and payment data is processed. Health data carries its own obligations and moves through national infrastructure such as the NPHIES health information exchange. Government bodies inherit classification expectations through DGA rules. Vision 2030 programmes point the same way: local hosting is the posture regulators assume unless you argue otherwise.
The third layer is security rather than residency: the NCA’s Essential Cybersecurity Controls set the baseline an assessor will hold your environment to, wherever it sits.
None of this means “everything must stay in the Kingdom.” It means placement is now a documented decision. The market has moved to meet the rule: the hyperscalers all operate in-Kingdom regions built for exactly this, and worldwide sovereign cloud IaaS spending is forecast to reach roughly $80bn in 2026 (Gartner, 2026). You are adopting a maturing pattern, not inventing one.
The one question that sorts every workload
You do not need a sprawling classification taxonomy. You need one question, asked per workload, answered honestly: who owns the rule for this data?
- A regulator has claimed it. Banking and payments data, health records, government data. The default placement is an in-Kingdom region, and anything else needs a written exception.
- PDPL applies, no sector rule. Customer identities, national ID numbers, HR files, anything personal. Article 29 decides whether it may leave the Kingdom and under what safeguards, and where the analysis is marginal, an in-Kingdom region is cheaper than the argument.
- Nobody has claimed it. The public website, published price lists, internal tooling with no personal data. Cost and latency decide, not law.
Run honestly, it settles the region question before any vendor is invited to pitch.
flowchart TD
A(["Take one workload"]) --> B{"Has a regulator claimed this data?"}
B -->|"Yes: SAMA, health, government"| C(["In-Kingdom region only"])
B -->|"No, but it holds personal data"| D{"Article 29 allows the transfer?"}
D -->|"Yes"| E(["Global region permitted"])
D -->|"No, or unclear"| C
B -->|"No personal data"| E
Then write the answers down in one register: each system, its gate answer, the regulator if any, a named owner. In our experience that register, not the architecture diagram, is what your auditor and your next CTO will ask for first, and it is where a practical PDPL compliance programme begins: with the inventory, not the vendor meeting.
In-Kingdom, hybrid, or multi-cloud: which shape fits
Once the gate has sorted the estate, only three shapes are worth building.
- In-Kingdom cloud regions carry everything the gate sent to residency. For most Saudi organisations that is most of the estate, and that is fine: the local regions are full production regions with the real service catalogue, not a compliance fig leaf.
- Hybrid covers systems that cannot move yet, a core platform mid-modernization or a workload welded to physical hardware. Treat it as scaffolding with a demolition date written into the register, because a hybrid estate with no exit plan is a legacy estate wearing a cloud badge.
- Multi-cloud only where it buys something concrete, a regulator demanding provider independence or a capability exactly one vendor offers. It doubles the skills you must hold and the surface you must secure. Portable data formats and contractual exit rights manage lock-in better than a second cloud you half operate.
A worked example: a healthcare group sorts its systems
Say you run a healthcare group in Riyadh with a handful of clinics and about twenty systems. The numbers are made up to show the shape.
Five sail through free: the public website, the appointment marketing pages, an internal wiki, a project tracker, a rostering tool with no patient data. They stay where they run today, chosen on cost alone.
Nine hold personal data under no sector placement rule: HR, finance, the CRM with patient contact details, supplier contracts. An Article 29 analysis might clear some for a global region, but you would re-argue it system by system at every audit, so the group lands in one in-Kingdom region.
Six are claimed outright: the electronic medical records, the NPHIES integration, insurance claims and eligibility, staff health insurance data, and the pharmacy system that logs prescriptions. In-Kingdom again, with the controls documented the way a health sector assessor expects to read them.
Notice what happened to the provider question: it arrived small. For fifteen of the twenty systems the answer is “an in-Kingdom region,” a short list settled on price, managed services, and what your team already operates. The migration order fell out of the same register: one internal workload first to prove the landing zone, then the confidential nine, then the regulated six. Before signing any of it, model egress charges, dual-running, and idle test environments; a migration has the same shape as any total cost of ownership exercise for enterprise software, where the sticker is the small visible part.
Where cloud migrations go wrong in the Kingdom
- Residency mistaken for compliance. An in-Kingdom region answers where data sits, not whether PDPL’s lawfulness and consent requirements are met, and it arrives with encryption, access control, logging, and backup placement still your job to configure. Our guide to passing an assessment against the NCA’s ECC covers what assessors actually probe.
- Backups and support paths leak across the border. Production runs in Riyadh, the nightly backup lands in Frankfurt, and a vendor’s support engineers open records from another continent. Each is a cross-border transfer whether or not anyone named it. Trace the data’s whole life, not just its primary home.
- Over-classification worn as safety. Sovereign-grade controls around the marketing site cost money and slow people down for no regulatory gain. The gate only works if “no personal data” is allowed to be an answer.
- Lift-and-shift with no cost model. Cloud is a different cost shape, not a cheaper one by default. Without tagging, budgets, and a monthly review, savings that existed on paper invert in year two.
- One cutover weekend. Move everything at once and your rollback plan is optimism. When something breaks you triage twenty systems at once instead of one, in front of the business.
- No owner after go-live. A platform nobody watches drifts: permissions accrete, spend creeps, patching lags. Build in-house capability or retain a partner who actually runs it; ending at cutover is how the next incident begins.
How to start: one register, one pilot, then the order
- Build the register. Two workshops with IT, finance, and whoever owns compliance. Every system, its gate answer, its regulator, its owner. The register outlives the migration team that wrote it.
- Measure honestly. For each system, record today’s hosting cost, the regulator that touches it, and where its backups, replicas, and support access actually flow. Expect at least one surprise; that is the register paying for itself.
- Pilot one internal workload. Move something low-risk to your chosen in-Kingdom region and use it to build the landing zone: accounts, identity, network segmentation, logging, cost alerts. Prove the controls to your auditor before anything confidential follows.
- Scale in register order. Confidential systems one at a time, regulated last, and re-run the gate quarterly because classifications change when the business does.
flowchart LR A(["Build the data register"]) --> B(["Stand up the landing zone"]) B --> C(["Move one internal workload"]) C --> D(["Rehearse the controls with your auditor"]) D --> E(["Confidential first, regulated last"])
Done in that order, a migration is boring, and boring is the objective: every placement defensible, every step reversible, no late discovery that regulated data sits in the wrong hemisphere. If you want an independent pair of eyes on the register or the landing zone before committing budget, that independence is the core of our cloud and digital transformation advisory.
Pausing a cloud move until someone confirms what may legally leave the Kingdom? SDCG builds cloud strategies that start with data residency and the Saudi regulatory map, and we stay vendor-neutral across AWS, Azure, Google, and Oracle because we resell none of them and earn nothing on what you choose. Book a free 30-minute review.