Mycket av migreringsråden som publicerades inför april 2026 sa att App-V skulle upphöra. Det stämde inte riktigt, och skillnaden betyder något om du planerar arbete utifrån det.
Det som nådde slutet på supporten var App-V:s serverinfrastruktur. Klienten och Sequencern gjorde det inte. De gick över till utökad support i november 2024 och fortsätter på Windows servicetidplan.
Byggde du om din färdplan kring "App-V är dött i april" är det värt att läsa om vad du faktiskt band dig till. Arbetet kan fortfarande vara rätt arbete. Brådskan som knöts till det var förmodligen inte det.
Vad som faktiskt nådde slutet på supporten
Datumet är den 14 april 2026, och det gäller en specifik lista.
Under Microsofts fasta livscykelpolicy pensionerade den dagen den generation verktyg som hör till Microsoft Desktop Optimization Pack. Application Virtualization Hosting for Windows Desktops finns med, jämte BitLocker Administration and Monitoring, Diagnostics and Recovery Toolset, User Experience Virtualization och Advanced Group Policy Management. I App-V-termer betyder "hosting" hanteringsservern, publiceringsservern och rapportservern, plus databaserna bakom dem.
Klienten och Sequencern hanteras separat, och Microsofts supportpolicy för App-V är tydlig med det. De har gått över till fast utökad support och är inte längre föråldrade. Det finns inget nytt slutdatum för support för dem.
Två detaljer förklarar varför klienten överlever servrarna. App-V-klienten har levererats inuti Windows Enterprise och Windows Education sedan Windows 10 version 1607, så den är en Windows-funktion du aktiverar snarare än en separat produkt du installerar. Sequencern flyttade in i Windows Assessment and Deployment Kit. Båda följer nu Windows servicetidplan.
Utökad support betyder att Microsoft fortsätter leverera funktionen som en del av Windows och fortsätter ge ut bugg- och säkerhetsfixar, men inte tar emot designändringar eller nya funktioner. Inte övergiven. Inte heller under utveckling.
Vad detta betyder i praktiken
Två olika situationer, som ofta förväxlas.
Kör du den fullständiga App-V-infrastrukturen, med hanterings-, publicerings- och rapportservrar, är det den del som har en verklig tidsgräns bakom sig. Att köra serverinfrastruktur utan support som förmedlar applikationsleverans är en verklig risk, och den migreringen är inte valfri.
Levererar du App-V-paket utan de servrarna, genom Intune, Configuration Manager eller skript mot klienten, är din position betydligt bekvämare än rubrikerna antydde. Klienten har support. Du har tid att planera ordentligt.
De flesta miljöer jag ser är det andra fallet och tror att de är det första.
Du avgör det på en minut på vilken enhet som helst som kör paketen:
Get-AppvPublishingServer | Select-Object Name, Url
Get-AppvClientPackage -All | Select-Object Name, Version, PackageId
Returnerar det första kommandot en publiceringsserver som pekar på en intern URL har du serverinfrastruktur i leveransvägen och ett daterat arbete framför dig. Returnerar det ingenting medan det andra kommandot listar paket lades de paketen till och publicerades lokalt av Configuration Manager, ett Intune-skript eller en aktivitetssekvens, och ingen server är inblandad alls.
Kör det över ett representativt urval snarare än på en maskin. Miljöer som vuxit under ett decennium är sällan konsekventa, och det är vanligt att hitta en affärsenhet som fortfarande pekar på en publiceringsserver alla andra slutade använda för flera år sedan.
Två mycket olika lägen, och kontrollen som talar om vilket du är i.
Varför detta överdrevs
Delvis ärlig förväxling mellan "App-V-server" och "App-V". Delvis för att en tidsgräns är ett mer övertygande skäl att starta ett projekt än "det här blir gradvis äldre teknik".
Den olyckliga sidoeffekten är att en del organisationer forcerade konverteringar de inte var redo för, vilket gav paket som fungerar i test och genererar supportärenden i produktion. En forcerad migrering av en svår applikation är sämre än en planerad sex månader senare.
Det kostar också trovärdighet internt. Be om budget mot en tidsgräns som visar sig inte gälla din miljö, så startar nästa applikationsprojekt du föreslår från ett sämre läge än det här gjorde.
Vad som faktiskt är sant
- Serverkomponenterna nådde slutet på supporten. Migrera bort från dem.
- Klienten och Sequencern är i utökad support. De kommer inte att sluta fungera ett visst datum.
- Utökad support är ingen strategi. Det är tid att genomföra en.
- App-V får inga nya investeringar. Allt nytt sker kring MSIX och App Attach.
- App-V app attach är ett sätt med support att fortsätta köra befintliga App-V-paket på Azure Virtual Desktop utan att sätta upp en egen App-V-server, vilket är ett verkligt alternativ medan du planerar resten.
Vad utökad support inte ger dig är värt att säga rakt ut. Det betyder inte att formatet håller jämna steg med plattformen. Det betyder inte att en applikationsleverantör fortfarande hjälper dig när du rapporterar ett fel inifrån en virtuell miljö. Och det betyder inte att dina paketerare fortfarande kan sekvensera om tre år, för de som gjorde det bra tenderar att röra sig mot de format som investeras i. Den sista är den begränsning som biter först i de flesta miljöer, och ingen supportpolicy löser den.
Den korrekta läsningen är inte "ingen brådska". Den är "du har tillräckligt med tid att göra det här ordentligt, så gör det ordentligt".
Att planera utan paniken
Den användbara ordningsföljden är densamma som gäller varje migrering av en applikationsmiljö, och den börjar med att veta vad du har.
Inventera vad som faktiskt används. App-V-miljöer samlar på sig paket ingen startat på två år. Varje sådant du migrerar är bortkastad möda. Användningsdata först, sedan beslut. Har du ingen användningstelemetri skiljer publicerings- och starthändelser på klienten det levande från det arkiverade tillräckligt väl för att arbeta med.
Sortera efter destination, inte efter ålder. Vissa paket blir MSIX. Vissa passar bättre som MSI- eller PowerShell App Deployment Toolkit-paket. Vissa bör avvecklas. Vissa är kandidater för App Attach i en virtuell skrivbordsmiljö. Att avgöra detta per applikation, i förväg, förhindrar mönstret där allt tvingas mot MSIX och en tredjedel gör motstånd.
Kriterierna som brukar avgöra, i den ordning de tenderar att gälla:
- Startar någon den fortfarande? Att avveckla slår att konvertera varje gång, och det är den enda vägen utan testbörda.
- Levererar leverantören fortfarande ett installationsprogram? Paketera den aktuella versionen från källan snarare än att konvertera ett paket byggt från en utgåva fyra versioner bakåt.
- Installerar den en drivrutin eller en systemtjänst, eller skriver till maskinomfattande platser andra applikationer läser? Det är ett jobb för MSI eller PSADT, inte för MSIX.
- Används den enbart inuti en virtuell skrivbordsmiljö? App Attach kan vara en bättre destination än installation per enhet, och inbyggd MSIX mot App Attach redogör för avvägningen.
- Är det ett rent App-V 5.1-paket i daglig användning? Det är den snabbaste konverteringen som finns och rätt form för din första omgång.
Konvertera de enkla först, för att bygga pipelinen. Inte den svåraste för att bevisa att det går. Du vill ha en fungerande process, en signeringskonfiguration som uppför sig, och en testring som faktiskt fångar saker, innan du möter de besvärliga fallen.
Räkna med att specifika saker går sönder. App-V och MSIX hanterar miljövariabler, genvägar, skript och filtypskopplingar olika, och de skillnaderna är där konverteringsarbetet faktiskt landar. Migrering från App-V till MSIX täcker vad som brukar gå fel och varför, och konvertering av äldre appar till MSIX täcker containerbeteendena som dyker upp efteråt.
Behåll App-V-paketet tills ersättaren är bevisad i produktion. Inte tills det klarar testerna. Tills verkliga användare använt det i två veckor. Behåll en fungerande sekvenseringsmiljö ett tag också, för veckan du river den är veckan du hittar ytterligare ett paket som behöver byggas om.
Den enda saken värd att göra nu
Fastställ vilken av de två situationerna du är i. Kör du serverinfrastrukturen har den en verklig tidsgräns knuten till sig och bör schemaläggas ordentligt. Gör du inte det har du fått tid, och den används bäst till inventering och sortering snarare än till en rusning av konverteringar.
Hur som helst är arbetet som lönar sig detsamma: vet vad du har, vet vad var och en ska bli, och konvertera medvetet. Ett team som lägger två veckor på inventering och dirigering blir vanligen klart med hela miljön snabbare än ett som började konvertera dag ett, för det behöver aldrig bygga om paketen det inte borde ha gjort.
Var EtherApps Forge passar in
EtherApps Forge fångar in applikationer, även från äldre miljöer och äldre Windows-versioner, beslutar paketeringsvägen, och producerar MSIX, MSI, PSADT eller Intune-färdig utdata från samma infångning. Dirigeringsbeslutet är den del som betyder något här, för misstaget i de flesta App-V-migreringar är inte konverteringen i sig. Det är att konvertera saker som borde ha avvecklats, och att tvinga in saker i MSIX som hörde hemma någon annanstans.
EtherApps Forge är en Windows-skrivbordsapplikation med en kostnadsfri provperiod på 7 dagar, inte en värdbaserad tjänst, så infångningar och utdata stannar inuti din egen miljö. Vår rutt äldre appar täcker sidan med upptäckt och åtgärder, applikationsmodernisering och migrering täcker planeringen, och MSIX-paketering och utrullning täcker signering, validering och leverans när ett paket väl finns.
Utforska modernisering av äldre applikationer
Börja med inventeringen och dirigeringsbeslutet, så blir konverteringarna den enkla delen.