Migrating packages: DSM and SCCM

What changes in a migration

A migration does not change the installer; it changes the wrapping. The vendor file stays the same. How it is installed, detected and uninstalled is rewritten. Treat it as “copy files over” and you get packages that install but never uninstall cleanly.

Reading legacy packages

A DSM package contains a script.inc with commands and a payload. The payload is usually reusable. The script logic has to be translated: which commands run in which order, which parameters are hard-coded, which checks exist.

Mapping commands

script.inc becomes install, post-install and uninstall steps. A long sequence becomes phases of a PSADT package. Anything that cannot be mapped clearly stays visible as a review item — not as a silently inherited command.

Unknown logic as a review item

The dangerous part of a migration is the command nobody can explain anymore. It does not belong in automatic conversion; it belongs on a list a human works through. A package that runs an unknown command is not progress.

Testing after migration

A migration succeeds only when the new package works on a device without the old install and uninstall leaves no leftovers. Compare against the old package: same files, same registry, same behaviour.

---