Azure Saudi Arabia East Migration Checklist

01

What Microsoft has actually confirmed, and what it has not

The public facts are deliberately limited: Microsoft has announced customer workload availability from Q4 2026, three availability zones, and an Eastern Province location. The exact opening date remains unannounced.

Microsoft has not published a complete day-one service list. Until it does, any plan that assumes a particular SKU, zone capability, quota, or managed service will be available is carrying an explicit dependency. Record that dependency instead of turning it into a promise.

02

Why service availability is the first thing to check, not the last

A region is not a single capability. A workload depends on specific services, tiers, features, quotas, zones, integrations, and support boundaries. “Azure is available” does not answer whether the exact combination in your architecture is available.

Start with the services the estate actually uses. For each one, capture the SKU, regional dependency, zone requirement, integration points, quota, and an acceptable fallback. Mark it as confirmed, unavailable, or unconfirmed against Microsoft’s current published material. Do not fill an unknown cell with optimism.

03

Map dependencies before you split an estate across regions

Most migrations are phased. That means part of the estate may run in Saudi Arabia while identity, data, integration, monitoring, or another application remains in UAE North or Europe. The temporary split can become the highest-risk architecture in the programme.

Map synchronous calls, shared databases, identity flows, private endpoints, DNS, secrets, build pipelines, observability, backup, and third-party allowlists. Then test what changes when latency, egress cost, failure domains, and data transfer paths cross a regional boundary.

04

Know where data location becomes an engineering question, and where it stops

Engineering can show what data a workload holds, where copies exist, which services process it, where backups and logs go, and which cross-border paths the design creates. That evidence gives legal counsel something concrete to assess.

Engineering cannot certify PDPL compliance or decide the legal basis for a transfer. Record the questions, the data flows, and the technical controls. Put the legal conclusion with the organisation’s counsel.

05

Evaluate reservations and Savings Plans instead of assuming they disappear

A regional move does not automatically invalidate every commitment. Applicability depends on the commitment type, scope, service, term, exchange or cancellation rules, and the target architecture.

List every active reservation and Savings Plan with its renewal date, utilisation, scope, and affected workload. Compare the cost of retaining, exchanging, resizing, allowing expiry, or changing scope. The decision should be made before the migration schedule and the renewal calendar collide.

06

Classify every resource and model the transition, not just the destination

Not every resource should migrate. Give each resource a disposition: move as-is, redesign, retire, stays put, or blocked. That classification prevents teams from paying to move unused resources and keeps genuine blockers visible.

Then model the transition cost separately from steady-state Azure spend. Include parallel running, migration delivery, retirement candidates, commitment exposure, and the target-region price difference. If Microsoft has not published regional pricing, keep the price delta as an explicit assumption. A credible model must be allowed to conclude that the move has no payback from infrastructure cost alone.

07

Choose a pilot workload that proves something useful

The smallest workload is not always the best pilot. A good pilot has a limited blast radius and a clear rollback path, but still exercises enough of the target landing zone, identity, networking, observability, and deployment process to expose real gaps.

Prefer a workload with understood ownership, moderate traffic, few unconfirmed regional dependencies, testable acceptance criteria, and a business owner willing to make decisions quickly. Document why it was chosen and what evidence counts as success.

08

What to do in the next ninety days

1. Inventory subscriptions, resources, locations, owners, and current monthly cost.
2. Give every resource a disposition: move as-is, redesign, retire, stays put, or blocked.
3. Build the dependency map and identify every cross-region path a phased move would create.
4. Check the exact services and SKUs against Microsoft’s published availability; mark unknowns explicitly.
5. Give counsel a data-flow view and a written list of questions instead of a generic compliance claim.
6. Model parallel running, migration cost, commitment exposure, and target-price uncertainty.
7. Name one pilot workload, its acceptance criteria, and its rollback position.
8. Assign an owner and review date to every open constraint.

The output is not a commitment to migrate. It is the evidence needed to decide whether, when, and how a move should happen.