Business Central upgrade readiness for LS Central stores: what to check before the update wave

Upgrades & lifecycle · 7 min read

Business Central online gets two major updates a year, landing every April and October, with minor updates in the months in between. For a back office, a major update is an IT event. For a store running LS Central, it is a trading event: the POS, the hardware hanging off it, and the end-of-day close all sit downstream of the same version change. Readiness means checking the retail layer on purpose, not discovering it on the first morning after the update.

Why a retail upgrade is not a back-office upgrade

In the LS Central online model, the POS runs a web client on the customer tenant, so it is updated automatically when the tenant is upgraded. There is no separate POS version decision to make — and no way to hold the tills back on the old version while head office moves ahead. LS Retail also recommends testing the hardware as part of update testing, and keeping the Hardware Station and AppShell current on each host through Update Services so they stay in sync with the SaaS updates. A checklist that only covers extensions and finance screens misses the two places a store actually feels an update: the till and the close.

Step 1: Inventory extensions and integrations before anything else

Compatibility problems are the most common reason an environment update fails, and Microsoft's notification email will not find them for you: it carries no fix for breakage and does not detect issues in code that interacts with ISV applications. So the first readiness step is a written inventory, not a hope:

• Per-tenant extensions (PTEs). List every one, its owner, and who recompiles it if the new version breaks it. Microsoft's standing advice is to keep apps and PTEs ready to update at any time and to actively test compatibility.
• Marketplace and ISV apps, LS Central included. Confirm each vendor's stated support for the target version. ISV apps update automatically when the BC version update occurs — automatic is convenient, but it means the vendor's version, not yours, is what lands.
• Integrations. Payment, e-commerce, loyalty, and reporting connections that call the tenant need a named owner and a post-update test, even if they are "just APIs." An integration nobody owns is an integration that fails silently.

Step 2: Use the preview month in a sandbox

The preview period starts a month before each major release — every March and September. During it, administrators can create a sandbox on the preview version or update an existing sandbox to it, specifically to try new functionality and test the compatibility of extensions. Since the 2025 release wave 2 preview, updating an existing sandbox to the preview version also lets you test with your own data and extensions, surface issues caused by environment data, and start user readiness such as training earlier.

Two cautions belong on the plan. First, preview sandbox environments are removed 30 days after the official release, so export anything from the preview you need to keep before that deadline. Second, closer to the production update, test again on a sandbox copy of production updated to the released version — Microsoft strongly recommends testing critical business scenarios before production environments are updated, and for a retailer the critical scenarios are a sale, a return, and a statement close, not a journal posting in isolation.

Step 3: Test the POS and its hardware, not just the back office

Run the readiness procedure on a test POS connected the way a real till is connected:

1. Sign in and sell. Complete a normal sale, a return, and a mixed-tender transaction on the updated sandbox POS. The layout, buttons, and prompts should behave exactly as cashiers expect.
2. Exercise the hardware. Print a receipt, open the cash drawer, scan items, and run a card transaction if the test setup allows it. This is the hardware testing LS Retail recommends as part of update testing — printers and drawers are where version changes surface first.
3. Check the host software. Confirm Hardware Station and AppShell on the test host are the versions Update Services delivers for the new release, and note the versions so store hosts can be checked against them.
4. Test offline behaviour. Drop the connection briefly and confirm the POS keeps selling and the queue drains afterwards (see our offline mode guide).
5. Involve store users. LS Retail lists insufficient testing — and leaving end users out of it — as a common LS Central mistake: usability problems and workflow inefficiencies are exactly what back-office-only testing misses. Unit, integration, and user acceptance testing each catch a different class of problem.

Step 4: Pick the date like a retailer

You have more room than most stores use. The update period lasts five calendar months, and administrators can reschedule the update to any date within it from the Business Central administration center, where the current version, the next version, and the transition dates are all visible. Scheduled major and minor updates respect the maintenance window set on the environment. What changes across the cycle is how much control you keep:

The decision framework is simple. Never let the date drift into the grace period: a failed attempt there is automatically rescheduled seven days later, whether that day suits trading or not. Prefer a date early enough in the update period that a failed attempt — which restores the environment to the original application version — leaves time to fix the cause and retry on a day you choose. Always set the date against the trading calendar: not the night before a promotion, a stocktake, or your busiest weekend, and inside the environment's maintenance window so the update runs when stores are closed.

The readiness checklist

• Extension and integration inventory written down, each with a named owner.
• Vendor support for the target version confirmed for LS Central and every ISV app.
• Sandbox on the preview version tested during the preview month; anything worth keeping exported before the preview environment is removed.
• Production-copy sandbox updated to the released version; sale, return, and statement scenarios run by store users, not only by IT.
• Test POS hardware exercised: receipt print, drawer, scanner, card flow.
• Hardware Station and AppShell versions recorded from the test host; store hosts checked against them.
• Production update date set in the admin center, inside the maintenance window and clear of promotions, stocktakes, and peak weekends.
• First-trading-day plan staffed: who watches replication, who runs the first close, who stores call if a till behaves differently.

What success looks like on the first trading day

The update is not done when the admin center says it succeeded. It is done when:

• Every till signs in on the new version and completes its first sale, receipt print, and drawer open without workarounds.
• Replication and scheduler jobs run clean, so prices and items distributed after the update reach the stores.
• The first statement calculates and reconciles against the POS totals — the same checks as the normal end-of-day routine, run with extra attention because it is the first close on the new version.
• No extension is missing. If anything was uninstalled to let the update through, it is reinstalled in a compatible version and its data confirmed intact.

FAQ

Can we skip a major update? No. The cycle runs preview, update, grace, and enforced periods; skipping the work does not skip the update, it just moves it to the enforced period where blocking extensions may be removed to let it succeed.

What happens if the update fails? The environment is restored to the original application version so users can connect again, and the attempt is automatically rescheduled for seven days later. Administrators can move it to an earlier or different date inside the update period once the cause is fixed.

When should testing start? In the preview month — March or September — using a sandbox on the preview version, then again on a production copy once the release is generally available.