Business Central and LS Central version lifecycle: planning around update waves and end of support

Upgrades & lifecycle · 9 min read

Running Business Central with LS Central means living on two release trains at once. Neither one waits for a quiet week in your stores. The retailers who handle updates well are not the ones with the best luck — they are the ones who treat the two waves a year as fixed dates on the calendar and plan testing, training, and freeze periods around them. This guide explains how the waves actually work, what end of support really means, and how to build an annual upgrade calendar around both products.

Two release trains, one calendar

Business Central online follows a set update schedule: two major update cycles each year, starting in April and October, with minor updates in the other months. Microsoft manages updates for both the application and the platform. LS Central deliberately runs on the same rhythm: LS Retail releases new features in two major waves a year, scheduled for April and October to coincide with the general availability of Business Central release wave 1 and wave 2, and each LS Central major version is built on the matching Business Central major version — LS Central 27.0, for example, is built on Business Central 2025 release wave 2. Between the waves, LS Retail ships new events and hotfixes on a weekly basis and cumulative updates as needed, and LS minor versions follow the availability of Microsoft's minor updates.

The practical consequence: there is no version of LS Central to upgrade to until the matching Business Central wave exists, and there is no staying put once the wave arrives. Planning has to start from the wave dates, not from when the update notification lands.

How a SaaS wave reaches your environment

When a wave rolls out, the update is applied to an environment inside that environment's update window — the hours of the day, in a selected time zone, during which updates are allowed to run. The default window is 8:00 PM to 6:00 AM local time. Updates always start during the window, though not necessarily right at its start, and an update that cannot finish before the window ends is canceled so the environment is operational for business hours; it is automatically rescheduled seven days later and the notification recipients are informed. During the update itself, all users and sign-in attempts are blocked with a "Service is under maintenance" message — which is why the window belongs outside trading hours, and why a failed or canceled update is a planning event, not just a delay: it moves your go-live by a week unless you reschedule it yourself.

Notifications are part of the machinery. Registered notification recipients in the administration center get an email when a new version becomes available and when an update is scheduled. Those emails come from Microsoft's Dynamics 365 notification address, and Microsoft explicitly warns they must not be swallowed by spam filters. If the one person who reads them leaves, the waves keep coming — update the recipient list as part of staff changes.

What you actually control in the admin center

SaaS updates are mandatory in effect, but their timing is more flexible than most admins assume. Per environment, you control three things:

• The update window. In the Business Central administration center, open the environment from the Environments tab, choose Update Settings, then Set update window, and specify time zone, start time, and end time. The window must be a minimum of six hours. Set it once, deliberately, per environment — production and sandbox do not need the same window.
• The scheduled date. Under Update Settings, use the Modify action next to Next Update and pick a target version and a date in the Schedule Environment Update pane. You can schedule to any version higher than the current one within the environment's current or next major version, on a date within the update period for the current major version. You can even select a planned version that has not been released yet; the update is then scheduled once that version becomes available. Note the edge case: pick today's date after today's window has already passed, and the update starts in tomorrow's window instead.
• Preparation. Preview environments exist so users can get familiar with new functionality before it reaches production. Before a major update, Microsoft also checks per-tenant extensions in existing environments for compatibility with the next major version and emails notification recipients about any issues it detects. If an issue affects your extensions, the documented route is to fix and test the app in a sandbox running the new major version, then upload the new app version in Extension Management with Deploy to set to Next major version, so the compatible version is used when the environment updates.

The environment page shows the fields that matter for planning: Latest Available Version and Next Update (the target version and date). If those two fields are not part of someone's monthly routine, the first you'll hear of a wave is the maintenance message.

On-premises: end of support means something different

On-premises, nobody forces the update — and that is exactly the risk. Business Central on-premises from 2019 release wave 2 onward is covered by the Modern Lifecycle Policy. The customer is in full control of deployments and installs updates itself, but Microsoft supports the software only if the customer keeps it current according to the policy. End of support for an on-premises version therefore does not mean the software stops running; it means the fixes, new features, and latest tax updates that the policy provides stop flowing to a version that has fallen behind, and support is no longer there when something breaks. The older October '18 and April '19 on-premises updates sit under the earlier Fixed Lifecycle Policy instead — the April '19 update's mainstream support ended in October 2023 — which is why very old installations face a project, not an update.

For a retailer, the on-premises planning rule is simple: your upgrade project has to finish while your current version is still inside its support life, with time to spare for the LS Central version built on your target Business Central version, plus POS testing. Starting when support ends is starting a full wave late.

Keeping LS Central in step with Business Central

LS Central's support window in SaaS is explicit: LS Retail supports the last minor version of the current major version and two back. When LS Central 27.0 shipped, versions 25.1 and 26.1 remained supported; anything older was not, although an upgrade path is maintained. Skipping one wave is survivable; skipping two puts you outside the supported set. On-premises, the pairing is tighter still: an LS Central release is built on one specific Business Central major version, so the two are upgraded together, in one project, with the POS estate tested against the pair.

One timing gift is built into the LS schedule: partners receive a feature-complete release candidate five to six weeks ahead of each wave. If your partner is in that program, your test window opens before general availability — use it. That is when POS regression testing belongs, not in the week Microsoft has scheduled your production update. (For what to verify at the tills after any change, see our offline mode checklist.)

An annual upgrade calendar you can run

Turn the two waves into a standing yearly rhythm. Adjust the months to your trading peaks, but keep the sequence:

1. January and July — inventory. Record the current BC and LS Central versions for every environment and store, confirm notification recipients in the admin center are current staff, and verify each environment's update window still sits outside trading hours.
2. February and August — prepare. Watch for the wave's release plan and your partner's release-candidate access. Stand up or refresh a sandbox/preview environment on the new major version and run the extension compatibility findings Microsoft emails about.
3. March and September — test. Regression-test the core retail flows in the sandbox: sale, return, tender, statement posting, and peripheral printing at one representative till. Fix extensions and set them to deploy to the next major version where needed.
4. April and October — schedule, don't drift. When the wave becomes available, pick the production date yourself inside the update period instead of accepting whatever default lands. Place it away from promotions and stock counts, in the environment's update window, with the next morning reserved for verification.
5. May and November — verify and close. Confirm statements posted cleanly for the first days on the new version (see our end-of-day routine), close out the wave's issue list, and record the new version baseline for the next cycle.

The decision rule underneath the calendar: if a choice exists between testing early in the partner's release-candidate window and testing late inside your update period, choose early. Every week of delay is spent from the same fixed budget, and the reschedule penalty for a failed update — seven days later, automatically — is priced into the late option whether you plan for it or not.

FAQ

Can we skip a SaaS wave and catch up later? Not in any way that helps. Updates are scheduled within the current major version's update period, and LS Central's SaaS support only covers the current major and two back — falling behind spends support coverage without buying time.

What happens if an update fails overnight? If it cannot complete inside the update window it is canceled and automatically rescheduled seven days later, and notification recipients are informed. Reschedule it yourself to a date you choose rather than waiting for the automatic one.

Does end of support switch off an on-premises version? No. The software keeps running, but under the Modern Lifecycle Policy Microsoft supports on-premises software only while it is kept current — fixes, features, and tax updates move on without you.