Business Central release waves explained

Microsoft ships major Business Central updates twice a year, on a fixed cadence long called release waves. Understanding the cadence — and what it requires of you — is essential for keeping a SaaS tenant healthy. One 2026 caveat up front: Microsoft is retiring the release plan documents that used to accompany each wave (roadmap content moves to the continuous AI at Work roadmap from September 2026), but the update cadence itself is unchanged — majors still land in April and October. The full story of that change is in the 2026 wave 2 guide; this guide covers the mechanics that still govern every tenant.

The schedule

Wave 1 lands in April; Wave 2 lands in October — so version numbers step twice a year (version 26 in April 2025, 27 in October 2025, 28 in April 2026, 29 in October 2026, and so on). Each major brings new application features, new AL platform capabilities, performance improvements, and — the part that bites the unprepared — deprecations announced one or two versions ahead of removal. Historically each wave came with a formal release plan published months in advance; going forward, feature disclosure is continuous via the roadmap, and the per-version "what's new" documentation remains the reliable record of what actually shipped.

Preview

A preview build is available roughly six weeks before general availability. Customers can spin up a preview sandbox from the admin centre, install their own extensions against it, and run regression tests against the upcoming version. This is the canonical window for partners to certify AppSource apps, and the canonical window for you to find out whether your per-tenant extensions survive the new runtime — before production finds out for you.

General availability and rollout

GA is a fixed date, but Microsoft rolls the update out across the tenant base over several weeks. Customers can request an early update from the admin centre — useful when you want the new version in UAT immediately — or let their scheduled window take it. Mandatory upgrades happen by a published cut-off date: you can defer within the allowed range, but there is no opting out indefinitely. A tenant that ignores scheduling ends up updated at Microsoft's convenience, which is exactly the behaviour the update window exists to prevent. The version itself arrives regardless, but individual new capabilities within it can still be previewed, delayed, or turned off per feature through Feature Management.

The update window

Customers configure an update window (a span of hours on a day of the week) when Microsoft is allowed to take their environment briefly offline to apply the update. Configure it carefully — outside business hours is the obvious answer, but pay attention to overnight batch posting, weekend cron jobs, bank file transmissions, and integration schedules that assume the API is always there. The window applies per environment, so production and sandboxes can (and should) run different schedules, with a sandbox taking each major first.

Extensions

A wave update reinstalls every installed extension against the new platform version. Extensions published to AppSource are pre-validated for compatibility — Microsoft runs technical checks against upcoming versions, which is a large part of AppSource's value. Per-tenant extensions (PTEs) are not: it is the customer's or partner's job to compile and validate them against the new runtime before the update window arrives. In practice this is where wave problems actually come from. Microsoft's own upgrade machinery very rarely breaks a vanilla tenant; an abandoned PTE using a deprecated event, written by a partner who is no longer engaged, breaks tenants every wave. If nobody currently owns your PTEs, that is the risk to fix — the AL-Go CI/CD guide shows how compilation against upcoming versions becomes automatic.

Monthly updates

Between majors, Microsoft pushes monthly minor updates — bug fixes, security patches, and small enhancements. These don't change the major version, don't require extension recompiles, and can't be skipped. They are also the reason the old NAV habit of "freeze the system, touch nothing" is dead: the platform moves monthly whether you engage or not, and the winning posture is a tenant whose extensions are continuously kept compatible rather than periodically rescued.

Practical advice

Treat each wave like a small recurring project with a named owner:

1. Six weeks out: create a preview sandbox, install all extensions, compile PTEs against the new version.
2. Run your critical-path processes — order-to-cash, purchase-to-pay, month-end — in the preview, plus whatever broke last time.
3. Fix and republish PTEs; chase ISVs whose AppSource apps show compatibility warnings.
4. Brief power users on visible changes and check deprecation lists for anything you still rely on.
5. Confirm the production update window and let the update land.

Most teams get through both waves a year with a half-day each once the routine exists. The teams that suffer are the ones treating April and October as surprises — which, on a published fifteen-year-old cadence, they never are.

Where to go next

The developer's side of each wave is upgrading AL code across BC versions, and the warnings that turn into errors are in AL compiler errors. Sandboxes for the preview are covered in Business Central environments. The enterprise-tier equivalent of this cadence is One Version and updates.