Blog
Still on Business Central 27? The enforced update starts in October
Every Business Central online environment gets two major updates a year, and every administrator gets five months to pick the date for each one. For version 28 that window closed on 31 August. September is the grace period, and on 1 October the enforced update period begins: if an environment still has not moved to 28, Microsoft updates it anyway, and any extension that stands in the way can be uninstalled to let the update through.
Most environments we look after are on 28 already, and if yours is, this post is a reminder of a mechanism you will meet again in March. If you are still on 27, or you are not sure, read on. The rules are precise, they are all published on Microsoft Learn, and almost nobody reads them until the update has already run.
The three periods, with dates
Microsoft’s update cycle for a major version has three stages, and each one narrows what an administrator can do.
- Update period, April to 31 August. Version 28 became generally available at the start of April and was offered to existing environments about a week later. Administrators could schedule the update on any date in the five months, and a failed attempt was simply retried seven days later.
- Grace period, September. The update can no longer be pushed to a later date, and it cannot be re-targeted to another 27.x version. Failed attempts are retried every seven days by Microsoft. An administrator can move the attempt earlier or choose a different 28.x build, and that is the whole menu. The admin centre shows warnings, and Microsoft may show in-product warnings to all users in the tenant.
- Enforced update period, from October. Microsoft keeps attempting the update. Any extension that causes it to fail, typically through a compatibility problem, may be uninstalled automatically so that the update succeeds.
Two consequences are easy to miss. A running update can no longer be cancelled once the environment is in its enforced period. And after the update to 28 succeeds, the environment cannot be restored to a 27 backup, because restoring to a version that is in its grace or enforced period is not allowed.
What “enforced” does and does not mean
The word sounds like data loss. It is not, and the distinction changes how urgent this is.
When an extension is uninstalled during the enforced period, its tables and data stay in the database. Installing a compatible version of the same extension after the update brings everything back. What you lose is the extension’s function, from the moment of the update until somebody installs a fixed version. If that extension posts your intercompany invoices or feeds your warehouse scanners, “not deleted” is little comfort during the days it is missing.
The second half matters just as much: once a compatible version exists, Microsoft does not put it back for you. An AppSource app that was removed to let the update through will not reinstall itself when its publisher ships the fix. Somebody has to notice, and somebody has to install it.
So the enforced update is not a threat to your data. It is a guarantee that the update happens on Microsoft’s date, and that any dependency that has not kept up will be missing afterwards, for as long as it takes you to find out. The whole point of acting in September is to choose the date yourself and to have the missing pieces ready before the update, not after.
The second update queued behind the first
This is where the calendar turns awkward for anyone who waited. Version 29 becomes generally available in the first week of October, the same month the 28 enforcement starts.
When an update succeeds, the admin centre automatically schedules the next one, targeting the latest available version and set for at least seven days later. An environment forced onto 28 in early October will therefore have an update to 29 scheduled within a week or two, while everyone is still finding out which extensions were uninstalled by the first one. The 29 update can be rescheduled to any date in its own five-month period, which runs to early March 2027, so this is manageable. It is manageable only if somebody is watching the admin centre and moves the date. An environment with nobody watching takes both major versions inside a few weeks, on dates nobody chose.
Why environments get stuck
An environment misses its update window for three reasons, and all three come down to extensions.
- A per-tenant extension nobody recompiled. The customisation built for you three years ago still compiles against 27 and breaks against 28, usually on a field or procedure that Microsoft marked obsolete and finally removed. Microsoft warned about the removal at least a year earlier, in the deprecated features list, and the compiler warned every developer who built the extension since. The warning reached nobody who was still responsible for it.
- An AppSource app whose publisher has not shipped. You cannot fix this one yourself; the code belongs to the vendor. Microsoft’s own remedy is blunt: an app that is incompatible with the current major version can be removed from AppSource 30 days after that version’s release, and a publisher who ignores the grace period risks having every one of their apps delisted. Meanwhile the environment it sits in stays stuck.
- A development extension left in production. Something somebody published straight from Visual Studio Code to fix a problem in a hurry, which never went through a build pipeline and never had a next-major test.
Moving customisations out of the base application and into extensions was the right decision, and we have argued for it at length. It did not remove upgrade risk. It moved that risk from code you own to release calendars you do not, and the enforced update is where the two meet. On this Microsoft is explicit: during the enforced period, the customer and their reselling partner are fully responsible for finding a way forward.
The ten-minute check
You do not need a developer for any of this. Open the Business Central admin centre and look at four things.
- The environment’s version and next update. Each environment lists its current version, the latest available version and the target and date of its next update. If the current version starts with 27, the rest of this post applies to you today.
- Notification recipients. Every update warning Microsoft sends, including the pre-update compatibility check that names the incompatible extension and what to change, goes to the email addresses on the Notification recipients tab, and nowhere else. If that tab is empty, no warning has been sent to anyone. If it lists a person who left, the same. The messages come from no-reply-dynamics365@microsoft.com, so also check they are not being filed as spam.
- The Operations log. A failed update attempt is recorded there with its error. That error usually names the extension, and it is the fastest way to learn why the September retries keep failing.
- The update window. By default an environment can be updated between 20:00 and 06:00 local time, and the window must be at least six hours. An update that does not finish inside the window is cancelled, the environment is restored, and the attempt moves seven days out. A large database with a narrow window can fail on time alone, which looks the same as a compatibility failure from the outside.
If the environment sends telemetry to Application Insights, the same story is in the environment lifecycle signals: LC0100 when an update becomes available, LC0107 when one fails.
What we would do this week
- Rehearse the update on a copy. Copy production to a sandbox, schedule the sandbox update for today and set Allow the update to run outside the update window to yes. Within hours you have either a working 28 sandbox or a precise failure to act on. This is the one test a preview environment cannot give you, because previews cannot be created from your production data.
- Fix the PTE and stage it. Recompile against 28, test it on that sandbox, and upload the new version with the deployment schedule set to Next major. Since update 28.4 this is done in the admin centre, and we covered how that changed two weeks ago. The compatible version then installs as part of the update itself.
- Chase the vendor, in writing. For an AppSource app that blocks the update, ask the publisher for the 28-compatible version and a date. If the answer is silence, decide now whether you can run without the app for a while, because in October that decision will be made for you.
- Uninstall what nobody uses. Environments accumulate extensions that were trialled and forgotten. Each one is a potential blocker. Uninstalling keeps the data unless you explicitly choose otherwise, so the risk is small.
- Pick your own date. Once the sandbox update succeeds, schedule production for a night this month that suits your business, rather than a night in October that suits the algorithm.
- Then look at 29. Its preview is out now and the changes worth testing are known. An environment that lands on 28 this month can take 29 on a date of its choosing, any time before March.
A major update was never optional in Business Central online. What the enforced period changes is only who picks the day, and September is the last month in which that is still you.
Not sure what is blocking your environment, or who is supposed to be watching the admin centre? Tell us your story and we will find out together.