Two Environments, Same Version, Different Contents

Spin up a fresh Business Central 2026 release wave 1 environment — version 28 — and you get the full set of Microsoft standard extensions that ship with that release. Upgrade an existing environment to the exact same version, and some of them are simply not there.

Both environments report the same version number. Both are current. One is missing functionality the other has.

This surprises people, and the instinct is to file it as an upgrade bug. It is not. It is a deliberate change to what an environment upgrade is permitted to do, and understanding the principle behind it matters more than memorising the workaround — because the principle is going to keep producing surprises like this one.

What Actually Changed

MVP Yun Zhu documented the behavior on 14 May 2026, in a post titled “Dynamics 365 Business Central: Newly added standard extensions missing in upgraded environments (Uninstalled apps will now remain uninstalled)”. His worked example is the External Storage – Document Attachments extension: present in a newly created version 28 environment, absent in an upgraded one.

The important part of his post is not the symptom but the attribution. Zhu reports that Microsoft announced this at Directions EMEA 2025, and quotes the announcement directly: “We listened to your feedback! Uninstalled apps will now remain uninstalled.”

That single sentence is the whole change. Read it as a statement about state ownership rather than about installation mechanics.

Previously, an upgrade could quietly re-add Microsoft extensions to an environment. That behavior is convenient exactly once — the first time it saves you from a missing dependency — and then it is a liability forever after. If an administrator deliberately uninstalled an app, and the next upgrade put it back, the upgrade overrode an explicit human decision. Teams that uninstall apps for good reasons (unused localisation layers, migration extensions retained past their usefulness, apps disabled while a defect is investigated) would find those decisions silently reversed on Microsoft’s schedule, not theirs.

The new behavior treats “uninstalled” as a durable, intentional piece of tenant state. An upgrade no longer gets a vote on it.

The trade-off is real and it lands on partners: a new extension introduced in version 28 was never explicitly installed on your upgraded tenant, so on the new rules there is nothing authorising the platform to install it. It stays out. The environment is correct by the new definition and incomplete by the old expectation.

The Same Principle, Already in the Docs

This is not an isolated decision, which is the strongest evidence that it is design rather than accident. Microsoft Learn already documents the identical principle for a different scenario — apps removed to unblock a failing update. From Maintain Marketplace apps and Per-Tenant extensions in Business Central online, describing the enforced update period:

Once a compatible version of an app is made available, it won’t be automatically installed on each environment from which it was uninstalled as part of the enforced update period.

Same rule: the platform will take an app out when it has to, and it will not put it back on its own initiative. Reinstallation is an administrative act.

The related setting is worth knowing precisely, because it is easy to assume it covers this case. Learn’s Managing Apps page explains that Apps Update Cadence controls whether installed apps update alongside minor environment updates, with the default meaning they update only with major updates. It governs updates to apps already present. It has nothing to say about apps that are absent — no cadence setting will install something that was never installed.

The Trap: The Admin Center Cannot Fix This

Here is the part that costs the most time, and it is documented in plain language on the same Learn page:

In the current version, it’s not possible to install new apps, either main apps or their dependencies (library apps), by using the Manage Apps. To install the apps, continue using the Extension Management page within your Business Central environment.

The natural reflex, having spotted a missing app from the Business Central administration center, is to fix it from the administration center. Manage Apps lists installed apps, offers an Uninstall action, and does install updates — an Install update action becomes available once a newer version of an already-installed app is ready to install. What it will not do is install an app that is not there yet. Updates to what you have, yes; new apps, no. The remediation path therefore runs through Extension Management inside the environment — a different surface, reached a different way, and one that a partner working primarily from the admin center may not have open.

So the operational shape of the fix is: detect from the admin center, remediate from inside the tenant.

While you are on the Extension Management page, it is worth knowing what uninstalling actually left behind. Per Unpublishing and Uninstalling Extensions, uninstalling does not touch business data — data collected by the extension is preserved so the app can be reinstalled without loss. That is why reinstalling a standard extension after an upgrade is a low-risk act rather than a data event. The corollary is that orphaned data accumulates: the Delete Orphaned Extension Data page lists apps you still hold data for, and Learn’s upgrade considerations for v26 and later notes that clearing it reduces companion-table row size and shortens future upgrades.

A Second, Different Gap — Do Not Conflate Them

Two days earlier, on 12 May 2026, Zhu documented a related but distinct problem: newly added workflow templates for Item Journals and Requisition Worksheets are, in his words, “available out-of-the-box in a fresh version 28.0 environment” but “noticeably absent in environments that have been upgraded.”

It is tempting to file this under the same heading. Resist that, because the two differ in both cause and cure:

  • Standard extensions — by design, per the Directions EMEA 2025 announcement. Fixed by installing the app from Extension Management. Not expected to change.
  • Workflow templates — Zhu does not characterise this as by-design. He notes it “might be automatically updated in future versions, but for the current upgraded environment, this is the only way to do it.” The fix is different too: search for Workflow Templates via Tell Me, then run Reset Microsoft Templates.

Treating the second as another instance of the first leads you to look for a missing app that does not exist, and to skip the one action that actually resolves it.

What to Do About It

The practical consequence is that a version number is no longer sufficient evidence that two environments are equivalent. Two tenants on 28.x can differ in installed-app set, and nothing in the version string reveals it. Any post-upgrade checklist built on “confirm the version” is checking the wrong thing.

A more useful post-upgrade pass:

  1. Compare the installed-app list of the upgraded environment against a freshly created sandbox on the same version. The delta is your missing set — and creating that sandbox is the only cheap way to know what “complete” looks like for that release.
  2. Reinstall what you actually want from Extension Management in the environment, not from Manage Apps.
  3. Run Reset Microsoft Templates if workflow templates are among the gaps.
  4. Treat every remaining absence as a decision, and write down which ones are deliberate. Under the new rules that record is the only thing distinguishing “we removed this on purpose” from “we never noticed.”
  5. Clear orphaned data for apps you have confirmed you will not reinstall.

Step 4 is the one that compounds. The upgrade now respects your uninstall decisions, which is only an improvement if those decisions were ever recorded somewhere more durable than the memory of whoever made them.

When something does go wrong post-upgrade and the cause is not an obvious missing app, the diagnostic tooling in this release wave is worth reaching for — the same 2026 wave 1 release shipped a Troubleshooting MCP Server for AI-assisted AL debugging, which can query live call stacks during a debug session. And if you are rebuilding a development environment to match an upgraded tenant, note that the version alignment problem applies to your toolchain too: downloading AL symbols offline from an artifact is the reliable way to compile against exactly the version the tenant is now running.

The Broader Read

Strip away the specifics and this is a change in who owns environment composition.

The old model treated the installed-app set as something the platform could reconcile toward a canonical “what this version should contain.” The new model treats it as tenant state that only an administrator writes. Microsoft ships new capability; it does not push that capability into environments whose owners never asked for it.

That is the right call, and it is consistent with how the platform already handles configuration data that lives outside the standard boundaries — the system is increasingly explicit about not silently touching state a human deliberately shaped.

It does mean the job changed. “Upgrade the environment” used to be reasonably close to “the environment now has what this version has.” It no longer is. Somebody has to look at the difference and decide, every release, which absences are choices and which are oversights.

That somebody is the partner. Worth building into the checklist before the next wave.