What it does
Every environment is bound to a geography at creation, and everything created in it — the Dataverse database, apps, flows, connections, gateways, custom connectors — is deployed into datacentres in that geography. Provisioning is moving from picking a specific datacentre region to picking a macro region geography, with the platform choosing the datacentre inside it.
Key facts
- A macro region geography is the data residency boundary. The documented set is North America; The Americas; European Union and EFTA; Europe and UK; Europe, UK, Middle East and Africa; and Asia-Pacific.
- EU and EFTA is the EUDB boundary. Europe and UK includes the UK and explicitly should not be treated as EUDB — that distinction matters and clients get it wrong.
- Within a macro region the platform picks the datacentre based on capacity, availability and performance. You see the assigned region in the environment properties after provisioning.
- To choose a specific datacentre region rather than a macro region, the tenant needs Advanced Data Residency enabled for 100% of its Microsoft 365 seats. ADR is a Microsoft 365 SKU, and enabling it for all seats is what gives you region selection for Dynamics 365 and Power Platform too.
- Macro region provisioning applies to public cloud only and is rolling out globally. As documented at the start of July 2026 it had been implemented for Canada and Norway.
- Sovereign clouds — GCC, GCC High, DoD — aren't part of the macro region model. Only a US Government associated organisation can create an environment in GCC.
- Tax rules block creating a database in India or Australia unless the Entra tenant is in India or Australia respectively. An exception is available for Australia.
- An environment can sit in a different region from the tenant. The default environment, Teams environments and sign-up-created developer environments follow the tenant home location unless the preferred environment location tenant setting is changed with PowerShell.
- Backup, restore and copy operations all require source and target in the same region. This is a hard constraint on any multi-region design.
- On-premises data gateways aren't available in the India region.
- Existing environments keep their current geo-based provisioning; Microsoft doesn't anticipate moving them.
When to use / skip
Region choice is a one-way door — there's no supported "move this environment to Europe" operation — so treat it as an architecture decision made with legal input, not an admin default. The honest advice for most multinational clients is fewer regions rather than more: every additional region fragments your ALM pipeline, because you can't copy or restore across a regional boundary. Put the environment where the regulated data must live and where the majority of users are, and accept the latency for the rest. Only split by region when a legal requirement genuinely forces it.
Configuration decisions
- Which macro region geography each environment belongs to, and whether the client's requirement is really EUDB or just "in Europe".
- Whether Advanced Data Residency is worth licensing across all Microsoft 365 seats to get country-level placement.
- The tenant's preferred environment location, which governs where Teams and self-service developer environments land.
- Whether the dev/test/production chain sits entirely within one region, given the copy and restore constraint.
- What the residency commitment actually says in the contract, versus what the platform enforces — these are different documents.
Gotchas
- "Europe and UK" is not EUDB. A client who signs off on that macro region believing they have EU Data Boundary coverage has a compliance gap.
- Copy and restore refusing to cross regions is the constraint that breaks multi-region ALM. People discover it when the target environment simply doesn't appear in the dropdown.
- The India and Australia tax restrictions apply to the tenant's home location, not to where the users are, which surprises companies headquartered elsewhere with operations there.
- The default environment lands in the tenant home region and can't be moved. If that's the wrong region for your data, the default environment is the wrong place for your data.
- Advanced Data Residency has to cover all Microsoft 365 seats in the tenant. Partial coverage doesn't qualify.
Consultant notes
- Get the residency requirement in writing from the client's legal or DPO function before you pick a region, and quote the macro region name back to them exactly. "Europe" is not a requirement, it's a shrug.
- Explain early that region is set at creation and not changeable, because the alternative conversation involves a full data migration into a new environment.
- Residency is about where data is stored. It isn't a statement about where support personnel are located or where every dependent service processes data — direct those questions to the Trust Centre and the product terms rather than answering them yourself.
- Check the current datacentre region and availability pages before committing to a region for a specific country. The macro region model is still rolling out and the picture in the portal changes.
Worth checking again as macro region provisioning rolls out beyond Canada and Norway, or if new geographies join the list.