One Version and updates in Finance and SCM

Dynamics 365 Finance and Supply Chain Management run under Microsoft's One Version service-update policy: every production environment, in every region, on every tenant, is updated to a current platform version on a fixed cadence. Customers have limited flexibility around timing and no ability to remain indefinitely on an older version. This is one of the biggest cultural differences from on-premise AX.

The cadence

Microsoft ships Service Updates roughly every six weeks — about eight per year — each bundling new features, fixes, and platform changes. Service Updates apply in a rolling fashion across the tenant base; customers can choose between channels (e.g. General vs Early access) for some control over which release lands when.

Pause windows

Customers can pause Service Updates for a small number of cycles in a calendar year, deferring an update — typically used to skip a busy period like year-end close. After the maximum pause is consumed, the update applies automatically. The pause is per-environment and configured through LCS.

Service Update vs Application/Platform update

Platform updates are runtime and infrastructure changes — these are mandatory and continuous. Application updates change Finance/SCM standard code; these are part of the Service Update bundle and follow the same cadence.

Custom code obligations

Custom code (X++ extensions, integrations, reports) compiled against an older platform may break against a newer one. Microsoft's tools include Code Upgrade services in LCS that scan custom code for breaking changes ahead of a service update.

Quality assurance

Microsoft pre-tests Service Updates against a sample of customer environments and gates rollout by region. Customers should still run their own regression suite against the preview service update on a sandbox before applying to production.

Why One Version

Microsoft cannot economically support hundreds of AX versions in production for decades. One Version is the price of SaaS: you get continuous improvements, security patches, and uniform support, in exchange for keeping current. The discipline is real but the rewards — performance gains, AI features, regulatory updates — accrue without big-bang upgrades.

Operational reality

Mature Finance/SCM customers treat each Service Update as a small ops task: install in sandbox a week or two ahead, run the regression suite, brief power users on new features, accept production rollout. With practice it becomes routine.

The One Version release cycle at a glance

What actually breaks

The features most likely to surface a real regression are the ones closest to customisation: chain-of-command extensions on standard classes, event handlers subscribing to platform events whose signature changed, and reports built against data entities that had fields added, renamed, or reshaped. Pure configuration (number sequences, workflows, security roles) rarely breaks; compiled X++ extending standard logic is where Code Upgrade scans earn their keep. A thin extension layer — small, focused chain-of-command overrides rather than deep copy-and-modify customisation — is the single biggest predictor of a quiet Service Update cycle.

Channels and staggered rollout

Microsoft doesn't push every tenant to a new Service Update on the same day even within a chosen channel — rollout is staggered by region and cohort so that a problem caught in an early wave can be halted before it reaches every customer. This means two tenants on the same channel can be a few days apart on the same nominal version; it is normal, not a sign of a misconfigured environment, and it's one reason the sandbox-first-then-production sequence matters more than watching a specific calendar date.

Where to go next

Service updates land through environments and LCS and are absorbed through release management and test automation. Custom X++ is what needs checking each cycle. The 2026 change to how Microsoft communicates the roadmap — without changing this cadence — is in the 2026 wave 2 guide.