Application modernisation
App-V
Microsoft Application Virtualization
App-V, Microsoft Application Virtualization, is a legacy application virtualisation format that delivers Win32 applications as isolated virtual apps rather than fully installing them onto the underlying operating system.
Why App-V matters in a Microsoft estate
App-V matters during Windows 11, Intune, Azure Virtual Desktop, and Cloud PC programmes because application blockers can delay the whole rollout. The practical question is whether the term helps capture, package, sign, deploy, or troubleshoot an app with less rework.
How App-V shows up in practice
Many estates adopted this model specifically to avoid the file and registry conflicts that installing many applications directly onto a shared VDI or Remote Desktop Session Host image used to cause. Its current status is precise and worth stating exactly, because it is often described more alarmingly than the facts support. The App-V client and Sequencer are not end of life: they moved to fixed extended support and continue to ship in Windows, receiving security fixes on the normal Windows servicing timeline. What genuinely reached end of support was the App-V server infrastructure specifically, the management and streaming server components used to publish and deliver App-V packages to endpoints centrally.
Because App-V is not being actively developed and adds no new features, most estates running it are planning a move to MSIX regardless of the server-support deadline, since MSIX is where Microsoft's ongoing investment and Windows 365 and Azure Virtual Desktop integration now sits. Converting existing packages depends heavily on which App-V generation they were built in. App-V 5.1 packages generally convert with reasonable reliability, since the MSIX Packaging Tool can convert directly from the `.appv` package file itself, either through its UI or from the command line. App-V 4.x packages cannot be converted directly at all.
Microsoft's own guidance here is to return to the original source installer and package that as MSIX instead, or, where that installer has been lost, to capture the running application from a live installation as the practical fallback. Even a successful format conversion is not the end of the work. Environment variables, startup shortcuts, file type associations, and any script assuming App-V's particular virtualisation and isolation behaviour commonly need explicit remediation once repackaged in MSIX, since the two formats do not virtualise applications in an identical way. This is why these specific compatibility issues account for most of the "it converted cleanly and then behaved oddly" reports across large-scale App-V to MSIX migration programmes.