DSM nach PSADT migrieren

Was DSM anders macht

Ein DSM-Paket beschreibt eine Installation als Abfolge von Befehlen in einer script.inc. Es gibt keinen festen Phasenvertrag wie bei PSADT. Alles, was das Paket tut, steht in einer Datei — oft gewachsen, selten dokumentiert.

Für die Migration heißt das: Du übersetzt nicht ein Format, du rekonstruierst eine Absicht.

script.inc lesen

Der erste Schritt ist lesen, nicht konvertieren. Welche Befehle laufen? Welche Parameter sind gesetzt? Welche Dateien werden kopiert, welche Registry-Werte geschrieben? Welche Befehle sind auskommentiert, aber offensichtlich wichtig?

Diese Fragen beantwortet man am besten mit einer Notiz pro Befehl, nicht im Kopf.

Befehle zuordnen

Danach wird zugeordnet: Was muss vor dem Installer passieren (Pre-Install)? Was ist der Installer selbst (Install)? Was ist Konfiguration (Post-Install)? Was räumt auf (Uninstall)?

Alles, was sich nicht eindeutig zuordnen lässt, wird nicht geraten, sondern markiert.

Unbekannte Logik als Prüfpunkt

Ein Befehl, den niemand erklären kann, ist das größte Risiko der Migration. Er gehört in eine Liste mit der Frage: Was passiert, wenn wir ihn weglassen? Manchmal lautet die Antwort „nichts", manchmal „das Produkt startet nicht".

Diese Entscheidung braucht einen Menschen, keinen Konverter.

Testen nach der Migration

Die Migration ist fertig, wenn das neue Paket auf einem Gerät ohne Altinstallation funktioniert, sich deinstallieren lässt und danach keine Reste bleiben. Der Vergleich mit dem alten Paket gehört dazu: gleiche Dateien, gleiche Registry, gleiches Verhalten.

Ein Paket, das „installiert", aber nie deinstalliert wurde, ist nicht migriert, sondern nur verschoben.

Was PilotDeploy dabei tut

PilotDeploy liest DSM-Quellen lokal, ordnet Befehle zu und behält unbekannte Logik als Reviewpunkt. Der Payload bleibt erhalten, die Quellen verlassen das Gerät nicht. Was bleibt, ist die Entscheidung über die markierten Stellen — und der Test unter Windows.

---