Which Dynamics 365 regions can you actually deploy into?

Checked 31 July 2026, against a Microsoft page last dated 23 July 2026. A regional list is true on the day it is written and on no other day, so treat every count below as a reading taken on a date — and go and read the table before you commit.

Microsoft publishes the list. The part that is not on the list, and that costs money to learn late, is what the choice constrains: where you may test, where a backup may be restored, what happens when an existing environment sits in the wrong Azure region, and which of three completely different "region" questions you were actually answering.

What the list says today

The authoritative table lives on a Power Platform page, not a Dynamics one — Unified environment types and templates section Regional availability for finance and operations apps. Its columns are Location (display name), Location (code), Azure region, UPE, USE, UDE and Trial.

Read on 31 July 2026, that table carries thirty-one Azure region rows across seventeen locations. Twenty-three support unified production and unified sandbox environments. Eight do not — Microsoft marks those cells with an em dash, and explains the pattern in a Note:

"Some locations have a secondary Azure region that only supports UDE (developer) and trial

environment types. These secondary regions don't support UPE (production) or USE (sandbox)

workloads. For sovereign and government cloud availability, contact Microsoft Support."

The eight, by Microsoft's own Azure region codes, because these are the ones people pick by accident:

`australiasoutheast` — Location: Australia · Supported there: Developer and trial only
`canadaeast` — Location: Canada · Supported there: Developer and trial only
`francesouth` — Location: France · Supported there: Developer and trial only
`southindia` — Location: India · Supported there: Developer and trial only
`norwaywest` — Location: Norway · Supported there: Developer and trial only
`southafricawest` — Location: South Africa · Supported there: Developer and trial only
`switzerlandwest` — Location: Switzerland · Supported there: Developer and trial only
`ukwest` — Location: United Kingdom · Supported there: Developer and trial only

Two hedges on that page to reproduce rather than round off. The Azure region column "is a hint that you can currently use only in PowerShell to target a specific region within a location" — in the admin centre you pick a location, not an Azure region. And validation is not there yet: "Microsoft is adding validation to prevent ERP templates from being created in unsupported Azure regions… Until this validation is in place, refer to the following table to confirm your Azure region is supported before provisioning."

What the region choice actually constrains

Five constraints, each quoted from the page that states it. This is the part a reader cannot get from the list.

**Production must match your test datacentre** — What Microsoft says: "Deploy the production environment to the same datacenter where your sandbox environments are deployed, and where UAT and performance testing were done." · Where it bites: Picks your production region months before anyone thinks they are choosing it
**Backup and restore is region-bound** — What Microsoft says: "Ensure that both the source and target environments are provisioned in the same region." · Where it bites: A cross-region restore plan is not a plan
**Installing onto an existing environment can just fail** — What Microsoft says: "The selected region does not support the FnO app deployment" · Where it bites: An existing Dataverse estate in an Azure region the ERP apps don't support blocks the install outright
**Fixing it is a support ticket, not a setting** — What Microsoft says: "you can request Microsoft to move the environment to a supported region via support ticket, or provision a new unified environment in a different supported region" · Where it bites: Weeks, not minutes, and it lands on the critical path
**Latency is yours to measure** — What Microsoft says: "consider the latency from the geographic locations where the business operates. Use tools such as PsPing to test latency to Azure data centers" · Where it bites: Nobody does this until the first complaint from the furthest plant

Row by row, those come from Prepare for go-live, the backup and restore tutorial, the unified admin overview's Known limitations for rows three and four, and Environment planning for the latency row.

The first row is the one that quietly decides the answer. Microsoft's reason is not bureaucratic — using the same datacentre "help[s] ensure that you're validating latency as well as support for all services under production-like conditions", and the instruction is explicit: "Don't go live on a datacenter different from the one you tested on." Which means your production region was chosen the day someone provisioned the acceptance-testing environment, usually without a decision record.

Three questions, three different pages

Here is the confusion this article exists to remove. "Which region?" is three unrelated decisions, and answering one does not answer the others.

**Which Azure region hosts the environment?** — What it actually decides: Whether production, sandbox and developer environments can exist there at all · Where Microsoft answers it: The unified environment types table, above
**Where does customer data live at rest?** — What it actually decides: Data residency, and where Microsoft may replicate it · Where Microsoft answers it: "You can choose the macro region geography where you want your customer data to be stored" — the data residency documentation
**Which country's regulatory functionality do you get?** — What it actually decides: Tax, statutory reporting, e-invoicing behaviour · Where Microsoft answers it: "Enable this functionality based on the primary address of the active legal entity" — the globalization resources page

That third row is the one that surprises people, and it is worth stating plainly: country localization in finance and operations apps is driven by the active legal entity's primary address, not by the Azure region the environment runs in. Choosing a European region does not grant a European localization, and choosing a US region does not take one away.

The narrower question, because the general rule has documented exceptions. Localization features follow the legal entity. Data residency obligations can still drive the deployment, and Microsoft names three on the service description. Organisations "that do business with entities in France that require local data residency" are pointed to a France-specific deployment article; customers with operations in China are pointed to finance and operations "operated by 21Vianet in China"; and customers with operations in Russia are pointed to the Russian personal data localization law. If any of the three applies to you, region and country stop being independent.

The residency question has its own sharp edges on the data residency documentation last dated 7 July 2026, and two are worth carrying into a compliance conversation. Brazil: "Because there is only one region in Brazil, customer data in Brazil South may be replicated to South Central US (Texas) for disaster recovery purposes." And previews: "Preview, beta, or other pre-release services, which typically store customer data in the United States but may store it globally." If your legal team signed a residency clause and your team is piloting preview features, those two sentences are the ones to put in front of them.

The same page also names something a lot of LCS-era estates never accounted for — Lifecycle Services itself "stores certain customer data on servers located in the United States", including "Your code or metadata, and data packages", "Business process models and task guides", diagnostic logs, and support request content.

Where we would draw the line, and what to do

We would not let the region be a side effect of provisioning the first sandbox. It is a compliance decision, a latency decision and a go-live constraint, and Microsoft's own instruction to keep production in the test datacentre makes it expensive to revisit — a move is a support ticket, not a setting. Thirty minutes of decision record at the start beats that ticket later.

And we would not accept "we're in Europe" as an answer. The macro region geography, the Azure region and the legal entity's localization are three different fields with three different owners. Ask which one the person means.

Four checks:

Write down the Azure region code of every existing environment. If any is one of the eight above, that environment can host a developer or trial workload and nothing else.
Confirm your production region equals your UAT region. If it does not, that gap is a go-live conversation, not a post-go-live one.
Confirm your data residency commitment against the macro region geography you actually selected, not against the Azure region name you remember.
Confirm which legal entities need which country functionality, and check that against the primary address on each — not against where the environment is hosted.

About Cognilium Cognilium is the AI optimization layer for Dynamics 365 — complementary apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Built on Power Platform, Dataverse and Azure. https://cognilium.ai · https://www.linkedin.com/company/37180269/

An optimization app inherits the region, the residency boundary and the latency of the environment it sits beside. Book a fifteen-minute call and we will walk your regional constraints and where an optimizer lands against them — no deck. https://cognilium.ai

Which Dynamics 365 regions can you actually deploy into?