An App-V to MSIX migration moves a legacy App-V application estate onto the modern MSIX packaging format so those applications keep running cleanly on Windows 11 and deploy through Intune. In practice the work is a short, repeatable sequence: assess the App-V estate, convert the packages that convert directly, fix any runtime gaps that surface, test on real devices, sign each package with a trusted certificate, then deploy through Intune with staged assignment rings. Some packages convert in minutes; others need a different route, and knowing which is which before you start is what keeps the project predictable.
Why organisations are moving off App-V
App-V still works, and Microsoft is explicit that teams whose App-V feature set continues to meet their needs are not forced to migrate. The reason so many estates are planning the move anyway is that the platform is now frozen. App-V is no longer being developed. The App-V client and sequencer moved to fixed extended support: they still ship in Windows and receive bug and security fixes, but no new features are added. The App-V server components went further: they were deprecated and their support ended in April 2026, so the server side of an App-V deployment is now past its supported life.
That combination of a frozen client and an unsupported server is why forward planning makes sense now, while there is time to do it calmly rather than against a deadline. Teams that need to keep running App-V packages on Azure Virtual Desktop without standing up App-V server infrastructure can use App-V app attach, the supported Microsoft path, which buys room to plan a proper move to MSIX.
What converts and what does not
Not every App-V package takes the same road to MSIX, and the dividing line is the App-V version.
The MSIX Packaging Tool converts App-V 5.1 packages directly. Point it at the .appv file, through the UI or the command line, and the tool translates the existing manifest into an MSIX package. Because the package information is already structured, this is the fastest, cleanest conversion available.
App-V 4.x packages are a different matter. Direct conversion is not supported, and Microsoft's recommendation is to go back to the original source installer and convert that to MSIX instead. Where the source installer has been lost, and in older estates it often has, a capture-first repackage from a live installation is the practical route: you treat the running application as the source of truth and rebuild it as a signed package.
Conversion also rarely ends at the package. Some applications behave differently inside an MSIX container, which redirects certain file and registry writes. Those runtime behaviours are fixed with the Package Support Framework (PSF), which applies targeted fix-ups and can run scripts at launch to prepare the environment the application expects.
Audit the App-V estate before you migrate
A migration is only as good as its inventory. Before converting anything, build a picture of what the estate contains and how it is used. The audit should capture:
- Package inventory. Every App-V package in circulation, with version, owner, and where it is published.
- Usage. Which packages are actively launched and by whom; dormant packages may not be worth migrating.
- App-V 4.x versus 5.x split. This decides the route per package: 5.1 converts directly, 4.x goes via the source installer or capture-first.
- Missing source media. Flag packages whose original installer is gone, because those are your capture-first candidates.
- Scripts and middleware. App-V scripts, runtimes, and shared dependencies that will need handling after conversion.
- Connection groups. Packages that run together need their relationships understood before they are split apart.
- Retirement candidates. Applications nobody uses, or that already have a modern replacement, should be retired rather than migrated.
The output is a per-package decision: convert directly, convert from source, capture-first, or retire. That list is the backbone of the whole project.
From App-V estate audit to signed MSIX packages deployed through Intune.
Choosing an App-V to MSIX migration method
With the audit in hand, each package can be pointed at the right method, which depends on its version, whether its source survives, and how many you have to move.
| Method | Best for | Automation level | Watch-outs |
|---|---|---|---|
| Manual repackaging | Applications with no App-V source and awkward install logic | Low, hands-on throughout | Slow and hard to repeat consistently between packagers |
| MSIX Packaging Tool conversion | App-V 5.1 packages with clean, well-understood behaviour | Medium, guided UI workflow | Only App-V 5.1 converts directly; 4.x needs the source installer |
| Scripted batch conversion (command-line template runs) | Large App-V 5.x estates converted in bulk | High, template-driven runs | Needs solid templates and per-app validation afterwards |
| Capture-first repackaging (EtherApps Forge) | App-V 4.x or packages whose source is lost | High, agentic with human review | Confirm licensing rights before recapturing an installed application |
The conversion workflow
Whatever method a package takes, the conversion itself follows a consistent shape.
Start on a clean machine. Use a clean, patched Windows 11 virtual or reference machine as the conversion environment, so you package the application and not the clutter of a working desktop.
Evaluate first. Understand the installer or App-V package before converting it, so you know whether it will convert cleanly and what it writes.
Convert. For an App-V 5.1 package, run the MSIX Packaging Tool. For a bulk run across a larger App-V 5.x estate, drive it from the command line with a template:
MsixPackagingTool.exe create-package --template C:\conversions\LineOfBusinessApp.xml -v
The template carries the package information and settings, so one configuration can be reused for later versions and scripted across many packages. Generate it once through the UI, then reuse it for batch runs.
Review the package. Open the resulting MSIX in the package editor and check the manifest, entry points, and capabilities before signing.
Apply PSF where needed. Where a converted application misbehaves inside the container, add the Package Support Framework with the fix-up it needs, including a launch script if the application expects one.
Testing, signing, and Intune deployment
A converted package is only a candidate until it is tested and signed.
Sign it. MSIX packages must be signed with a certificate the estate trusts before they will install on managed devices. There is no App-V signature to inherit, so the package takes your organisation's code-signing certificate, whose identity must match the publisher named in the manifest.
Test on representative devices. Install and exercise each package on real Windows 11 devices that match the target estate: check launch, core workflows, licensing activation, per-user settings, and uninstall, not simply that it installs.
Deploy through Intune with rings. Add the signed MSIX to Intune and assign it in stages: a pilot ring first, then broader rings, so a problem surfaces on a handful of devices rather than the whole estate.
A worked example
Consider two packages from the same audit.
The first is an App-V 5.1 line-of-business application in daily use, its behaviour well understood. It converts directly: the MSIX Packaging Tool reads the .appv file and produces an MSIX package in one pass. A Windows 11 pilot surfaces one blocker, the application relies on a launch script that set an environment variable the container did not carry over. A Package Support Framework fix-up runs that script at launch and it behaves. The package is signed, piloted on a small ring, then assigned more broadly in Intune.
The second is an older App-V 4.x package whose installer was lost years ago, with no source media to fall back to. Direct conversion is not available, so it takes the capture-first route instead: captured from a live installation, rebuilt as a signed MSIX, tested on Windows 11, and deployed the same way. Same destination, different road, and the audit told the team which each package needed before any time was spent.
App-V to MSIX migration questions, answered
Can App-V packages be converted directly to MSIX?
App-V 5.1 packages can: the MSIX Packaging Tool converts them directly from the .appv file, through the UI or the command line. App-V 4.x packages cannot; Microsoft recommends converting from the original source installer, or a capture-first repackage from a live installation where that installer is lost.
What tools are available for App-V to MSIX migration?
Microsoft's MSIX Packaging Tool handles direct App-V 5.1 conversion and scripted batch runs from the command line, and the Package Support Framework handles runtime fix-ups afterwards. For packages that cannot convert directly, a capture-first approach rebuilds the application from a running installation, which is where EtherApps Forge fits.
What breaks during conversion?
The common breakages are runtime behaviours the MSIX container changes: file or registry writes it redirects, launch scripts that set up the environment, and per-user configuration a machine-level conversion does not carry. Most are resolved with a Package Support Framework fix-up; App-V 4.x packages break the direct route entirely.
Do converted packages need re-signing?
Yes. Every MSIX package must be signed with a certificate the estate trusts before it will install on managed devices, and there is no App-V signature to reuse. Make sure the certificate identity matches the manifest publisher.
How do I deploy migrated MSIX apps with Intune?
Add the signed MSIX to Intune and assign it in staged rings, starting with a pilot group. Test on representative Windows 11 devices first, then widen ring by ring so any issue is caught early.
Where EtherApps Forge fits
Most App-V estates are a mix: App-V 5.1 packages that convert directly, and a stubborn tail of App-V 4.x or lost-source packages that do not. EtherApps Forge is built for that tail. As a capture-first packager, it captures the application from a live installation and rebuilds it, so a lost installer is no longer a dead end.
The workflow is agentic with human review: EtherApps Forge analyses the captured footprint and recommends a route, and a packager confirms it, rather than pretending difficult applications package themselves. Outputs span MSIX, MSI, PowerShell App Deployment Toolkit, IntuneWin, and App Attach, so one capture can feed Intune delivery or an Azure Virtual Desktop App Attach scenario. Prove it on one real application first with the 7-day free trial before committing the wider estate.
For the delivery side, see MSIX packaging and deployment, and for packages whose source has gone, modernise legacy Windows apps covers the lost-installer path. The companion guides on a capture-first path to MSIX for complex applications and how to repackage an application when the installer is lost go deeper, and agentic application packaging explains the automated capture-and-review model.
An App-V to MSIX migration is a planning job first and a packaging job second: audit the estate, route each package to the method that fits, fix the runtime gaps, sign, test, and deploy through Intune in rings. Do the audit well and the rest becomes routine.
Explore MSIX packaging and deployment for App-V to MSIX migration support across conversion, PSF fix-ups, signing, and Intune rollout.