MSIX vs. traditional packaging: a decision record
Context
MSIX gets pitched as the modern replacement for MSI and App-V, but "modern" isn't the same as "right for this app." This record captures the criteria used to decide, app by app, whether MSIX is worth it — written after packaging roughly 200 applications across three estates over the last two years.
The real trade-off
MSIX buys you: clean uninstall (no more registry/file-system drift), a container that isolates the app from the rest of the system, and an install mechanism that plays natively with Intune and the Microsoft Store for Business. It costs you: a packaging process that's less forgiving of anything an installer does outside the box (driver installs, service accounts running as SYSTEM, kernel-mode components, license daemons that phone home to a hardware fingerprint) and a debugging story that's meaningfully worse when something inside the container doesn't behave.
Decision criteria
| Signal | Leans MSIX | Leans traditional |
|---|---|---|
| App vendor ships an MSIX or is on the Microsoft Store | Yes | — |
App writes to HKLM outside its own install path at runtime | — | Yes |
| App installs a driver, filter driver, or kernel service | — | Strongly yes |
| App licensing keys off machine identity/MAC address | — | Yes (container network virtualisation can break this) |
| Multiple versions need to run side-by-side | Yes | — |
| App is web-based / Electron / self-contained | Yes | — |
| Team already has a mature App-V or Ivanti packaging pipeline and low app churn | — | Yes, don't rebuild it for its own sake |
What actually broke in practice
- Print drivers and scanner TWAIN drivers — anything with a kernel-mode component. Don't attempt MSIX for these; traditional install remains correct.
- Older Java-based line-of-business apps that shell out to
regsvr32post-install. The MSIX container blocks this silently in some configurations — the app installs "successfully" and then fails at first run with no useful error. - License daemons bound to a MAC address. MSIX's per-app network virtualisation changes what the app sees as its adapter. Confirm with the vendor before packaging, not after a failed pilot.
- Anything that needs a machine-wide shared folder for multi-user handoff (some CAD and imaging tools). The container's file redirection surprised more than one team here — test the actual multi-user workflow, not just single-user install.
Where MSIX has been a clean win
Modern LOB apps built in-house, Electron-based internal tools, and anything already Store-ready. For these, the clean uninstall alone is worth the packaging effort — no more "which of these six apps left files in Program Files (x86)" tickets.
The rule this settled into
Default to traditional packaging. Only reach for MSIX when the app is a known-good candidate (Store-ready, self-contained, no kernel components) or when side-by-side versioning is a hard requirement that traditional packaging can't solve cleanly. Don't adopt MSIX as a blanket standard and then spend the next year working around the apps that don't fit it.