D365 Audit
Blog · 2026-08-22 · 5 min read
This article is currently available in German only. An English version may follow.

Verwaltete vs. Nicht Verwaltete Lösungen in Dynamics 365

Der Unterschied zwischen verwalteten und nicht verwalteten Lösungen entscheidet darüber, was Sie später noch ändern können. Was in der Praxis wirklich zählt.

Wer zum ersten Mal eine Lösung in Dynamics 365 importiert, stolpert früher oder später über diese Entscheidung: verwaltet oder nicht verwaltet. Die Antwort wirkt zunächst wie eine Formalie. Sie ist es aber nicht, denn sie legt fest, wie viel Bewegungsfreiheit Sie in der Zielumgebung erhalten wollen und wie aufwendig es wird, Anpassungen wieder zurückzunehmen.

Der Unterschied in einem Satz

Eine nicht verwaltete Lösung ist eine Arbeitskopie. Alles darin lässt sich weiter bearbeiten, und beim Löschen der Lösung bleiben die Komponenten in der Umgebung zurück. Eine verwaltete Lösung ist ein abgeschlossenes Paket. Ihre Komponenten sind gegen direkte Änderungen geschützt und beim Deinstallieren verschwinden sie samt der darin gespeicherten Daten.

Genau diese zweite Eigenschaft überrascht viele. Wer eine verwaltete Lösung deinstalliert, entfernt damit auch die Tabellen, die sie mitgebracht hat. Und mit den Tabellen die Datensätze darin.

Wo das in der Praxis wehtut

In der Entwicklungsumgebung arbeiten Sie fast immer in nicht verwalteten Lösungen. Das ist richtig so, denn dort müssen Sie Felder umbenennen, Formulare umbauen und Dinge wieder verwerfen können.

Der Fehler passiert einen Schritt später. Wird dieselbe nicht verwaltete Lösung auch in Test und Produktion importiert, entsteht dort ein zweiter bearbeitbarer Stand. Ab diesem Moment können Anpassungen direkt in Produktion vorgenommen werden, ohne dass sie je in der Entwicklung ankommen. Nach ein paar Monaten weiß niemand mehr sicher, welche Umgebung den wahren Stand hat.

Was für den Alltag daraus folgt

Die verbreitete Empfehlung lautet: in der Entwicklung nicht verwaltet arbeiten, nach Test und Produktion ausschließlich verwaltet ausliefern. Damit bleibt die Entwicklungsumgebung die einzige Quelle der Wahrheit, und niemand kann in Produktion unbemerkt an Formularen schrauben.

Diese Regel hat einen Preis. Sie brauchen einen funktionierenden Weg, Änderungen durch die Umgebungen zu schieben, und Sie müssen akzeptieren, dass schnelle Korrekturen direkt in Produktion nicht mehr möglich sind. Wer diesen Preis nicht zahlen will, sollte die Entscheidung wenigstens bewusst treffen statt sie zu übergehen.

Woran Sie erkennen, was Sie vor sich haben

Im Solution-Export steckt die Information im Manifest als Feld "Managed". Steht dort eine 0, ist die Lösung nicht verwaltet. In der Oberfläche von Power Apps sehen Sie es an der Spalte in der Lösungsübersicht.

Etwas kniffliger wird es, wenn eine Umgebung über Jahre gewachsen ist. Dann liegen dort oft mehrere Schichten übereinander: eine verwaltete Basis, darüber Anpassungen aus einer zweiten verwalteten Lösung, und ganz oben nicht verwaltete Änderungen, die jemand direkt vorgenommen hat. Welche Schicht am Ende gewinnt, folgt festen Regeln, ist aber ohne Werkzeug schwer zu durchschauen.

Vor dem Import in Produktion

Bevor eine Lösung in eine produktive Umgebung wandert, gehören drei Dinge geprüft. Jedes davon kann Importe scheitern lassen oder danach für Verwirrung sorgen.

  • Abhängigkeiten: Welche anderen verwalteten Lösungen müssen in der Zielumgebung bereits vorhanden sein? Fehlt eine davon, bricht der Import ab, und zwar erst nach mehreren Minuten Wartezeit.
  • Umgebungsspezifische Werte: Enthält die Lösung Umgebungsvariablen mit mitgeliefertem Wert? Diese Werte wandern beim Import mit und überschreiben in der Zielumgebung gerne eine korrekte Konfiguration mit der aus der Entwicklung.
  • Nicht verwaltete Reste: Gibt es in der Zielumgebung bereits nicht verwaltete Anpassungen an denselben Komponenten? Die haben Vorrang vor allem, was Sie verwaltet nachliefern, und führen zu dem klassischen Satz "bei mir sieht es aber anders aus".

Den Umstieg einer historisch gewachsenen Umgebung beschreibt Vorbereitung auf Managed Solutions. Wer tiefer einsteigen will, findet die nicht verwaltete Variante mit ihren Eigenheiten in einem eigenen Artikel zur Unmanaged Solution.

Kurz zusammengefasst

Nicht verwaltet heißt bearbeitbar und damit richtig für die Entwicklung. Verwaltet heißt geschützt und damit richtig für alles danach. Wer beides mischt, verliert nicht sofort etwas, aber schleichend die Übersicht darüber wo der echte Stand liegt.

Wie steht Ihre eigene Lösung da?

Laden Sie Ihren Solution-Export hoch und erhalten Sie in Minuten eine Auswertung: Sicherheitsrisiken, technische Schulden, Dokumentationsgrad und Migrationsrisiko. Kein Zugriff auf Ihre Umgebung nötig, erste Kennzahlen kostenlos.

Lösung analysieren