Dynamics 365 Finance environments and Lifecycle Services

Environments in Dynamics 365 Finance and Supply Chain Management (collectively, the Finance and Operations apps) are more involved than in Business Central. They're sized as named tiers, provisioned through Lifecycle Services (LCS), and operated under a mixed responsibility model that customers and partners both need to understand.

Environment tiers

Sandboxes are sized by tier, where the tier indicates infrastructure scale rather than just function:

• Tier 1 — a single-box development environment running on one Azure VM. Suitable for code work, not for realistic data volumes or concurrent users.
• Tier 2 — a multi-box, high-availability sandbox close to production scale, used for UAT, load testing, and golden-config builds. Every Finance/SCM project gets at least one Tier 2.
• Tier 3, 4, 5 — progressively larger sandboxes for very large customers.
• Production — Microsoft-managed, high-availability, with a defined SLA.

A typical mid-size project runs one production, two Tier 2 sandboxes (UAT plus a golden-configuration build), and a handful of Tier 1 dev boxes — one per developer, since Tier 1 machines don't share well. Large programmes add a dedicated Tier 2+ for performance testing with production-scale data. The tier decision is hard to reverse cheaply, so size the topology during contracting, not after: it appears on the licence bill.

Provisioning

Tier 1 sandboxes can be self-deployed from LCS in hours. Tier 2+ sandboxes and production are provisioned by Microsoft as part of FastTrack onboarding, with paperwork and lead times.

Lifecycle Services (LCS)

LCS is the cloud portal where customers and partners manage F&O implementations — project workspaces, environment requests, deployment of code packages, application of platform updates, support ticket management, the Business Process Modeller, the BPM-Task Recorder integration, and asset libraries. Every Finance/SCM environment is registered to an LCS project.

Deployable packages

Custom code, configuration, and reports flow through LCS as deployable packages built from Visual Studio. A package is uploaded to LCS, then applied to an environment by an authorised user. There is no direct dev → prod publish; everything goes through the staged process.

Database refresh

LCS handles point-in-time copy of production to sandbox for testing with real data, with golden-record masking for sensitive fields. The reverse path (sandbox → prod) is limited and tightly controlled.

Database refresh discipline

Two practices separate calm projects from chaotic ones. First, schedule refreshes on a cadence (monthly UAT refresh is common) rather than on demand — every refresh wipes sandbox-only data, users' saved views, and any test setup, so surprise refreshes burn tester goodwill fast. Second, script the post-refresh steps: re-pointing integration endpoints away from production URLs, disabling outbound email and batch jobs that would fire against real customers, and re-applying test accounts. A production-copy sandbox that still holds live payment-file configurations is an incident waiting to happen. This is a core part of test data management.

The move away from LCS

The direction of travel is unambiguous: F&O environments are becoming ordinary Power Platform environments. New deployments increasingly land in the unified admin experience, where environments are created and managed from the Power Platform admin centre, run on Dataverse-linked infrastructure, and pick up capabilities the classic model lacked — self-service copy and restore, Power Platform-style backup, and one security and ALM story across F&O and Dataverse. LCS remains real for the large installed base — deployable packages, existing project workspaces, and Tier 2+ operations still live there — but treat any new capability investment in LCS-specific tooling with suspicion. For a new implementation, ask the partner explicitly which model the project will deploy on; the answer changes the run-book you'll operate for years. See run-book operations after go-live for what that operating rhythm includes.

Environments and One Version

Every environment rides the same continuously-updated application under the One Version policy. Practical consequence: updates are applied sandbox-first, and the update calendar becomes part of environment planning — a UAT cycle that straddles a platform update tests two different versions unless you pin the schedule deliberately. Keep at least one sandbox a version ahead of production during update windows, and fold the update rhythm into release management.

Cost

Sandboxes beyond a minimum included set are paid add-ons — a Tier 2 is a material line item, which is why topology belongs in the commercial negotiation. Resist the temptation to save money by sharing one Tier 2 between UAT and golden configuration on an active project; the scheduling collisions cost more than the environment. Plan environment topology and SKUs early, alongside the wider environment strategy.