Business Central extension install and upgrade errors

By Emil Björk · Microsoft business apps consultant, Gothenburg

Why a Business Central AL extension fails to install, publish, or upgrade — dependency, data-upgrade, and schema errors decoded.

Reviewed September 20263 min read · 641 wordsPublished
On this page (5)

Business Central extensions install, upgrade, and uninstall through a managed lifecycle that checks dependencies, schema compatibility, and data-upgrade code before committing — which is exactly why an install or upgrade fails loudly rather than leaving a tenant in a half-updated state, but the error messages assume familiarity with that lifecycle to interpret correctly.

"This extension has one or more unresolved dependencies"

Symptom. Publishing or installing an extension fails immediately, naming a dependency app ID or a version range.

Cause. The extension's app.json declares a dependency on another app (a specific ID and minimum version) that either isn't installed in this environment, or is installed at a lower version than required.

Fix. Install the missing dependency first, or upgrade the existing dependency to at least the required version, then retry.

Prevention. In multi-app repos, use AL-Go's dependency-aware build ordering (see Business Central CI/CD with AL-Go) so dependent apps are always built and can be deployed in the correct order automatically, rather than tracked manually.

"Upgrade of extension [Name] failed" with a data-upgrade error

Symptom. A version upgrade fails partway through, typically citing an exception inside an Upgrade subtype codeunit.

Cause. The extension's data-upgrade code (which migrates existing records to a new table or field structure between versions) hit data it didn't anticipate — a null value, a record in an unexpected state, or a genuinely new edge case introduced by real usage since the last version.

Fix. The extension developer needs to fix the upgrade codeunit to handle the actual data encountered, then republish a corrected version. There is rarely a safe manual workaround from the admin side beyond rolling back to the previous version while the fix is prepared.

Prevention. Test upgrades against a recent copy of production data in a sandbox before rolling to production — a clean or synthetic test tenant rarely exercises the same data edge cases a live tenant has accumulated over months or years.

"Schema update is required" / "The following tables need to be synchronized"

Symptom. After an extension update, a table shows a pending schema-synchronization state rather than being immediately usable.

Cause. A table structure changed (a field added, a key changed) and Business Central's schema sync — which reconciles the AL table definition with the actual underlying SQL schema — hasn't completed yet, either because it's still running or because it requires a data conversion the platform is asking for explicit confirmation on.

Fix. Allow the schema synchronization to complete (larger tables take longer), or explicitly trigger it from the extension management page if it's stalled. For synchronization modes that require confirming a potentially destructive change (a field being removed or reduced in length), review what the extension is actually asking for before confirming.

Prevention. Schedule extension upgrades with schema changes during a maintenance window on tables with large row counts, since synchronization time scales with table size, not extension complexity.

"Cannot uninstall extension [Name] because [Other Extension] depends on it"

Symptom. Attempting to uninstall or unpublish an extension fails, naming a dependent extension.

Cause. Another installed extension declares a dependency on this one; Business Central refuses to remove a dependency out from under something that needs it, which would break the dependent extension at runtime.

Fix. Uninstall the dependent extension first (or confirm it no longer actually needs the dependency and update its app.json), then retry.

Prevention. Before decommissioning a shared internal library extension, search for every extension in the tenant that declares it as a dependency — removing a foundational internal app without checking dependents is a common way to take down several unrelated features at once.

Where to go next

The development-side discipline that prevents most of these — a proper test app and CI pipeline — is covered in the AL test framework and Business Central CI/CD with AL-Go. Per-tenant extensions versus AppSource apps, and the different upgrade paths each follows, are covered in per-tenant extensions vs AppSource.

Frequently asked questions

Why does an extension that worked in the sandbox fail in production?

Production often has real historical data a fresh sandbox doesn't — a data-upgrade codeunit that never gets exercised against genuinely old or edge-case records in a small test tenant can fail against production's actual data shape. Test upgrades against a copy of production data, not just a clean sandbox.

Can I force an extension to install despite a dependency error?

No — dependency checks exist because the extension's code assumes the dependency's objects exist with a specific structure. Forcing past the check (where the tooling even allows it) produces runtime errors instead of an install-time one, which is strictly worse to debug.

Related guides

Browse every guide in Business Central or just Troubleshooting.

Did this fix it?

Signals which guides land and which need work. No account, no comment box — corrections go through the contact page.

Spot something wrong or want a topic covered? Send a correction or a topic request — both are welcome.