Analyse vor einer Dynamics-Migration

Eine Migrationsschätzung ist entweder auf eine Bestandsaufnahme gestützt oder sie ist geraten. Das klingt hart hat aber einen einfachen Grund: Der Aufwand einer Migration hängt kaum vom Ziel ab und fast vollständig vom Ausgangszustand. Und der Ausgangszustand ist bei gewachsenen Systemen grundsätzlich schlechter dokumentiert als alle Beteiligten glauben.

Die Fragen, die vor dem Angebot beantwortet sein müssen

Für den Sonderfall des Tenant-Wechsels gelten zusätzliche Prüfpunkte. Egal ob On-Premise in die Cloud oder Altsystem in einen Neuaufbau: Die Aufwandstreiber sind dieselben. Und sie lassen sich aus dem Solution-Export beziffern.

Wie groß ist das Datenmodell wirklich? Nicht die fünfzehn Tabellen über die alle reden sondern die Gesamtzahl inklusive der vergessenen, mit Feldzahl pro Tabelle. Jede Tabelle ist ein Migrationsobjekt mit Mapping, Transformation, Test und Abnahme.

Wie viel Logik hängt daran und auf welcher Technik? Klassische Workflows, Business Rules, Plug-in-Schritte, Flows, Skripte, jeweils gezählt. Der Anteil abgelöster Technik ist dabei die entscheidende Zahl. Denn was veraltet ist wird nicht migriert sondern neu gebaut und das ist ein anderes Preisschild.

Woran hängt das System nach außen? Abhängigkeiten zu anderen Lösungen und Außenverbindungen in Flows und Endpunkten. Jede dieser Verbindungen braucht im Ziel eine Entsprechung oder eine Abschaltentscheidung.

Und wie viel davon lebt überhaupt noch? Deaktivierte Prozesse, unreferenzierte Web-Ressourcen, Felder ohne Verwendung, globale Auswahllisten ohne Verweis. Alles was vor der Migration als tot bestätigt wird muss nicht mitgenommen werden. Nichts senkt den Migrationsaufwand so direkt wie ein kleinerer Migrationsumfang.

Ein Nebeneffekt dieser Zählung ist oft unbezahlbar: Sie zwingt zu Gesprächen welche sonst erst mitten im Projekt stattfinden. Wenn die Liste 40 Tabellen zeigt und die Fachabteilung nur 15 kennt ist das kein Analysefehler. Es ist der Moment in dem jemand die restlichen 25 zum ersten Mal seit Jahren anschaut (und meistens schreit dann plötzlich jemand "das ist aber wichtig!" ;).

Der Sonderfall Datenqualität

Eine Einschränkung: Der Export beziffert die Struktur, nicht die Daten. Dublettenquoten und Befüllungsgrade brauchen den Blick in die Umgebung selbst. Für die Projektplanung hat sich die Zweiteilung bewährt: Strukturanalyse aus dem Export vorab (auch ohne jeden Zugriff) und Datenanalyse als erster Projektschritt danach.

Was die Zahlen im Projekt bewirken

Der eigentliche Wert der Bestandsaufnahme ist nicht die Schätzung sondern die Verhandlungsbasis. Mit dem Inventar lässt sich der Migrationsumfang aktiv verkleinern: Diese 40 Tabellen kommen mit, diese 20 werden vorher stillgelegt. Diese Workflows werden im Zuge der Migration durch Flows ersetzt statt 1:1 übertragen. Ohne Inventar migriert man alles (sicherheitshalber) und das "Sicherheitshalber" ist dann der teuerste Posten des Projekts.

Die Bestandsaufnahme selbst ist der billigste Teil des ganzen Vorhabens. Sie an den Anfang zu setzen ist die einzelne Entscheidung mit dem besten Verhältnis von Kosten zu Risikoreduktion welche ein Migrationsprojekt treffen kann.