Microsoft has been steering customers away from App-V for a long time now, and MSIX is the format it wants everything to land on instead. If your estate still has App-V packages in production, that's not an emergency, but it is a project worth planning deliberately rather than discovering mid-migration.

In short: Moving from App-V to MSIX is a re-packaging exercise, not a file-format conversion. Some packages convert cleanly through the MSIX Packaging Tool, but connection groups, customised sequencing and apps that break MSIX's stricter isolation rules need rebuilding, and some are remediated at runtime with Microsoft's Package Support Framework. Plan it as inventory, repackage, test-and-remediate, then phased rollout, rather than a single batch job.

Here's what actually changes between the two, why packages don't just convert automatically, and the plan we run to get through it cleanly.

What did App-V do, and why does MSIX replace it?

App-V virtualises applications into isolated "bubbles" that run without being fully installed on the underlying OS, sequenced by capturing the install process into a virtualised package. It solved real problems in its day: application conflicts, easier delivery to virtual desktops, and cleaner uninstalls.

MSIX is Microsoft's modern, native Windows packaging format. It uses container-based isolation built into Windows 10 and 11 rather than a separate virtualisation layer, integrates with Intune and the Company Portal for deployment, and pairs with Windows App Attach to stream applications into Azure Virtual Desktop or Windows 365 without baking them into a base image. It's the actively developed path; App-V is the one Microsoft has been quietly retiring capability from for years.

Why don't App-V packages just convert to MSIX?

The tempting assumption is that an existing App-V package can be waved through some converter and come out the other side as MSIX, ready to go. In practice, a genuine App-V estate usually has some proportion of packages that don't translate cleanly.

Flow diagram: inventory App-V packages, repackage to MSIX, test and remediate, then phased rollout
Treat this as four distinct stages, not one conversion step.
  • Connection groups, App-V's mechanism for letting virtualised packages share components with each other, have no direct MSIX equivalent and need re-thinking, not converting.
  • Package-in-package setups and deeply customised sequencing behaviour often need to be rebuilt against how MSIX actually isolates applications, rather than assumed to carry over.
  • Legacy application quirks picked up during the original App-V sequencing, registry redirection tricks, specific driver dependencies, sometimes surface as new problems once the isolation model changes underneath them.

"App-V to MSIX isn't a file format conversion. It's a re-packaging exercise that happens to reuse most of what you already know about the application."

None of this makes MSIX harder to reach, it just means every package needs a real look, not a batch conversion assumed to work.

What are MSIX's limitations, and where does the PSF help?

MSIX is stricter than App-V about how an application is allowed to behave, and that's deliberate: the tighter container is what makes MSIX clean to install and clean to remove. But it means some legacy behaviour that App-V tolerated will not run unaltered under MSIX, and it's worth knowing where those edges are before you package rather than after.

The common sticking points are consistent across estates:

  • Apps that write into their own install directory. MSIX presents the install folder as read-only. Older applications that drop config, logs or licence files next to the executable have to be redirected elsewhere.
  • Kernel-mode components, NT services and drivers. MSIX packages user-mode applications. Anything that installs a Windows service or a device driver can't be delivered as a straightforward MSIX package.
  • Certain shell extensions, COM registrations and inter-process integrations may need declaring explicitly in the manifest, and some deeply embedded ones aren't supported at all.
  • Mandatory code signing. Every MSIX package must be signed with a certificate the target devices trust. That's a security gain, but it's a step App-V didn't force, so signing and certificate management become part of the process.

This is where Microsoft's Package Support Framework (PSF) earns its keep. The PSF is an open-source set of runtime "fixups" that sit inside the package and intercept an application's calls, redirecting a write that would have hit the read-only install folder to a writable location, correcting a hard-coded working directory, or smoothing over a path assumption the application makes. Rather than rewriting the application, you apply a targeted fixup so it behaves correctly inside the MSIX container. A good proportion of the packages that "won't convert" on the first pass become perfectly deliverable once the right PSF fixup is in place, and knowing which fixup to reach for is most of what separates a smooth migration from a stalled one.

What migration plan avoids surprises?

This is the order we run it in with clients, and skipping a stage is usually where projects lose time later rather than save it.

  1. Inventory every App-V package actually in use. Not what's documented, what's genuinely being delivered to users today, including anything quietly still running on an old sequencer nobody's touched in years.
  2. Prioritise and retire before you repackage. Some App-V packages are for applications nobody uses any more. Confirming that now is cheaper than repackaging something you're about to decommission anyway.
  3. Repackage into MSIX, rebuilding connection groups and any customised sequencing behaviour against MSIX's isolation model rather than assuming a like-for-like conversion.
  4. Test and remediate properly, not just "does it open," but real use: the specific workflows, printers, integrations and edge cases the original App-V sequencing was built to handle.
  5. Roll out in phases, validating against a representative pilot group before the whole estate moves, the same discipline that makes any packaging or OS migration go smoothly.
  6. Decommission the App-V infrastructure once everything's genuinely moved, rather than leaving the management server running indefinitely "just in case."

Where does App Attach fit in?

Once applications are packaged as MSIX, Windows App Attach lets them stream into Azure Virtual Desktop or Windows 365 sessions on demand, rather than being baked into every image. That means a lighter, faster-to-update base image and applications that can be assigned per user or per group without a full image rebuild, a meaningful operational improvement over how App-V packages were typically delivered to virtual desktops.

Where this leaves you

App-V isn't switching off overnight, but the direction of travel has been clear for a long time, and every package migrated now is one less thing to migrate under pressure later. Systech's Application Packaging & MSIX service runs this exact process, inventory, repackaging, remediation and phased rollout, so your App-V estate moves to a format Microsoft is actually still investing in, without each package becoming its own unplanned fire drill. If you'd rather this never become a manual bottleneck again, we also build CI/CD application packaging workflows that automate the whole pipeline.

RM
Ryan Mangan

Founder & CTO of Systech IT Solutions, Microsoft MVP and Chartered Fellow of the BCS, and author of the bestselling Mastering Azure Virtual Desktop. Ryan has spent nearly two decades helping organisations adopt Azure, Microsoft 365 and modern workspace technology pragmatically.