Every six months a release plan appears, someone forwards it, and a Malaysian finance or IT team is asked whether any of it matters. SCSB's answer is usually that the release plan is the least controllable part of the picture. What a team can actually manage is the update cycle underneath it — the maintenance window, the update period, the sandbox test and the extensions that decide whether an update succeeds. That machinery is stable, documented and worth learning once. The feature list changes every wave.
What a release plan is, and what it is not
Microsoft's Dynamics 365 Business Central 2026 release wave 1 plan states that it covers functionality planned to be delivered to market from April 2026 to September 2026. The word doing the work in that sentence is planned.
A release plan is a statement of intent published ahead of delivery. Entries move between waves, change scope, and are sometimes withdrawn. SCSB therefore treats a release-plan entry as a prompt to review, never as evidence that a capability is available in a particular environment, enabled, licensed, or appropriate for the organisation's configuration. This article deliberately does not tell you which features shipped: for the current per-feature status, the authoritative sources are Microsoft's release plans and its interactive Release Planner, both reachable from the release-plan page above, and the environment itself.
Microsoft describes the broad investment themes for this wave — including AI-assisted capabilities and agents, electronic documents, supply chain, governance and administration, and reporting. Read those as direction of travel. Where a specific capability matters commercially to an organisation, confirm its current state against Microsoft's release plan and then against your own tenant, in that order. One current availability boundary is worth noting because it is structural rather than seasonal: Microsoft states that Microsoft Copilot and agents are available only to Business Central online customers.
The update cycle is what you actually manage
This is the part most teams skip, 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. Setting that window sensibly for Malaysian working hours is a five-minute task that many organisations have never done.
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. Nobody chose them, so nobody is watching for them unless someone is assigned to.
- 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.
Preview environments do less than most teams assume
Preview environments are widely recommended and widely misunderstood, and SCSB would rather set the expectation correctly than let a team discover the limits during a compressed test window.
Microsoft documents that a preview sandbox is created about a month before a major update by choosing the version marked as preview, and that the new preview sandbox contains demonstration company data. It also states plainly that trying the preview on a copy of current production data is not supported, and neither is testing the upgrade from the current version to the preview. Preview sandboxes are removed 30 days after the official release becomes available.
So a preview environment is genuinely useful for learning new functionality and for validating that per-tenant extensions still work. It is not a rehearsal of your upgrade. The rehearsal comes later: once the update is generally available, Microsoft's guidance is to copy the production environment to a sandbox and schedule the update on that sandbox, which can be run immediately by scheduling it for the current date and allowing it to run outside the update window. SCSB treats that copy-and-update test, not the preview, as the real evidence.
Your extensions decide whether the update succeeds
Most failed updates are not caused by Microsoft's changes. 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 the 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 test plan
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 wave:
- 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 release plan entries 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.
Keep Malaysian regulatory obligations out of the roadmap conversation
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, and SCSB will say so rather than manufacture a governance programme. An organisation running Business Central close to standard, with no per-tenant extensions, few marketplace apps and no complex integrations, can reasonably confine itself to setting a sensible maintenance window, choosing an update date that avoids its busy period, and testing a handful of core transactions after the update.
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.
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.