Business Central Extension nach Update nicht kompatibel: was passiert?

Wenn eine Extension mit der neuen Business-Central-Version nicht kompatibel ist, schlägt das Update der Umgebung fehl: Microsoft setzt die Umgebung auf die alte Version zurück und plant sieben Tage später einen neuen Versuch. Das geht innerhalb des fünfmonatigen Update-Zeitraums und einer einmonatigen Kulanzphase so weiter. Danach darf Microsoft inkompatible Extensions automatisch deinstallieren, damit das Update durchläuft; die Daten der Extension bleiben dabei erhalten, die Funktion fehlt aber.

Dieser Artikel beschreibt den Ablauf für Business Central online, so wie Microsoft ihn in der Dokumentation zu Update-Zyklen festlegt, und was Admins und Entwickler in jeder Phase tun sollten. Stand: Oktober 2026.

Warum eine Extension nach dem Update nicht mehr passt

Die häufigste Ursache ist, dass die Extension auf Objekte, Felder oder Methoden der Basis-App verweist, die Microsoft in der neuen Version entfernt oder geändert hat. Microsoft kündigt solche Breaking Changes laut eigener Aussage mindestens ein Jahr im Voraus an. Zusätzlich warnt der AL-Compiler über den Obsolete-Mechanismus vor Elementen, die in künftigen Versionen wegfallen.

Der Lebenszyklus läuft in drei Schritten ab, wie Microsoft unter Obsolete objects, methods, and symbols in AL beschreibt:

1. Version A enthält das Objekt oder die Methode ganz normal.
2. Version B markiert es als veraltet und bietet eine Alternative an.
3. Version C entfernt es zugunsten der Alternative.

Für Tabellen, Felder, Seiten, Berichte und weitere Objekte geschieht das über die Eigenschaft ObsoleteState, ergänzt um ObsoleteReason (Begründung und Ersatz) und ObsoleteTag (Version). Methoden, Events und Variablen werden mit dem Attribut [Obsolete] markiert.

Die Abgrenzung von Warnung und Fehler steht in der Beschreibung der ObsoleteState-Eigenschaft: Verweise auf Pending erzeugen Warnungen, Verweise auf Removed Fehler. Wer die Warnungen über mehrere Versionen ignoriert, bekommt also irgendwann einen Fehler, und genau das blockiert dann das Update. Welche Funktionen Microsoft konkret abkündigt, listet die Seite Veraltete Funktionen.

Weitere Ursachen sind Konflikte mit anderen installierten Apps, Fehler im Upgrade-Code der Extension selbst oder inkompatible AppSource-Apps von Drittanbietern. Microsoft nennt als Gründe für fehlgeschlagene Updates ausdrücklich Kompatibilitätsprobleme von Per-Tenant-Extensions (PTEs), von Marketplace-Apps und interne Update-Probleme.

Die Phasen einer Hauptversion im Überblick

Microsoft veröffentlicht zwei Hauptversionen (Major Updates) pro Jahr, im April und im Oktober. Für jede gelten feste Phasen mit unterschiedlichem Spielraum für euch.

Für das Release vom Oktober 2026 heißt das grob: Update-Zeitraum bis Anfang März 2027, Kulanzphase im März 2027, danach Durchsetzung. Die genauen Termine eurer Umgebungen seht ihr im Admin Center.

Vorschauphase

In der Vorschauphase könnt ihr eine Sandbox auf der Vorschauversion anlegen und eure Extensions dort testen. Eine neu angelegte Vorschau-Sandbox enthält Demodaten. Alternativ könnt ihr eine bestehende Sandbox, zum Beispiel eine Kopie der Produktivumgebung, auf die Vorschauversion updaten. So testet ihr das Update mit euren Daten und euren installierten Extensions. Eine so aktualisierte Sandbox bekommt danach automatisch jede neue Vorschauversion und wird gelöscht, wenn ein solches Update fehlschlägt. Vorschau-Sandboxes werden 30 Tage nach dem offiziellen Release entfernt. Details stehen unter Vorbereitung auf neue Hauptversionen mit Vorschauumgebungen.

Parallel prüft Business Central PTEs in Produktivumgebungen automatisch auf technische Inkompatibilität mit dem kommenden Release und informiert die hinterlegten Benachrichtigungsempfänger. Wichtig: Microsoft prüft nur die technische Kompatibilität. Ob eure Prozesse fachlich noch richtig laufen, müsst ihr selbst testen.

Update-Zeitraum

Der Update-Zeitraum beginnt mit der allgemeinen Verfügbarkeit der neuen Version. Für bestehende Umgebungen steht das Update etwa eine Woche später bereit. Sobald es verfügbar ist, bekommen die Benachrichtigungsempfänger eine E-Mail, und Umgebungen mit aktivierter Telemetrie erhalten ein Signal mit dem Tag LC0100. Admins können den Termin im Admin Center auf jeden Tag innerhalb des Zeitraums legen.

Schlägt ein Update fehl, passiert Folgendes:

1. Die Umgebung wird auf die ursprüngliche Version zurückgesetzt, damit die Benutzer weiterarbeiten können.
2. Die Benachrichtigungsempfänger erhalten eine E-Mail mit Details zum Fehler.
3. Ein neuer Versuch wird automatisch sieben Tage später eingeplant.
4. Nach der Fehlerbehebung könnt ihr den Termin auf heute oder ein früheres Datum ziehen und so sofort einen neuen Versuch starten.

Ein Hinweis aus der Dokumentation: Wurde das fehlgeschlagene Update von Microsoft geplant und war die Zielversion nicht die neueste, kann der nächste Versuch auf die dann neueste verfügbare Version zielen.

Kulanzphase

In der Kulanzphase lässt sich das Update nicht mehr auf einen späteren Termin verschieben. Fehlgeschlagene Updates werden weiter nach sieben Tagen wiederholt; Admins können den Versuch nur vorziehen. Microsoft weist im Admin Center auf die bevorstehende Durchsetzung hin und kann zusätzlich Endbenutzer im Produkt informieren. Laut der Microsoft-Seite zur Wartung von Apps und PTEs muss der Kunde spätestens jetzt mit seinem Partner das Problem lösen.

Durchsetzungsphase

In der Durchsetzungsphase können Extensions, die das Update verhindern, automatisch deinstalliert werden, damit das Update gelingt. Die Daten dieser Extensions werden nicht gelöscht und lassen sich wiederherstellen, indem nach dem Update eine kompatible Version installiert wird. Eine kompatible Version wird aber nicht automatisch wieder installiert; darum müssen sich Kunde und Partner selbst kümmern.

Außerdem gilt: Nach einem erfolgreichen Update lässt sich die Umgebung nicht auf eine Version zurücksetzen, die sich bereits in der Kulanz- oder Durchsetzungsphase befindet.

Unabhängig von diesen Phasen gibt es eine Ausnahme: Verhindert eine inkompatible Extension ein kritisches Sicherheitsupdate, kann sie laut Microsoft innerhalb von 14 Tagen deinstalliert werden.

Extension nicht kompatibel: was Admins tun sollten

Admins sorgen vor allem dafür, dass Warnungen ankommen und Tests stattfinden. Dazu gehören diese Schritte:

1. Benachrichtigungsempfänger pflegen. Hinterlegt im Admin Center eine Sammeladresse statt einer einzelnen Person, damit Mails zu Inkompatibilitäten nicht in einem verwaisten Postfach landen. Die Einrichtung beschreibt Microsoft unter Benachrichtigungen im Admin Center.
2. Update-Termin bewusst setzen. Plant das Update der Produktivumgebung früh im Update-Zeitraum, damit nach einem Fehlschlag genug Zeit bleibt. Wie das geht, steht unter Updates im Admin Center verwalten.
3. Mit Produktivdaten testen. Sobald das Update verfügbar ist, kopiert ihr die Produktivumgebung in eine Sandbox, plant dort das Update auf heute und setzt die Option, dass es außerhalb des Update-Fensters laufen darf. So seht ihr vor dem Produktivupdate, ob alle Extensions mitkommen.
4. Kritische Abläufe durchspielen. Buchungen, Belegdruck, Schnittstellen und Jobwarteschlangen gehören in jeden Test, denn die automatische Prüfung von Microsoft erkennt nur technische Fehler.
5. App-Stand im Blick behalten. Im Admin Center seht ihr installierte Apps und verfügbare Updates, siehe Apps im Admin Center verwalten.

Wenn ihr Telemetrie nutzen wollt, verbindet die Umgebung mit Azure Application Insights, wie unter Telemetrie aktivieren beschrieben. Die Lebenszyklus-Ereignisse der Umgebung zeigen dann unter anderem, wann ein Update verfügbar ist und wie es verlaufen ist.

Extension nicht kompatibel: was Entwickler tun sollten

Entwickler sollten Obsolete-Warnungen behandeln wie Fehler mit Frist. Folgende Schritte helfen:

1. Warnungen auswerten. Kompiliert die Extension gegen die aktuelle und die kommende Version und geht jede Warnung zu Pending-Objekten durch. Der ObsoleteReason nennt in der Regel den Ersatz.
2. Gegen Vorabversionen bauen. Microsoft stellt Partnern Vorabversionen der nächsten Haupt- und Nebenversion über Docker bzw. die Insider-Artefakte bereit. Eine Build-Pipeline, die regelmäßig dagegen kompiliert, zeigt Probleme Monate vor dem Update.
3. Upgrade-Code prüfen. Fehler in Upgrade-Codeunits führen ebenfalls zu fehlgeschlagenen Updates. Testet das Upgrade mit realistischen Datenmengen in der Sandbox.
4. Abhängigkeiten klären. Prüft, ob eingesetzte AppSource-Apps für die neue Version freigegeben sind, und klärt das bei Bedarf mit dem Anbieter.
5. Bedingte Kompilierung nutzen, wo nötig. Microsoft selbst arbeitet laut den Best Practices zum Abkündigen von AL-Code mit Präprozessor-Symbolen wie CLEAN18. Für eigene Extensions, die mehrere Versionen bedienen müssen, kann das sinnvoll sein.

Beispiel: Eine Extension liest ein Feld der Basis-App, das Microsoft vor einigen Versionen auf Pending gesetzt hat. Die Warnung steht seitdem im Build-Log, niemand reagiert. Mit der Version, in der das Feld auf Removed wechselt, lässt sich die Extension nicht mehr kompilieren, und das Update scheitert. Die Korrektur ist meist überschaubar, sobald man den im ObsoleteReason genannten Ersatz einbaut.

Ob eure Extensions solche Altlasten enthalten, zeigt ein AL-Code-Review. Wenn ihr vor der Frage steht, ob eine Anpassung überhaupt als Extension weiterleben sollte, hilft der Artikel Extension oder Anpassung im Standard.

Was tun, wenn das Update bereits fehlgeschlagen ist?

Bei einem fehlgeschlagenen Update arbeitet ihr zunächst auf der alten Version weiter; es besteht also kein Datenverlust und meist kein Stillstand. Die Zeit bis zum nächsten Versuch solltet ihr trotzdem nutzen:

1. Fehlermail lesen und die betroffene Extension identifizieren.
2. Produktivumgebung in eine Sandbox kopieren und das Update dort nachstellen.
3. Extension gegen die neue Version kompilieren, Fehler beheben, neue Version bereitstellen.
4. Update in der Sandbox erneut ausführen, fachlich testen.
5. Update-Termin der Produktivumgebung vorziehen oder den automatischen Versuch abwarten.

Kritisch wird es, wenn ihr bereits in der Kulanz- oder Durchsetzungsphase seid, euer Partner nicht reagiert oder niemand mehr den Quellcode der Extension hat. Dann hilft schnelle Unterstützung bei Extension-Update-Fehlern weiter. Wenn das Problem im Kern an fehlender Betreuung liegt, lohnt ein Blick auf den Ablauf eines Partnerwechsels.

Häufige Fragen

Werden meine Daten gelöscht, wenn Microsoft eine Extension deinstalliert?

Nein. Laut Microsoft werden die Daten einer Extension, die in der Durchsetzungsphase automatisch deinstalliert wird, nicht gelöscht. Sie stehen wieder zur Verfügung, sobald nach dem Update eine kompatible Version der Extension installiert wird. Bis dahin fehlen aber die Funktionen der Extension, etwa Felder, Seiten oder Schnittstellen.

Wie lange habe ich Zeit, bis eine inkompatible Extension entfernt werden kann?

Ab dem Release einer Hauptversion läuft ein Update-Zeitraum von fünf Kalendermonaten, danach eine Kulanzphase von einem Monat. Erst in der anschließenden Durchsetzungsphase kann Microsoft blockierende Extensions deinstallieren. Eine Ausnahme sind kritische Sicherheitsupdates: Blockiert eine Extension ein solches Update, kann sie laut Microsoft innerhalb von 14 Tagen deinstalliert werden.

Kann ich ein Business-Central-Update überspringen oder dauerhaft verschieben?

Nein. In Business Central online könnt ihr den Termin für eine neue Hauptversion nur innerhalb des fünfmonatigen Update-Zeitraums frei wählen. In der anschließenden Kulanzphase von einem Monat lässt er sich nur noch vorziehen, nicht mehr verschieben. Danach setzt Microsoft das Update durch und kann blockierende Extensions deinstallieren. Dauerhaft auf einer alten Version zu bleiben ist in Business Central online damit nicht möglich.

Was ist der Unterschied zwischen ObsoleteState Pending und Removed?

Pending bedeutet, dass ein Objekt in einer künftigen Version entfernt wird; Verweise darauf erzeugen nur Compiler-Warnungen. Removed bedeutet, dass das Objekt nicht mehr verwendet werden kann; Verweise darauf erzeugen Compiler-Fehler, und die Extension lässt sich gegen diese Version nicht mehr bauen.

Kannst du eine Extension reparieren, die ein anderer Partner entwickelt hat?

Ja, wenn der Quellcode verfügbar ist, etwa im Repository des alten Partners oder in einer App-Datei, die ihn enthält, und ihr die Rechte daran habt. Ist kein Quellcode zugänglich, bleibt nur ein Nachbau der Funktion. Ich analysiere die Fehlermeldung, kompiliere die Extension gegen die neue Version und behebe die Inkompatibilitäten. Die erste Diagnose bekommt ihr innerhalb von 48 Stunden.

Reicht der automatische Kompatibilitätstest von Microsoft aus?

Nein. Microsoft prüft PTEs nur auf technische Kompatibilität. Ob Buchungslogik, Berichte und Schnittstellen nach dem Update fachlich korrekt arbeiten, müsst ihr selbst in einer Sandbox mit einer Kopie der Produktivdaten testen.

Wann ich helfen kann

Ich arbeite seit 2014 mit Navision und Business Central und repariere AL-Extensions, die nach einem Update nicht mehr kompatibel sind, auch wenn sie ursprünglich von einem anderen Partner stammen. Abrechnung nach Festpreis oder nach Aufwand ab 120 €/h, ohne Jahresvertrag. Im kostenlosen Erstgespräch (30 Minuten) klären wir, wie dringend es ist und was als Nächstes zu tun ist.

Erstgespräch buchen