Dynamics 365 ist Cloud-Software. Änderungen kommen regelmäßig. Für ein validiertes System reicht deshalb eine einmalige Freigabe zum Go-live nicht. Entscheidend ist ein wiederholbarer Prozess, der jede relevante Änderung bewertet, risikobasiert testet und nachvollziehbar freigibt.
Die Update-Kadenz unterscheidet sich je Dynamics-365-Anwendung. Finance und Supply Chain erhalten vier Service Updates pro Jahr; Microsoft verlangt, dass Kunden mindestens zwei davon übernehmen. Customer-Engagement-Apps und Power Platform haben zwei große Release-Zyklen pro Jahr und zusätzlich laufende Service Updates. Business Central online hat zwei große Updatezyklen pro Jahr sowie monatliche Minor Updates.
Die Konsequenz für validierte Prozesse ist nicht, jedes Release vollständig neu zu testen. Die Konsequenz ist, dass jede relevante Änderung kontrolliert bewertet werden muss.
Microsoft Learn: Dynamics 365 Service Updates
Microsoft Learn: Business Central Updates
Der falsche Reflex ist entweder, jedes Release vollständig neu zu testen, oder Updates nur als IT-Thema zu behandeln. Dazwischen liegt der risikobasierte Weg: Erst wird bewertet, ob eine Änderung den validierten Scope berührt. Danach wird der notwendige Nachweis festgelegt.
Eine UI-Änderung außerhalb eines qualitätsrelevanten Prozesses kann ohne zusätzliche Tests freigegeben werden. Eine Änderung an Chargenlogik, Sperrbeständen, Freigaben, Schnittstellen oder regulatorischen Daten kann dagegen gezielte Regressionstests und eine dokumentierte Freigabe erfordern.
Jedes Release wird gegen denselben Bewertungsrahmen geprüft. So bleibt die Entscheidung unabhängig davon nachvollziehbar, ob es sich um Finance, Supply Chain, Business Central, Field Service oder eine Power-Platform-Komponente handelt.
| Frage | Entscheidung |
|---|---|
| Was hat sich geändert? | Release Notes, Feature-Änderungen, Fixes und technische Abhängigkeiten identifizieren. |
| Betrifft es den validierten Scope? | Änderung gegen Intended Use, Prozesse, Datenobjekte, Schnittstellen und Kontrollen bewerten. |
| Welches Risiko entsteht? | Auswirkung auf Produktqualität, Datenintegrität, Rückverfolgbarkeit und Compliance bestimmen. |
| Welcher Nachweis ist nötig? | Keine Aktion, dokumentierte Review, gezielter Test oder erweiterte Regression festlegen. |
Update Governance funktioniert dann, wenn sie kein Sonderprojekt ist, sondern Teil des normalen Application Lifecycle Managements. Rollen, Fristen und Nachweise müssen vor dem nächsten Release definiert sein.
Microsoft empfiehlt für Finance und Operations, Updates früh in einer Nicht-Produktivumgebung zu testen und automatisierte Regressionstests in den Release-Prozess einzubauen. Auch für Customer-Engagement-Apps und Power Platform empfiehlt Microsoft frühe Tests vor dem produktiven Rollout.
Für einen validierten Betrieb ergänzen wir diese technische Release Readiness um den regulatorischen Blick: Welche kritischen Anforderungen, Kontrollen und Datenflüsse müssen nach der Änderung erneut belegt werden?
Nicht: Zweimal im Jahr hektisch prüfen, was Microsoft geändert hat.
Sondern: Ein wiederholbarer Prozess mit festen Rollen, definierten Entscheidungskriterien, bekannten Testbausteinen und einer dokumentierten Freigabe.
So wird Update Governance vom Einzelereignis zum kontrollierten Betriebsprozess.
Im Validation Health Check prüfen wir bestehende Dynamics-365- und Power-Platform-Lösungen auch auf Change Control und Update Governance: Verantwortlichkeiten, Impact Assessment, Teststrategie, Nachweise und Freigaben. Sie erhalten klassifizierte Findings und eine konkrete Priorisierung für den nächsten Release-Zyklus.
Microsoft Learn: Stay current with Dynamics 365 service updates
Microsoft Learn: Finance and Operations service update availability
Microsoft Learn: Managing updates in Business Central
Der notwendige Validierungsumfang hängt vom Intended Use, dem validierten Scope, dem Risikoprofil und dem Qualitätsmanagementsystem des Herstellers ab. Nicht jede Änderung erfordert denselben Testumfang.
Stand: 17. August 2026
