Veel migratieadvies dat in de aanloop naar april 2026 verscheen, zei dat App-V zou eindigen. Dat klopte niet helemaal, en het verschil telt als u er werk op plant.
Wat het einde van de ondersteuning bereikte, was de serverinfrastructuur van App-V. De client en de Sequencer niet. Die gingen in november 2024 over naar extended support en volgen verder de servicingtijdlijn van Windows.
Hebt u uw roadmap herbouwd rond "App-V is dood in april", dan is het de moeite waard om te herlezen waaraan u zich werkelijk hebt verbonden. Het werk kan nog steeds het juiste werk zijn. De urgentie die eraan hing waarschijnlijk niet.
Wat werkelijk het einde van de ondersteuning bereikte
De datum is 14 april 2026, en hij geldt voor een specifieke lijst.
Onder het vaste levenscyclusbeleid van Microsoft zette die dag de generatie tooling van het Microsoft Desktop Optimization Pack op non-actief. Application Virtualization Hosting for Windows Desktops staat erop, naast BitLocker Administration and Monitoring, de Diagnostics and Recovery Toolset, User Experience Virtualization en Advanced Group Policy Management. In App-V-termen betekent "hosting" de managementserver, de publishingserver en de reportingserver, plus de databases erachter.
De client en de Sequencer worden apart behandeld, en het ondersteuningsbeleid voor App-V van Microsoft is daar expliciet over. Ze zijn overgegaan naar vaste extended support en zijn niet langer afgeschaft. Er is voor hen geen nieuwe einddatum voor ondersteuning.
Twee details verklaren waarom de client de servers overleeft. De App-V-client wordt sinds Windows 10 versie 1607 meegeleverd in Windows Enterprise en Windows Education, dus het is een Windows-functie die u inschakelt en geen apart product dat u installeert. De Sequencer verhuisde naar de Windows Assessment and Deployment Kit. Beide volgen nu de servicingtijdlijn van Windows.
Extended support betekent dat Microsoft de functie als onderdeel van Windows blijft meeleveren en bug- en beveiligingsfixes blijft uitbrengen, maar geen ontwerpwijzigingen of nieuwe functies accepteert. Niet verlaten. Ook niet in ontwikkeling.
Wat dit in de praktijk betekent
Twee verschillende situaties, die vaak worden verward.
Draait u de volledige App-V-infrastructuur, met management-, publishing- en reportingservers, dan is dat het deel met een echte deadline erachter. Serverinfrastructuur zonder ondersteuning draaien die applicatielevering bemiddelt is een reëel risico, en die migratie is niet optioneel.
Levert u App-V-packages zonder die servers, via Intune, Configuration Manager of scripts tegen de client, dan is uw positie aanzienlijk comfortabeler dan de koppen suggereerden. De client wordt ondersteund. U hebt tijd om goed te plannen.
De meeste omgevingen die ik zie zijn het tweede geval en denken dat ze het eerste zijn.
U beslecht het in een minuut op elk apparaat dat de packages draait:
Get-AppvPublishingServer | Select-Object Name, Url
Get-AppvClientPackage -All | Select-Object Name, Version, PackageId
Geeft het eerste commando een publishingserver terug die naar een interne URL wijst, dan hebt u serverinfrastructuur in het leveringspad en een klus met een datum eraan. Geeft het niets terug terwijl het tweede commando packages opsomt, dan zijn die packages lokaal toegevoegd en gepubliceerd door Configuration Manager, een Intune-script of een tasksequence, en is er helemaal geen server bij betrokken.
Draai het over een representatieve steekproef in plaats van op één machine. Omgevingen die over een decennium zijn gegroeid, zijn zelden consistent, en het komt vaak voor dat één bedrijfsonderdeel nog naar een publishingserver wijst die iedereen jaren geleden heeft losgelaten.
Twee heel verschillende posities, en de controle die u vertelt in welke u zit.
Waarom dit werd overdreven
Deels eerlijke verwarring tussen "App-V-server" en "App-V". Deels omdat een deadline een overtuigender reden vormt om een project te starten dan "dit wordt geleidelijk legacy".
Het ongelukkige neveneffect is dat sommige organisaties conversies doordrukten waar ze niet klaar voor waren, wat packages opleverde die het in de test doen en in productie supporttickets genereren. Een overhaaste migratie van een lastige applicatie is erger dan een geplande zes maanden later.
Het kost ook intern geloofwaardigheid. Vraag budget tegen een deadline die blijkt niet op uw omgeving van toepassing te zijn, en het volgende applicatieproject dat u voorstelt begint vanuit een slechtere positie dan dit.
Wat werkelijk waar is
- De servercomponenten bereikten het einde van de ondersteuning. Migreer ervan af.
- De client en de Sequencer zitten in extended support. Ze gaan niet op een specifieke datum stoppen met werken.
- Extended support is geen strategie. Het is tijd om er een uit te voeren.
- App-V krijgt geen nieuwe investering. Alles wat nieuw is, gebeurt rond MSIX en App Attach.
- App-V app attach is een ondersteunde manier om bestaande App-V-packages te blijven draaien op Azure Virtual Desktop zonder zelf een App-V-server op te tuigen, en dat is een echte optie terwijl u de rest plant.
Wat extended support u niet oplevert, is het waard om ronduit te zeggen. Het betekent niet dat het formaat gelijke tred houdt met het platform. Het betekent niet dat een applicatieleverancier u nog helpt wanneer u een fout meldt vanuit een virtuele omgeving. En het betekent niet dat uw packagers over drie jaar nog weten hoe ze moeten sequencen, want de mensen die het goed deden schuiven meestal op naar de formaten waarin wordt geïnvesteerd. Dat laatste is de beperking die in de meeste omgevingen het eerst bijt, en geen enkel ondersteuningsbeleid lost dat op.
De juiste lezing is niet "geen haast". Het is "u hebt genoeg tijd om dit goed te doen, dus doe het goed".
Plannen zonder de paniek
De nuttige volgorde is dezelfde die geldt voor elke migratie van een applicatieomgeving, en hij begint met weten wat u hebt.
Inventariseer wat werkelijk in gebruik is. App-V-omgevingen verzamelen packages die niemand in twee jaar heeft gestart. Elk daarvan dat u migreert is verspilde moeite. Eerst gebruiksgegevens, dan beslissingen. Hebt u geen gebruikstelemetrie, dan scheiden publicatie- en startgebeurtenissen op de client het levende van het gearchiveerde goed genoeg om mee te werken.
Sorteer op bestemming, niet op leeftijd. Sommige packages worden MSIX. Sommige zijn beter als MSI- of PowerShell App Deployment Toolkit-packages. Sommige moeten worden afgevoerd. Sommige zijn kandidaten voor App Attach in een virtuele desktopomgeving. Dit vooraf per applicatie beslissen voorkomt het patroon waarin alles richting MSIX wordt geduwd en een derde ervan terugvecht.
De criteria die het meestal beslechten, in de volgorde waarin ze doorgaans gelden:
- Start iemand hem nog? Afvoeren wint elke keer van converteren, en het is de enige route zonder testlast.
- Levert de leverancier nog een installer? Verpak de huidige versie vanuit de bron in plaats van een package te converteren dat is gebouwd uit een release van vier versies geleden.
- Installeert hij een driver of een systeemservice, of schrijft hij naar machinebrede locaties die andere applicaties lezen? Dat is een klus voor MSI of PSADT, niet voor MSIX.
- Wordt hij alleen ooit binnen een virtuele desktopomgeving gebruikt? App Attach kan een betere bestemming zijn dan installatie per apparaat, en native MSIX tegenover App Attach zet de afweging uiteen.
- Is het een schoon App-V 5.1-package in dagelijks gebruik? Dat is de snelste conversie die er is en de juiste vorm voor uw eerste ronde.
Converteer eerst de makkelijke, om de pipeline te bouwen. Niet de moeilijkste om te bewijzen dat het kan. U wilt een werkend proces, een signingconfiguratie die zich gedraagt, en een testring die daadwerkelijk dingen opvangt, voordat u de lastige gevallen tegenkomt.
Verwacht dat specifieke dingen breken. App-V en MSIX gaan anders om met omgevingsvariabelen, snelkoppelingen, scripts en bestandstypekoppelingen, en die verschillen zijn waar de conversie-inspanning werkelijk landt. Migratie van App-V naar MSIX behandelt wat er meestal misgaat en waarom, en legacy-naar-MSIX-conversie behandelt het containergedrag dat daarna opduikt.
Houd het App-V-package tot de vervanger zich in productie heeft bewezen. Niet tot het de test doorstaat. Tot echte gebruikers hem veertien dagen hebben gebruikt. Houd ook nog even een werkende sequencingomgeving aan, want de week waarin u die afbreekt is de week waarin u nog één package vindt dat een herbouw nodig heeft.
Het ene ding dat het waard is nu te doen
Stel vast in welke van de twee situaties u zit. Draait u de serverinfrastructuur, dan hangt daar een echte deadline aan en hoort die goed te worden ingepland. Doet u dat niet, dan hebt u tijd gekregen, en die besteedt u het best aan inventarisatie en sortering in plaats van aan een stormloop van conversies.
Hoe dan ook is het werk dat loont hetzelfde: weet wat u hebt, weet wat elk stuk moet worden, en converteer bewust. Een team dat veertien dagen aan inventarisatie en routering besteedt, is meestal sneller klaar met de hele omgeving dan een team dat op dag één begon te converteren, want het hoeft nooit de packages te herbouwen die het niet had moeten maken.
Waar EtherApps Forge past
EtherApps Forge legt applicaties vast, ook uit oudere omgevingen en oudere Windows-versies, beslist de packagingroute, en produceert MSIX, MSI, PSADT of Intune-klare uitvoer uit dezelfde capture. De routeringsbeslissing is het deel dat hier telt, want de fout in de meeste App-V-migraties is niet de conversie zelf. Het is dingen converteren die afgevoerd hadden moeten worden, en dingen in MSIX forceren die ergens anders thuishoorden.
EtherApps Forge is een Windows-desktopapplicatie met een gratis proefperiode van 7 dagen, geen gehoste dienst, dus captures en uitvoer blijven binnen uw eigen omgeving. Onze route legacy apps behandelt de kant van inventarisatie en herstel, applicatiemodernisering en -migratie behandelt de planning, en MSIX-packaging en uitrol behandelt signing, validatie en levering zodra een package bestaat.
Ontdek modernisering van legacy applicaties
Begin bij de inventarisatie en de routeringsbeslissing, en de conversies worden het makkelijke deel.