Migrating DSM to PSADT

What DSM does differently

A DSM package describes an installation as a sequence of commands in a script.inc. There is no fixed phase contract like PSADT. Everything the package does lives in one file — often grown over time, rarely documented.

For migration that means: you are not converting a format, you are reconstructing an intent.

Reading script.inc

The first step is reading, not converting. Which commands run? Which parameters are set? Which files are copied, which registry values written? Which commands are commented out but obviously important?

Answer with a note per command, not from memory.

Mapping commands

Then map: what must happen before the installer (pre-install)? What is the installer itself (install)? What is configuration (post-install)? What cleans up (uninstall)?

Anything that cannot be mapped clearly is marked, not guessed.

Unknown logic as a review item

A command nobody can explain is the biggest migration risk. It belongs on a list with one question: what happens if we leave it out? Sometimes the answer is “nothing”, sometimes “the product will not start”.

That decision needs a human, not a converter.

Testing after migration

Migration is done when the new package works on a device without the old install, uninstalls cleanly and leaves no leftovers. Compare with the old package: same files, same registry, same behaviour.

A package that “installs” but was never uninstalled has been moved, not migrated.

What PilotDeploy does

PilotDeploy reads DSM sources locally, maps commands and keeps unknown logic as a review item. The payload stays; sources do not leave the device. What remains is the decision on the marked spots — and the test on Windows.

---