En migrering från App-V till MSIX flyttar en äldre App-V-applikationsmiljö till det moderna MSIX-paketeringsformatet så att applikationerna fortsätter köra rent på Windows 11 och distribueras via Intune. I praktiken är arbetet en kort, upprepningsbar sekvens: inventera App-V-miljön, konvertera de paket som konverterar direkt, åtgärda eventuella runtimeluckor som dyker upp, testa på riktiga enheter, signera varje paket med ett betrott certifikat och distribuera sedan via Intune med stegvisa tilldelningsringar. Vissa paket konverterar på minuter; andra behöver en annan väg, och att veta vilket som är vilket innan du börjar är det som håller projektet förutsägbart.
Varför organisationer lämnar App-V
App-V fungerar fortfarande, och Microsoft är tydlig med att team vars App-V-funktionsuppsättning fortsätter att möta deras behov inte tvingas migrera. Anledningen till att så många miljöer ändå planerar flytten är att plattformen nu är frusen. App-V utvecklas inte längre. App-V-klienten och sequencern flyttades till fast utökad support: de levereras fortfarande i Windows och får bugg- och säkerhetsfixar, men inga nya funktioner läggs till. App-V-serverkomponenterna gick längre: de fasades ut och deras support upphörde i april 2026, så serversidan av en App-V-distribution är nu bortom sin stödda livslängd.
Den kombinationen av en frusen klient och en server utan support är varför framförhållning är förnuftig nu, medan det finns tid att göra det lugnt snarare än mot en deadline. Team som behöver fortsätta köra App-V-paket på Azure Virtual Desktop utan att sätta upp App-V-serverinfrastruktur kan använda App-V app attach, den stödda Microsoft-vägen, som ger utrymme att planera en ordentlig flytt till MSIX.
Vad som konverterar och vad som inte gör det
Inte alla App-V-paket tar samma väg till MSIX, och skiljelinjen är App-V-versionen.
MSIX Packaging Tool konverterar App-V 5.1-paket direkt. Peka det mot .appv-filen, via gränssnittet eller kommandoraden, så översätter verktyget det befintliga manifestet till ett MSIX-paket. Eftersom paketinformationen redan är strukturerad är detta den snabbaste, renaste konvertering som finns.
App-V 4.x-paket är en annan sak. Direkt konvertering stöds inte, och Microsofts rekommendation är att gå tillbaka till det ursprungliga källinstallationsprogrammet och konvertera det till MSIX i stället. Där källinstallationsprogrammet har gått förlorat, och i äldre miljöer har det ofta det, är en capture-first-ompaketering från en levande installation den praktiska vägen: du behandlar den körande applikationen som sanningskällan och bygger om den till ett signerat paket.
Konvertering slutar också sällan vid paketet. Vissa applikationer beter sig annorlunda inuti en MSIX-container, som omdirigerar vissa fil- och registerskrivningar. De runtimebeteendena åtgärdas med Package Support Framework (PSF), som tillämpar riktade fixar och kan köra skript vid start för att förbereda den miljö applikationen förväntar sig.
Inventera App-V-miljön innan du migrerar
En migrering är aldrig bättre än sin inventering. Innan du konverterar något, bygg en bild av vad miljön innehåller och hur den används. Inventeringen bör fånga:
- Paketinventering. Varje App-V-paket i omlopp, med version, ägare och var det publiceras.
- Användning. Vilka paket som aktivt startas och av vem; vilande paket kanske inte är värda att migrera.
- Uppdelning mellan App-V 4.x och 5.x. Detta avgör vägen per paket: 5.1 konverterar direkt, 4.x går via källinstallationsprogrammet eller capture-first.
- Saknade källmedia. Flagga paket vars ursprungliga installationsprogram är borta, eftersom det är dina capture-first-kandidater.
- Skript och middleware. App-V-skript, runtimes och delade beroenden som behöver hanteras efter konvertering.
- Anslutningsgrupper. Paket som körs tillsammans behöver få sina relationer förstådda innan de delas isär.
- Kandidater för avveckling. Applikationer som ingen använder, eller som redan har en modern ersättning, bör avvecklas snarare än migreras.
Utfallet är ett beslut per paket: konvertera direkt, konvertera från källa, capture-first, eller avveckla. Den listan är ryggraden i hela projektet.
Från App-V-miljöinventering till signerade MSIX-paket distribuerade via Intune.
Välja en metod för migrering från App-V till MSIX
Med inventeringen i handen kan varje paket pekas mot rätt metod, vilket beror på dess version, om dess källa överlever och hur många du måste flytta.
| Metod | Bäst för | Automatiseringsnivå | Att se upp med |
|---|---|---|---|
| Manuell ompaketering | Applikationer utan App-V-källa och besvärlig installationslogik | Låg, praktisk hela vägen | Långsam och svår att upprepa konsekvent mellan paketerare |
| MSIX Packaging Tool-konvertering | App-V 5.1-paket med rent, väl förstått beteende | Medel, guidat gränssnittsflöde | Endast App-V 5.1 konverterar direkt; 4.x behöver källinstallationsprogrammet |
| Skriptad batchkonvertering (mallkörningar via kommandorad) | Stora App-V 5.x-miljöer konverterade i bulk | Hög, mallstyrda körningar | Kräver solida mallar och validering per app efteråt |
| Capture-first-ompaketering (EtherApps Forge) | App-V 4.x eller paket vars källa är förlorad | Hög, agentisk med mänsklig granskning | Bekräfta licensrättigheter innan du återfångar en installerad applikation |
Konverteringsarbetsflödet
Oavsett vilken metod ett paket tar följer själva konverteringen en konsekvent form.
Börja på en ren maskin. Använd en ren, uppdaterad virtuell Windows 11-maskin eller referensmaskin som konverteringsmiljö, så att du paketerar applikationen och inte röran från ett arbetande skrivbord.
Utvärdera först. Förstå installationsprogrammet eller App-V-paketet innan du konverterar det, så att du vet om det konverterar rent och vad det skriver.
Konvertera. För ett App-V 5.1-paket, kör MSIX Packaging Tool. För en bulkkörning över en större App-V 5.x-miljö, styr det från kommandoraden med en mall:
MsixPackagingTool.exe create-package --template C:\conversions\LineOfBusinessApp.xml -v
Mallen bär paketinformationen och inställningarna, så att en konfiguration kan återanvändas för senare versioner och skriptas över många paket. Generera den en gång via gränssnittet och återanvänd den sedan för batchkörningar.
Granska paketet. Öppna det resulterande MSIX i paketredigeraren och kontrollera manifestet, startpunkterna och funktionerna innan signering.
Tillämpa PSF där det behövs. Där en konverterad applikation missköter sig inuti containern, lägg till Package Support Framework med den fix den behöver, inklusive ett startskript om applikationen förväntar sig ett.
Testning, signering och Intune-distribution
Ett konverterat paket är bara en kandidat tills det är testat och signerat.
Signera det. MSIX-paket måste signeras med ett certifikat som miljön betror innan de installeras på hanterade enheter. Det finns ingen App-V-signatur att ärva, så paketet tar din organisations kodsigneringscertifikat, vars identitet måste matcha utgivaren som namnges i manifestet.
Testa på representativa enheter. Installera och pröva varje paket på riktiga Windows 11-enheter som matchar målmiljön: kontrollera start, centrala arbetsflöden, licensaktivering, användarspecifika inställningar och avinstallation, inte bara att det installeras.
Distribuera via Intune med ringar. Lägg till den signerade MSIX i Intune och tilldela den i steg: en pilotring först, sedan bredare ringar, så att ett problem dyker upp på en handfull enheter snarare än hela miljön.
Ett genomarbetat exempel
Betrakta två paket från samma inventering.
Det första är en App-V 5.1 line-of-business-applikation i daglig användning, med väl förstått beteende. Det konverterar direkt: MSIX Packaging Tool läser .appv-filen och producerar ett MSIX-paket i en enda körning. En Windows 11-pilot avslöjar en blockerare: applikationen förlitar sig på ett startskript som satte en miljövariabel som containern inte förde över. En Package Support Framework-fix kör det skriptet vid start och den beter sig. Paketet signeras, pilottestas på en liten ring och tilldelas sedan bredare i Intune.
Det andra är ett äldre App-V 4.x-paket vars installationsprogram gick förlorat för flera år sedan, utan källmedia att falla tillbaka på. Direkt konvertering är inte tillgänglig, så det tar capture-first-vägen i stället: infångat från en levande installation, ombyggt till en signerad MSIX, testat på Windows 11 och distribuerat på samma sätt. Samma destination, en annan väg, och inventeringen berättade för teamet vad varje paket behövde innan någon tid lades ner.
Frågor om migrering från App-V till MSIX, besvarade
Kan App-V-paket konverteras direkt till MSIX?
App-V 5.1-paket kan det: MSIX Packaging Tool konverterar dem direkt från .appv-filen, via gränssnittet eller kommandoraden. App-V 4.x-paket kan inte; Microsoft rekommenderar att konvertera från det ursprungliga källinstallationsprogrammet, eller en capture-first-ompaketering från en levande installation där det installationsprogrammet är förlorat.
Vilka verktyg finns för migrering från App-V till MSIX?
Microsofts MSIX Packaging Tool hanterar direkt App-V 5.1-konvertering och skriptade batchkörningar från kommandoraden, och Package Support Framework hanterar runtimefixar efteråt. För paket som inte kan konvertera direkt bygger en capture-first-metod om applikationen från en körande installation, vilket är där EtherApps Forge passar in.
Vad går sönder under konverteringen?
De vanliga haverierna är runtimebeteenden som MSIX-containern ändrar: fil- eller registerskrivningar den omdirigerar, startskript som ställer in miljön, och användarspecifik konfiguration som en konvertering på maskinnivå inte för över. De flesta löses med en Package Support Framework-fix; App-V 4.x-paket bryter den direkta vägen helt.
Behöver konverterade paket signeras om?
Ja. Varje MSIX-paket måste signeras med ett certifikat som miljön betror innan det installeras på hanterade enheter, och det finns ingen App-V-signatur att återanvända. Se till att certifikatidentiteten matchar manifestets utgivare.
Hur distribuerar jag migrerade MSIX-appar med Intune?
Lägg till den signerade MSIX i Intune och tilldela den i stegvisa ringar, med start i en pilotgrupp. Testa först på representativa Windows 11-enheter, bredda sedan ring för ring så att varje problem fångas tidigt.
Var EtherApps Forge passar in
De flesta App-V-miljöer är en blandning: App-V 5.1-paket som konverterar direkt, och en envis svans av App-V 4.x- eller förlorad-källa-paket som inte gör det. EtherApps Forge är byggt för den svansen. Som en capture-first-paketerare fångar det applikationen från en levande installation och bygger om den, så att ett förlorat installationsprogram inte längre är en återvändsgränd.
Arbetsflödet är agentiskt med mänsklig granskning: EtherApps Forge analyserar det infångade fotavtrycket och rekommenderar en väg, och en paketerare bekräftar den, snarare än att låtsas att svåra applikationer paketerar sig själva. Utdata omfattar MSIX, MSI, PowerShell App Deployment Toolkit, IntuneWin och App Attach, så att en fångst kan mata Intune-leverans eller ett Azure Virtual Desktop App Attach-scenario. Bevisa det på en riktig applikation först med den kostnadsfria provperioden på 7 dagar innan du binder den bredare miljön.
För leveranssidan, se MSIX-paketering och utrullning, och för paket vars källa är borta täcker modernisera äldre Windows-appar vägen med förlorat installationsprogram. De kompletterande guiderna om en capture-first-väg till MSIX för komplexa applikationer och hur du ompaketerar en applikation när installationsprogrammet är förlorat går djupare, och agentisk applikationspaketering förklarar den automatiserade fångst-och-granskningsmodellen.
En migrering från App-V till MSIX är först ett planeringsjobb och sedan ett paketeringsjobb: inventera miljön, dirigera varje paket till metoden som passar, åtgärda runtimeluckorna, signera, testa och distribuera via Intune i ringar. Gör inventeringen väl så blir resten rutin.
Utforska MSIX-paketering och utrullning för stöd vid migrering från App-V till MSIX över konvertering, PSF-fixar, signering och Intune-utrullning.