Business Central Extension Update Fehler Ruhrgebiet
Update-Ausfallzeit auf Null
BC Extension Update Fehler im Ruhrgebiet: Extension-Check vor dem Release schützt vor ungeplanten Ausfällen. Direkt erreichbar, kein Wartungsvertrag.
Im produzierenden Gewerbe des Ruhrgebiets bedeutet ein ungeplanter Systemausfall mehr als verlorene Bürozeit. Wenn Business Central nicht verfügbar ist, stehen Fertigungsaufträge, Lieferscheine können nicht gedruckt werden, Warenein- und -ausgänge hängen — und die Produktion merkt das innerhalb von Minuten.
Microsoft rollt zweimal im Jahr automatische Release Waves aus. Für SaaS-Umgebungen ist das Datum bekannt, die Installation ist nicht abwendbar. Unternehmen die Custom-Extensions betreiben, haben ein Risiko: wenn eine Extension gegen geänderte oder entfernte AL-Objekte programmiert ist, deaktiviert BC sie beim Update automatisch. Ohne Vorwarnung am nächsten Morgen.
Das trifft produzierende Betriebe im Ruhrgebiet besonders hart — nicht weil ihre Extensions schlechter wären als anderswo, sondern weil die Toleranz für ungeplante Ausfälle in der Produktion schlicht geringer ist als in einem Bürobetrieb. Eine Stunde Stillstand in einer Fertigungslinie hat direkte Kosten.
Die Antwort darauf ist nicht reaktiver Support nach dem Update — sondern präventiver Extension-Check vorher.
Das Problem mit Extension-Update-Fehlern ist, dass sie ankündbar sind. Microsoft markiert AL-Objekte als Obsolete und gibt eine Frist — typischerweise 90 Tage oder bis zum nächsten Release-Zyklus. Wer diese Warnungen kennt und ernst nimmt, hat Zeit zu handeln bevor der Fehler entsteht.
In der Praxis werden ObsoleteTag-Warnungen oft ignoriert — entweder weil niemand aktiv die Build-Logs liest, weil die Extension von einem Dritten gebaut wurde und niemand mehr wirklich draufschaut, oder weil Pending noch harmlos klingt und Removed erst beim nächsten Update zum echten Problem wird.
Ein präventiver Extension-Check vor dem Release macht folgendes:
Pending (Zeitbombe) als auch Removed (akut kaputt nach Update)Das Ziel: Update-Ausfallzeit null. Nicht durch Glück, sondern durch Vorbereitung.
Zwei bis vier Wochen vor dem offiziellen Microsoft-Release-Datum analysiere ich alle Custom-Extensions im System auf Kompatibilität mit der kommenden Version. Ergebnis: klare Übersicht aller Risikostellen, Bewertung der Kritikalität, Maßnahmenplan.
Das ist ein klar abgegrenzter Auftrag — kein laufender Wartungsvertrag, kein Jahresbeitrag. Du beauftragst den Check einmalig pro Release Cycle, wenn du ihn brauchst.
Ich führe die notwendigen AL-Refactorings durch, bevor das Update ausrollt. Veraltete Field-Referenzen ersetzen, Deprecated Procedures auf aktuelle Nachfolger umstellen, Event-Subscriptions modernisieren. Ziel ist nicht nur, dass die Extension heute kompatibel ist, sondern auch beim übernächsten Release keinen Anpassungsbedarf hat.
Wenn das Update bereits ausgerollt ist und eine Extension nicht mehr lädt: Sofortanalyse, Reparatur, Wiederinbetriebnahme. Ich kenne das Muster — deprecated Objects, geänderte Prozeduren, blockierte Job Queues — und arbeite mich schnell durch.
Für Produktionsunternehmen mit Fertigungs-Extensions analysiere ich zusätzlich die Architektur: Werden direkte Tabellenaufrufe verwendet die beim nächsten Microsoft-Update problematisch werden? Gibt es Stellen die bei hoher Produktions-Last Performance-Probleme verursachen? Das ist kein akademischer Review, sondern eine praxisorientierte Einschätzung für den laufenden Betrieb.
Diese Unterstützung ist besonders relevant, wenn:
Update-Ausfallzeit: von unbekannt auf null
Ein Automobilzulieferer im Ruhrgebiet betreibt zwei Custom-Extensions — eine für die Fertigungsauftragserfassung, eine für die Qualitätsprüfungs-Dokumentation mit Anbindung an ein Messdatensystem. Beide wurden vor vier Jahren gebaut und seitdem kaum angefasst.
Vor der BC Release Wave 2025 Wave 2 wird ein präventiver Check beauftragt. Befund: In der Fertigungsauftrags-Extension gibt es 11 Referenzen auf Felder und Prozeduren die in der kommenden Version auf Removed gesetzt werden. Drei davon betreffen den Kernprozess der Auftragserfassung — ohne diese Funktionen würde die Extension nach dem Update nicht mehr laden.
In der Qualitätsprüfungs-Extension gibt es zwei Pending-Referenzen, die erst im übernächsten Release-Zyklus kritisch werden würden — aber mitgemacht werden, solange die Extension sowieso angefasst wird.
Anpassungsaufwand vor dem Update: vier Arbeitstage. Das Update rollte planmäßig aus — ohne Ausfall, ohne Notfall-Hotline am nächsten Morgen, ohne Unterbrechung der Produktion.
Vier Arbeitstage Vorbereitung statt ungeplanter Produktionsstillstand und Notfallreparatur unter Zeitdruck.
Produzieren wir im Ruhrgebiet — kannst du schnell reagieren wenn etwas nach dem Update passiert?
Ja. Ich bin in Bochum ansässig und kenne die Situation produzierender Betriebe im Ruhrgebiet gut. Für Remote-Diagnose und Reparatur spielt die geografische Nähe keine direkte Rolle — ich arbeite über Fernzugriff. Die Nähe bedeutet aber, dass ich euren Betriebskontext verstehe und bei Bedarf schnell vor Ort bin.
Warum beauftrage ich dich statt meines bestehenden BC-Partners für den Check?
Für einen präventiven Check bin ich eine Ergänzung, keine Konkurrenz. Wenn euer Partner proaktiv über Update-Risiken kommuniziert und Extension-Checks selbst anbietet, dann ist das der richtige Weg. Wenn das nicht der Fall ist und ihr in den letzten Releases bereits Überraschungen erlebt habt, ist ein unabhängiger Check sinnvoll. Ich habe keinen Anreiz, Probleme größer darzustellen als sie sind.
Wie weit im Voraus muss der Check stattfinden?
Mindestens vier Wochen vor dem Release-Datum — besser sechs bis acht Wochen. Microsoft kommuniziert die Release Dates frühzeitig. Damit bleibt Zeit für die Analyse, die notwendigen Anpassungen, einen Testlauf und einen Puffer für unvorhergesehene Komplexität. Wer zwei Tage vorher anruft, bekommt eine Notfallreparatur — aber keine Vorbereitung mehr.
Unsere Extension wurde von einem externen Entwickler gebaut — kein Quellcode-Zugang bei uns. Können wir trotzdem einen Check machen?
Ja. Für einen Extension-Check brauche ich Zugriff auf das BC-System und idealerweise den AL-Quellcode. Wenn kein Quellcode vorliegt, kann ich über den App-Store oder direkten BC-Zugang zumindest den Ist-Zustand bewerten und euch sagen wo das Risiko liegt. Für die eigentliche Reparatur brauche ich allerdings den Quellcode oder die Kooperation des ursprünglichen Entwicklers.
Nächstes Release naht — jetzt prüfen statt nachher reparieren.
Weitere Themen: Business Central Extension Update Fehler · Dynamics 365 Berater Ruhrgebiet
Ü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.