Which Dynamics 365 environment tiers do you actually need?

Two come with the subscription. Microsoft's environment-planning page for finance and operations apps opens the section with a flat sentence: "The standard cloud offer includes two environments." Everything past those two is bought as an add-on, run in your own Azure subscription, or — under the newer admin plane — provisioned against capacity you already hold.

The expensive part is not the count. It is that Microsoft now documents two different environment vocabularies — the numbered tier ladder and the unified environment types — on two different sites, and a project that reads one while buying against the other buys the wrong thing.

What the standard cloud offer actually includes

From Environment planning, Microsoft's own words for each of the two:

**Tier 2: Standard Acceptance Testing** — What Microsoft says it is: "One Standard Acceptance Testing (UAT) instance is provided for the duration of the subscription." · What you get: "a non-production multiserver instance that customers can use for UAT, integration testing, and training"
**Production** — What Microsoft says it is: "One production instance is provided per tenant." · What you get: "The production multiserver instance includes disaster recovery and high availability."

Two more things on that page, both missed. Additional sandboxes are a purchase: "You can purchase additional sandbox or staging instances separately as an optional add-on." And production is not provisioned on request — it "provisions when the implementation approaches the Operate phase, after the required activities in the Microsoft Dynamics Lifecycle Services (LCS) methodology and a successful go-live assessment are completed."

What the page does not say is worth recording. It names no user-licence threshold for the two included environments. On storage it says only that "every customer receives a certain amount" and directs you to the Microsoft Dynamics 365 Licensing Guide. Partners quote a seat number for this constantly; it is not on this page, nor on the service description. Microsoft does publish the figure — on a third page. Manage sandbox environments across implementation projects states: "Microsoft provides one production environment and one sandbox environment with the purchase of 20 user licenses for finance and operations apps." Cite that page, not the environment-planning one, and not the Licensing Guide — the guide's twenty-seat rule is a purchase minimum, which is a different rule.

Two vocabularies, and mixing them is the error

The numbered ladder is defined in the service description, under Nonproduction instance, verbatim:

"Sandbox Tier 1 – Developer instance (customer-hosted)

Sandbox Tier 2 – Standard Acceptance Testing instance

Sandbox Tiers 3–5 – Add-on sandboxes"

The unified vocabulary is defined on a Power Platform page, not a Dynamics one — Unified environment types and templates, last dated 23 July 2026. Its summary table, reproduced exactly:

Unified production environment — Abbreviation: UPE · Power Platform environment type: Production · Elastic compute: Full scaling · Typical use: Live production workloads
Unified sandbox environment — Abbreviation: USE · Power Platform environment type: Sandbox · Elastic compute: Full scaling · Typical use: Testing, UAT, staging, training
Unified developer environment — Abbreviation: UDE · Power Platform environment type: Sandbox · Elastic compute: Single AOS (no scaling) · Typical use: X++ development

Three specifics that change an architecture decision. Full scaling means "up to 80 AOS instances (40 interactive, 40 batch)" for UPE and USE; a UDE is "Limited to 1 AOS instance (no scaling)" and is "Not suitable for multi-user development or performance testing." The environment name "can't exceed 20 characters", a finance-and-operations runtime constraint. And the choice is one-way — "When you provision an environment as a unified sandbox environment (USE), you can't change it to a unified developer environment (UDE) and vice versa."

One label for the procurement conversation: the ERP templates that deploy these environments ship with `(preview)` in their display names [PP] — Finance (preview), Supply Chain Management (preview), Project Operations Integrated (preview) and Commerce (preview), the last "Available for trials only". Microsoft directs new customers to this admin plane and still labels the templates preview. Both are true; put both in the risk register rather than picking the comfortable one.

The distinction that decides where you test

Microsoft's Tier 1 versus Tier 2-and-higher comparison — Microsoft's cells verbatim, our row labels — because it is the row set that decides whether your test results mean anything:

**Topology** — Tier 1: "Single-box environment" · Tier 2 and higher: "Multi-box environment"
**Components** — Tier 1: "All components are installed on the same server. These components include Application Object Server (AOS), the database, Dynamics 365 Commerce, and Management Reporter." · Tier 2 and higher: "Components are installed on multiple servers."
**Database** — Tier 1: "Microsoft SQL Server is used." · Tier 2 and higher: "Azure SQL Database is used."
**Architecture** — Tier 1: "The architecture differs from the architecture of the production environment to maximize efficiency and cost of the development team." · Tier 2 and higher: "The architecture is the same as the architecture of the production environment, even though this type of environment has a different sizing and isn't enabled for disaster recovery."
**Deployment** — Tier 1: "The environment can be cloud-hosted, or it can be deployed as an environment image (VHD)." · Tier 2 and higher: "The environment can be deployed only as a standard environment or an add-on environment. It can't be cloud-hosted."
**Suitability** — Tier 1: "The environment isn't suitable for UAT or performance testing." · Tier 2 and higher: "The environment is suitable for UAT and performance testing."

Different database engine, different topology. A load test on a single-box environment measures a system nobody will run. Microsoft repeats it in the go-live prerequisites as an imperative — *"Don't use Tier-1 environments for UAT or performance testing."*

Access differs too. On a Tier 1, "you have full administrative access to the environment via Remote Desktop." On Tier 2 and higher, "You grant access to Azure SQL databases… via just-in-time access. Remote Desktop access isn't available."

What the SLA and the backups actually cover

Microsoft publishes a monthly availability commitment for this tier in the service description — follow the link for the rate. The scope is the part that should govern your test-window planning, and it is verbatim from environment planning:

"Microsoft promises service and data high availability as well as minimal servicing downtime

guarantees as part of the Dynamics 365 software license agreement (SLA) for production

environments. The SLA goals don't apply to non-production environments."

Backups, from the go-live FAQ, verbatim: "Full database backups are done weekly, differential database backups are done hourly, and transaction log backups are done every five minutes. Automatic backups are retained for 28 days." The service description gives the sandbox side: "For sandbox (Tier 2+) environments, automatic backups are available for seven days."

And the answer nobody likes. To "Can I request a copy of the backup of my production database?" Microsoft answers: "No. However, you can copy your production database to your Tier 2 or higher sandbox environment." That routing is why a sandbox is an operational dependency, not a project artefact.

Environment count is now a capacity question

Under the Power Platform admin center the arithmetic changed shape. From the unified admin overview:

"You must also have at least 1 GB available of both operations and Dataverse database capacity to

provision one more environment. There are no strict limits on how many environments you can

create. Lifecycle Services is different, where each sandbox and production environment slot has a

predetermined purchase."

So "how many environments" stopped being a slot question and became a gigabyte question. Microsoft answers the overage question with a hedge worth reproducing rather than rounding off — from the storage capacity report: "Currently, exceeding storage entitlements doesn't affect the availability of the service. Data stored in the service remains durable even if you go over your storage limit." Lower in the same callout: "If your storage consumption exceeds the documented entitlements or usage limits, we may suspend use of the online service. Microsoft provides reasonable notice before suspending your online service."

Read those two sentences as one. It is a soft limit today with a contractual hard edge, and a retention strategy built on the first sentence has ignored the second.

Our baseline for a mid-size multi-plant manufacturer — ours, not Microsoft's

This table is our recommendation. Microsoft's own environment guidance on that page is published as illustrations rather than as text — a "sample overview of standard and additional environments, based on the complexity of the implementation", and a tier-sizing image captioned "The provided values are for reference only." Neither is reproduced here, because neither is quotable text. Treat the rows below as our position and price them against your own volumes.

**Production** — The offer includes one per tenant. Not a decision
**Acceptance testing** — The offer includes one. It is where UAT and performance testing are permitted to happen
**Golden configuration** — A configuration master that is not also the environment people are testing in. Cutover source
**Performance test, time-boxed** — Rented for the load-test window and returned. Microsoft's own example of an add-on is "an additional Tier-4 environment for performance testing"
**One developer environment per developer** — Microsoft's rule, not ours: "You must allocate one development environment per developer"
**A post-go-live release track** — The row every project cuts. Microsoft's instruction: "After go-live, if you plan to work on new releases, get an additional Tier-2 or higher environment to support production"

That last row is the one we would defend hardest. Microsoft ships four service updates a year — "February, April, July, October", April and October being the major waves. A project that returns every sandbox at go-live has designed its February problem in advance.

Where we would draw the line, and what to do this week

We would not buy a performance-test environment for the life of the programme. It is a time-boxed need, the add-on is bought through a CSP or Volume Licensing, and Microsoft's own warning is to "Consider the potential lead time that occurs between the time when you place the order and the time when the environment is deployed." Rent it, book it early, give it back.

And we would not let the environment plan be written by whoever holds the budget. It is an architecture artefact. Microsoft's own sequence for building one runs four steps, and the second — "Determine the activities lifecycle to determine the environments lifecycle" — is the one that gets skipped, because it asks when you can give an environment back.

Four checks, this week:

Write down which of your non-production environments is single-box and which is multi-box. Any UAT or load test scheduled on the former is scheduled on the wrong architecture.
Confirm whether your post-go-live release environment exists on the plan, or only in the assumption that a sandbox will still be there.
In the Power Platform admin center, open Licensing > Capacity add-ons > Summary, then the Finance and Operations page for the environment-level view. Microsoft's paths, exactly.
Check any seat threshold you have been quoted against Microsoft's sandbox-management article, which states the entitlement, and against the Licensing Guide, which states a separate purchase minimum. They are two different rules and quotes routinely merge them.

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/

Every optimization app you add sits on the environment plan you signed, and inherits its test capacity. Book a fifteen-minute call and we will walk your environment topology and where an optimizer lands in it — no deck. https://cognilium.ai

Which Dynamics 365 environment tiers do you actually need?