Upgrade von alten Lösungen

Es gibt sie überall: Lösungen deren Fundament in Dynamics CRM 2013 oder 2016 gelegt wurde. Seitdem sind sie mitgewandert durch Versionssprünge und in die Cloud. Die Grundfunktionen funktionieren sonst hätten sie keine Daseinsberechtiung mehr. Aber unter der Oberfläche tragen sie Konstruktionen aus einer anderen Zeit und irgendwann steht die Frage im Raum wie man so etwas modernisiert.

Erst bewerten, dann anfassen

Der naheliegendste Fehler ist der Start ohne Bestandsaufnahme. Modernisierung ohne Inventar wird zur Endlosaufgabe, weil ständig Neues auftaucht. Die Bestandsaufnahme aus dem Solution-Export beantwortet vorab die Dimensionen: Wie viele klassische Workflows, wie viel Alt-JavaScript, welche abgekündigten Komponententypen, wie viele Formulare in Legacy-Bauart oder wie steht es um Dokumentation und Namenskonsistenz.

Aus diesen Zahlen ergibt sich die wichtigste Weiche: Lohnt die Modernisierung im Bestand oder ist ein Neuaufbau mit Datenübernahme ehrlicher? Als grobe Orientierung: Wenn mehr als die Hälfte der Logik auf abgelöster Technik läuft und die Dokumentation praktisch fehlt ist der Neuaufbau selten teurer als jede einzelne Altkonstruktion zu verstehen und umzubauen.

Die Reihenfolge im Bestand

Fällt die Entscheidung für den Bestand gilt im Grundsatz die Reihenfolge welche unter Refactoring von Dynamics-Lösungen steht. Erst messen, dann Altlasten entfernen, neu schneiden und konsolidieren. Zu allerletzt modernisieren. Jede Komponente die vorher rausfliegt muss nicht modernisiert werden.

Bei alten Lösungen rückt ein Punkt nach vorn: alles mit Abschaltdatum. Abgekündigte Endpunkte in Skripten und Komponenten für die Microsoft ein konkretes Ende genannt hat - das ist der Teil mit echtem Termindruck. Die große Masse ohne Termin wandert dagegen anlassbezogen. Dazu gehören klassische Workflows und Xrm.Page-Skripte. Wer ein Formular fachlich umbaut modernisiert dessen Skripte im selben Zug.

Zwei Stolpersteine aus der Praxis

Alte Lösungen enthalten oft Komponenten die sich gar nicht mehr neu anlegen lassen z.B. etwa Dialoge. Dialoge funktionierten nur im alten Web-Client der Ende 2020 abgeschaltet wurde und im Unified Interface starten sie nicht. Im Export stehen diese dann trotzdem. Ihre Schritte sind oft die einzige Beschreibung eines Ablaufs den die Anwender früher geführt durchlaufen haben. Vor dem Löschen deshalb lesen und klären ob und wie der Ablauf heute abgebildet ist. Gelöscht lässt sich ein Dialog nicht wieder anlegen.

Und: Alte Lösungen sind häufig unsegmentiert. Beim ersten Export aus einer modernisierten Entwicklungsumgebung wandert daher oft mehr mit als gedacht. Der Neuschnitt in segmentierte Solutions gehört deshalb früh in den Plan und nicht ans Ende.

Als Arbeitsumgebung für all das empfiehlt sich eine aus Produktion wiederhergestellte Kopie. Alte Lösungen verhalten sich gegen leere Testumgebungen oft anders als gegen den echten Bestand. Das gilt gerade bei Prozessen die auf vorhandene Daten reagieren. Diese Kopie macht Experimente gefahrlos und kostet nur etwas Zeit.

Modernisierung ist bei solchen Beständen weniger ein Projekt als eine Betriebsart. Eine Lösung die 12 Jahre gewachsen ist wird nicht in einem Quartal jung. Aber sie kann ab sofort mit jeder Änderung ein Stück jünger werden statt älter. Das ist der realistische Anspruch.