Cloud Migration in Saudi Arabia: A Strategy Guide for Enterprises

Cloud migration in Saudi Arabia is the planned move of applications, data and infrastructure from on-premise servers to cloud platforms in a way that satisfies Saudi data-residency rules, the Personal Data Protection Law (PDPL) and National Cybersecurity Authority (NCA) controls. A sound strategy classifies data first, selects in-Kingdom regions, builds a secure landing zone, then migrates in controlled waves.

It is one of the highest-stakes infrastructure decisions a Saudi enterprise will make. The difference between a well-executed migration and a poorly planned one is measured in operational continuity, security posture and long-term total cost, not just the initial project budget. Frameworks written for Western markets need real adaptation for the Kingdom's regulatory landscape, its data-classification rules and the fact that in-Kingdom hyperscale capacity is still maturing. This guide sets out what is different in KSA, how to choose where each workload lives, and the sequence that keeps a migration on time and compliant.

What makes cloud migration in Saudi Arabia different?

Three regulatory layers shape every migration decision in the Kingdom, and they overlap.

Personal data: the PDPL

The PDPL was issued by Royal Decree M/19 on 16 September 2021, amended in March 2023, and came into force on 14 September 2023, with a one-year grace period that ended on 14 September 2024. It is supervised by the Saudi Data and Artificial Intelligence Authority (SDAIA), which publishes the law, its implementing regulations and the breach-notification service on the National Data Governance Platform. Transfers of personal data outside the Kingdom are governed by a dedicated transfer regulation, so any workload that processes customer or employee data needs a documented view of where that data is stored, replicated and backed up. Our PDPL compliance guide covers these obligations in detail.

Cybersecurity: NCA ECC and CCC

The NCA's Essential Cybersecurity Controls (ECC-2:2024) include a dedicated subdomain, 4-2 Cloud Computing and Hosting Cybersecurity, which is binding on in-scope entities that use or plan to use cloud services. It requires your data to be protected according to its classification, returned in a usable format when a service ends, and separated from other tenants' environments. The NCA's Cloud Cybersecurity Controls (CCC-2:2024) go further for cloud service providers and for government and Critical National Infrastructure tenants. Notably, CCC-2:2024 moved data-localisation controls out of the document to the National Data Management Office (NDMO) at SDAIA, so localisation questions now go to SDAIA before any action is taken. For the full control set, see our NCA ECC guide.

Provider registration: CST classes

The Communications, Space and Technology Commission (CST) registers cloud service providers in classes that define which data they may host. Class A covers government public data; Class B adds government confidential data; Class C covers all government data levels up to top secret. Private-sector workloads can use any registered class, but government and semi-government work must match the provider's class to the data's classification.

Which cloud regions are available inside the Kingdom?

In-Kingdom hyperscale capacity has grown quickly, but availability differs by provider and by service. Always check the live service list for the specific region before you design around it.

Where a service is not yet available in-Kingdom, the decision is not automatically "wait". It depends on the data classification of that workload and on what SDAIA and your sector regulator permit. Our article on cloud computing and data residency in Saudi Arabia explains how to map that.

Should you choose public cloud, private cloud or hybrid?

For most Saudi enterprises the honest answer is hybrid. Platform selection depends on workload classification, regulatory requirements and the tooling the organisation already runs. Forcing everything into one model usually means either over-spending on private infrastructure or taking compliance risk in public cloud.

How do you build a cloud migration strategy, step by step?

1. Inventory and classify. List every application, its data, its dependencies and its owner. Classify data under your organisation's policy and the NDMO classification levels.
2. Decide a path per application. Use the "6 Rs" below. Not every system should move, and some should be retired.
3. Build the landing zone first. Establish networking (virtual private clouds, segmentation), identity and access management with multi-factor authentication, centralised logging and monitoring, and policy guardrails aligned to NCA ECC before any workload arrives.
4. Run a pilot wave. Start with non-critical workloads so teams build cloud operating capability before business-critical systems depend on it.
5. Migrate in waves with rollback. Group applications by dependency. Keep a tested rollback path for every wave to limit the operational impact of surprises.
6. Cut over and decommission. Switch traffic, verify, then actually switch off the old servers. Dual running is one of the largest hidden costs.
7. Optimise continuously. Right-size instances, use reservations where demand is steady, and review cost and security posture monthly.

The 6 Rs of migration

Why is DevOps a migration requirement, not an afterthought?

DevOps infrastructure, meaning CI/CD pipelines, infrastructure as code and automated testing, should be built as part of the migration, not after it. Organisations that move workloads without these practices end up with cloud estates that are harder to operate reliably than the data centre they left. Infrastructure as code also gives auditors something concrete: every network rule, encryption setting and access policy is versioned and reviewable, which makes demonstrating NCA alignment far easier than screenshots of a console. The migration is the moment to establish the operational foundation cloud needs to deliver its full value.

What drives the cost of a cloud migration?

Costs vary widely with estate size and the mix of strategies, so treat any single figure with caution. The main drivers are predictable:

• Refactoring effort: the more applications you re-architect, the higher the upfront cost and the larger the long-term benefit.
• Dual running: paying for old and new environments at once. Short, disciplined cut-overs keep this down.
• Licensing: some enterprise licences can be brought to cloud, others cannot; check before you choose instance types.
• Data transfer and storage tiers: egress charges and backup retention add up quietly.
• Skills and operations: training, managed services and monitoring tooling.

Savings come from consolidation, automation and decommissioning, not from cloud alone. In our published cloud migration and stack consolidation case study, a hybrid AWS architecture with unified identity, centralised monitoring, automated DevOps and NCA-aligned controls delivered a 40% reduction in infrastructure overhead and a centralised security posture with continuous NCA compliance monitoring.

What are the most common cloud migration mistakes?

• Migrating before classifying data, then discovering a workload cannot legally sit where it was moved.
• Skipping the landing zone and bolting on identity, logging and network controls later.
• Assuming every service is available in an in-Kingdom region.
• Leaving disaster recovery until after go-live. Plan it as part of the target architecture, as described in our disaster recovery planning guide.
• Never decommissioning the old environment, so costs rise instead of fall.

What should you do next?

Start with an inventory and a data-classification exercise; it costs little and answers most placement questions. Then design the landing zone against NCA ECC and your sector rules before moving anything. Amwaj Solutions designs and executes cloud migration programmes for Saudi enterprises, building PDPL compliance, NCA alignment and DevOps automation into the plan from day one, with security architecture delivered through our cybersecurity and compliance service.