Azure Landing Zone for Saudi Arabia: What to Set Up Before Migration

01 / What you are building

What does a landing zone include?

Microsoft's Cloud Adoption Framework describes landing zones through areas such as identity, subscriptions, networking, security, management, governance, and deployment automation.

In everyday terms, the landing zone answers who can deploy, where resources go, how they connect, which controls apply, and who operates the result.

Some foundations are shared across workloads. Others belong to an individual application. A central network team may own connectivity, while the application team owns its deployment and alerts. Make those boundaries explicit.

Use the Azure landing zone guidance as a design reference. Choose the scale and structure your team can maintain.

02 / Organise the environment

Decide how subscriptions and environments are separated

Review your existing tenant and subscription structure before creating another one. A region change alone does not require a new Microsoft Entra tenant.

Consider legal separation, billing, access boundaries, ownership, and the way teams deploy. Production and development often need different permissions and policies, even when they support the same product.

Management groups can apply governance across subscriptions. Shared platform subscriptions may hold networking or operational services. Application subscriptions can provide clear ownership of workload resources and spending.

Keep the structure understandable. Every new boundary creates administration work. Document why it exists, who owns it, and how a new application gets the resources it needs.

03 / Control access

Set up access before people start deploying

List the roles involved: platform administrators, application developers, deployment pipelines, support staff, auditors, and outside suppliers. Give each the permissions needed for its work.

Separate routine work from privileged administration. Use your approved controls for administrator sign-in and elevation. Document emergency access and test the procedure under controlled conditions.

Prefer supported workload identities and managed identities where they fit, rather than creating long-lived shared credentials for every connection. Keep any required secrets in the chosen secret-management service and assign a rotation owner.

Check how access is removed when a person or supplier leaves. A migration is a good opportunity to retire old grants that nobody can explain, but make each change with the application dependencies in view.

04 / Design the connections

Plan address ranges, DNS, and private access

Reserve address ranges that do not overlap with the existing cloud networks, offices, or other sites that must connect. An overlap discovered during migration can be much harder to fix than one found on a diagram.

Choose the appropriate network pattern for the scale of the estate. A hub-and-spoke layout or a managed connectivity approach may fit, but the choice should follow routing, inspection, connectivity, and ownership requirements.

Plan private DNS and endpoint resolution explicitly. Test what an application, a build agent, and an administrator will resolve from their actual networks.

For offices and data centres, check the intended VPN or private-connectivity design and its target-region support. Include lead times for external providers where relevant.

Finally, map temporary paths to the old region. The UAE-to-Saudi migration guide explains why those paths need their own performance and data-flow checks.

05 / Set guardrails

Apply policies that support the intended design

Useful policies can cover approved resource locations, required ownership information, public-access settings, encryption choices, or other controls your organisation has agreed.

Start with the requirement behind each policy. Decide whether it should report a problem, block a deployment, or help configure the required setting. Test its effect before applying it broadly.

Location rules need care around global services and approved external dependencies. A blanket rule can block a necessary service while still failing to answer where the application's data is processed.

Document exceptions with an owner and review date. Use the PDPL and Azure guide to keep technical location controls connected to the wider data-handling requirements.

06 / Make the system operable

Decide where logs, alerts, and backups belong

Choose log destinations, retention, access, and the events worth collecting. An existing central workspace in another country is a design decision to review, not a setting to copy without checking.

Make alerts actionable. Identify the recipient, expected response time, and procedure for common failures. Test that the notification arrives and that the person receiving it has enough access to investigate.

Plan backup protection and restore destinations alongside the workload. Confirm service support and data location before choosing redundancy options. Use the backup and recovery guide for a fuller review.

Add cost ownership. Record the team responsible for the subscription, budget review, and unexplained increases. A named owner makes it easier to catch a forgotten test deployment or excessive logging.

07 / Make changes repeatable

Build the environment through reviewed deployment code

Use your chosen infrastructure-as-code tool to describe the intended resources and configuration. Keep region, naming, and environment-specific settings explicit so the target does not depend on a sequence of undocumented portal changes.

Review deployment permissions and approval steps. Test what happens when a deployment fails halfway through, and make sure the team can determine which resources exist and which changes remain.

Prepare templates and pipelines before target access is available, then validate them against the actual Saudi services and quotas when possible. Success in another region does not prove that every target SKU or feature is supported.

Keep secrets out of the deployment repository. Reference them through the approved mechanism and check that the pipeline can retrieve only what it needs.