A Business Central update is a change to a working finance system. The useful question is which transactions, integrations and reports must still work afterwards, who will test them and what evidence will support the production decision. A current roadmap helps identify changes; the organisation’s own environment determines the test plan.
This guide focuses on Business Central online. Keep a short record for each update: current and target version, affected environments, app and extension versions, maintenance window, planned test dates, process owners and acceptance evidence. On-premises upgrades need a separate version-specific plan.
Use the current roadmap, with older waves as context
The 2026 release wave 1 plan covered planned delivery from April to September 2026. It remains a historical reference. Microsoft states that new release plans stopped being published from September 2026 and directs readers to its AI at Work roadmap.
For a change that matters to your business, check the current product documentation, availability and licensing, then confirm the behaviour in the target environment. A roadmap entry is not acceptance evidence and does not establish that a feature is enabled for your tenant.
The update cycle is what you actually manage
The operating calendar needs particular attention, and it is the part that determines whether a release wave is uneventful. Microsoft documents the cadence in its guidance on Business Central update cycles, and the structure is consistent from wave to wave:
- Two major updates a year, released every April and October.
- A preview period beginning about a month before each major release — March and September for regular tenants.
- An update period starting at general availability and lasting five calendar months. Within it, administrators can reschedule the environment update to any date they choose.
- A grace period of one month after the update period ends, during which an update can no longer be pushed to a later date.
- An enforced update period after that.
- Minor updates every month except April and October, which Microsoft says contain critical improvements to the service, including regulatory updates.
Two practical consequences follow. First, an organisation has roughly five months of genuine discretion over when a major update lands — which means the update can be scheduled away from year end, an audit, or a peak trading period, provided somebody actually makes that decision rather than letting the default stand. Second, Microsoft notes that administrators set a maintenance window per environment, and that scheduled updates and unscheduled critical fixes respect it. Record the maintenance window in the team’s operating calendar and confirm that the named administrators receive update notices.
Separate what arrives automatically from what someone must enable
Microsoft tags release-plan entries by how they become available, and in the release plan for this wave it directs administrators to look for features tagged "Users, automatically" and, separately, features that must be enabled by administrators, makers or analysts. That distinction should drive two different responses:
- Automatically enabled changes need impact assessment, user communication and regression testing. Assign an owner for those tasks.
- Changes requiring enablement need a decision with an owner: who benefits, what is configured, what is tested, what the rollback is, and who tells users.
There is a third route that is easy to miss. Microsoft documents a Feature Management page, and notes that when features or design improvements are released as part of minor updates, some are optional until the following major update — administrators can switch them on or off there. That page is where a cautious team can adopt a change early and deliberately, on its own timetable, instead of receiving it by default later.
Use preview and generally available sandboxes for different decisions
Microsoft’s dedicated preview-environment guidance, updated 23 June 2026, describes two options: create a clean preview sandbox, or update an existing sandbox to an available preview version. The second option can include your data, setup, customisations and installed extensions, including a sandbox copy of production.
Use that preview for early compatibility and process checks, subject to the versions offered in the administration centre. Treat it as disposable: Microsoft says public-preview environments are deleted 30 days after general availability and cannot be updated to a different version. Export anything needed before deletion and record the test version.
There is a documentation inconsistency to watch: the older update-cycle overview retains a passage saying that previewing a production copy is unsupported. Use the newer dedicated preview guidance and check the options actually available for your environment. Before production changes, repeat the critical tests on the generally available target version with a current, appropriately controlled sandbox copy. Preview results alone should not sign off a later build.
Resolve extension and environment blockers before the deadline
Update failures can have several causes. Microsoft lists the common reasons an environment fails to update as per-tenant extension compatibility issues, marketplace app compatibility issues, and internal update issues. When an update fails or is cancelled, the environment is restored to its original application version and a new attempt is scheduled seven days later.
The consequence sharpens as the cycle advances. Microsoft states that during the enforced update period, extensions that cause the update to the next major version to fail might be automatically uninstalled so that the update can succeed — noting that data belonging to those extensions is not deleted and can be recovered by installing a compatible version afterwards. Microsoft also records that an environment cannot be restored to a version in its grace or enforced update period once an update to a later version has succeeded.
SCSB's reading of that is straightforward: for any organisation running per-tenant extensions or marketplace apps, extension compatibility is a key change-control item, and the five-month update period exists to give you time to resolve it. Deferring the update without using that time to test the apps converts a manageable task into an enforced one.
A proportionate update test checklist
A useful plan is short and specific to what the organisation actually depends on. List the reports, integrations, extensions, approval routes and recurring controls in production, then for each material update:
- Confirm the maintenance window and scheduled update date for every environment, and move the date if it collides with a close, an audit or a peak period.
- Review the current roadmap and product documentation that touch processes you rely on, separating automatic changes from those requiring enablement.
- Check extension and app compatibility with the publishers of every per-tenant extension and marketplace app in use.
- Copy production to a sandbox and run the update there, then test a representative transaction through each affected workflow including exceptions and approvals.
- Reconcile the outputs that matter — key reports and exported data — back to source records.
- Record the decision to enable, defer or monitor each change, with an owner and the evidence relied on.
Translate approved Malaysian requirements into test cases
Microsoft states that minor updates can include regulatory updates, and the release plan describes localisation and regulatory readiness as an ongoing investment area. Both are genuinely useful, and neither settles a Malaysian compliance question.
A product update does not determine an organisation's position with LHDN or any other authority, and the presence of a localisation capability is not evidence that a particular obligation has been met in a particular configuration. SCSB keeps these as two separate workstreams: the product-change review, run against Microsoft's material and the organisation's own environment; and the obligation review, run against the authority's current published guidance and the organisation's own advisers. The second then tells you what to test in the first.
When a light-touch approach is enough
Not every organisation needs the full apparatus described here. Keep the test plan proportionate to the functions and risks the organisation actually has. An organisation running Business Central close to standard, with no per-tenant extensions, few marketplace apps and no complex integrations, can use a smaller test pack: confirm the maintenance window and update date, test its critical transactions before production changes, and run proportionate checks afterwards.
The point at which that stops being sufficient is reasonably clear: custom extensions, integrations that other systems depend on, regulated reporting that must reconcile, or a close calendar with no slack. Where none of those apply, a heavier process buys very little.
Make acceptance evidence specific
For an illustrative sales cycle, record the sandbox and version, approved customer and item setup, expected posting and tax treatment, document references, actual ledger entries and any integration result. Include a credit or correction case where that workflow is used. The process owner should compare the result with the approved expectation, record exceptions and decide whether the evidence supports production use.
A passed screen-by-screen test is not enough if the resulting report no longer reconciles. Keep expected totals and observed totals together, identify unresolved differences and assign a reviewer. Agree the response to a failed production check in advance; do not assume every version or data change can be rolled back.
Where SCSB's implementation support fits
Where a team needs to assess, test or configure an agreed Dynamics 365 Business Central change, SCSB's Business Central implementation service can be discussed within an agreed scope. Process owners, data, approvals and regulatory conclusions remain the responsibility of the organisation.
This article is general information about how Business Central updates are delivered and governed. It is not advice on any organisation's circumstances, and it does not determine any tax, accounting or regulatory position. Release-wave contents, delivery dates and update mechanics are set by Microsoft and change over time; confirm the current position against Microsoft's own published material.
Dynamics 365 Business Central, Microsoft and Microsoft Copilot are trademarks of the Microsoft group of companies.