Business Central Extension Update Fehler
AL-Extension nach Release Wave reparieren
Business Central Extension nach Update defekt? Ich analysiere AL-Code, repariere inkompatible Extensions und mache sie fit für den nächsten Release-Zyklus.
Microsoft rollt Business Central SaaS zweimal im Jahr automatisch aus — im Frühjahr (Wave 1) und im Herbst (Wave 2). Unternehmen haben keine Wahl: Das Update kommt. Wer eine Custom-Extension betreibt, die veraltete AL-Objekte nutzt oder gegen geänderte Basis-Objekte programmiert ist, riskiert, dass diese Extension nach dem Update nicht mehr funktioniert.
Das Heimtückische: Der Fehler kündigt sich selten laut an. Microsoft gibt eine 90-Tage-Frist — wer die ObsoleteTag-Warnungen in seiner Extension nicht aktiv verfolgt, bemerkt das Problem erst, wenn die Funktion plötzlich fehlt. Manchmal mitten im laufenden Betrieb.
Das ist kein theoretisches Risiko. Es ist das häufigste akute Problem, mit dem mich BC-Kunden kontaktieren.
Wenn Microsoft Objekte als Obsolete markiert — also als veraltet — und deine Extension diese Objekte noch referenziert, kann die Extension beim nächsten Kompiliervorgang nicht mehr geladen werden. BC deaktiviert sie automatisch.
Typische Ursachen:
Ich analysiere deine Extension systematisch auf veraltete AL-Objekte: alle ObsoleteState-Tags, alle Referenzen auf deprecated Fields und Procedures, alle Stellen die bei der nächsten Release Wave brechen werden — nicht nur die, die schon gebrochen sind.
Das Ergebnis ist eine klare Übersicht: was ist akut kaputt, was ist die nächste Zeitbombe, was ist langfristig sauber.
Ich refactore den betroffenen AL-Code gegen aktuelle Microsoft-Standards. Das bedeutet:
Das Ziel ist nicht nur, dass die Extension heute wieder läuft — sondern dass sie beim nächsten Release-Zyklus nicht erneut bricht.
Wenn eine Extension tiefere strukturelle Probleme hat — zum Beispiel weil sie ursprünglich in C/AL geschrieben und mechanisch nach AL konvertiert wurde, ohne die Architektur anzupassen — gehe ich tiefer.
Ich erkenne solche Extensions an typischen Mustern: zu viele direkte Tabellenaufrufe statt Codeunits, fehlende Trennung von Business-Logik und UI, Verwendung von globalen Variablen wo event-basierte Kommunikation angebracht wäre. Diese Muster verursachen nicht nur Kompatibilitätsprobleme — sie sind auch der Hauptgrund für Performance-Probleme.
Du brauchst diese Unterstützung, wenn:
Ein Produktionsunternehmen betreibt eine Custom-Extension für die Fertigungsauftragserfassung — entwickelt vor vier Jahren, seitdem kaum angefasst. Nach der BC Release Wave 2025 Wave 2 lädt die Extension nicht mehr. Fehlermeldung: Kompilierungsfehler auf drei Tabellen-Fields.
Die Analyse zeigt: In zwei Jahren hatten sich über 15 deprecated Field-Referenzen angesammelt — einige mit ObsoleteState Removed, andere noch auf Pending. Drei Procedures hatten sich in der Basis-App geändert, ohne dass die Extension aktualisiert worden war.
Reparatur und Refactoring: zwei Tage Aufwand. Die Extension ist danach vollständig kompatibel mit der aktuellen BC-Version, alle ObsoleteTag-Warnungen beseitigt. Bei der nächsten Release Wave gibt es keine Überraschungen mehr.
Was ist der Unterschied zwischen ObsoleteState Pending und Removed?
Pending bedeutet: das Objekt ist als veraltet markiert, funktioniert aber noch. Microsoft gibt eine Frist — typischerweise bis zur übernächsten Major Version. Removed bedeutet: das Objekt existiert in der aktuellen BC-Version nicht mehr. Extensions die Removed-Objekte referenzieren, laden nicht mehr. Das ist der akute Notfall.
Kann ich meiner Extension ansehen ob sie beim nächsten Update Probleme macht?
Ja — der AL-Compiler gibt Warnungen für ObsoleteState-Pending-Referenzen aus. Das Problem: Viele Teams sehen diese Warnungen beim Build und ignorieren sie, weil sie noch keinen Fehler verursachen. Wenn aus Pending dann Removed wird, ist es zu spät. Ich kann eine Vorab-Analyse machen und dir zeigen was in den nächsten zwei Release-Zyklen kritisch wird.
Muss ich die Extension komplett neu schreiben lassen?
Meistens nicht. Die meisten Extension-Reparaturen sind gezielte Anpassungen an den veralteten Stellen — kein Neuschrieb. Nur wenn die ursprüngliche Architektur so grundlegend problematisch ist, dass Flicken langfristig teurer wird als neu bauen, empfehle ich einen Neuschrieb. Und das sage ich vorher klar.
Was wenn die Extension von einem anderen Entwickler stammt und es keine Dokumentation gibt?
Das ist der Normalfall. Ich analysiere AL-Code systematisch ohne Vorvissen — Tabellenstruktur, Event-Subscriptions, Codeunit-Aufrufe. Das dauert etwas länger als bei gut dokumentiertem Code, ist aber machbar.
Wie läuft das Erstgespräch ab?
30 Minuten. Du schilderst mir das Problem, ich sage dir ob und wie ich helfen kann — direkt, ohne Präsentation. Danach bekommst du eine schriftliche Einschätzung mit Aufwand und Vorgehen. Erst dann entscheidest du ob wir starten.
Kein Overhead, kein Vermittler — direkt mit mir sprechen.
Kein Jahresvertrag. Kein Mindestvolumen. Du zahlst für das gelöste Problem.
Weitere Themen: Business Central Notfall Support · AL Code Review Business Central · Business Central Performance optimieren
Über mich
Freiberuflicher BC-Entwickler und Consultant aus Bochum. Ich arbeite direkt mit eurem Fachbereich — ohne Agentur-Overhead, ohne Account-Staffelung. Remote und vor Ort in NRW verfügbar.
Mehr über mich und meine LeistungenSchreib mir eine Nachricht oder ruf direkt an.
