Beaucoup de conseils de migration publiés à l'approche d'avril 2026 affirmaient qu'App-V prenait fin. Ce n'était pas tout à fait exact, et la nuance compte si vous planifiez des travaux en vous appuyant dessus.
Ce qui a atteint la fin de support, c'est l'infrastructure serveur App-V. Pas le client ni le Sequencer. Ils sont passés en support étendu en novembre 2024 et poursuivent sur le calendrier de maintenance de Windows.
Si vous avez refait votre feuille de route autour de « App-V est mort en avril », il vaut la peine de relire ce à quoi vous vous êtes réellement engagé. Le travail reste peut-être le bon travail. L'urgence qui y était attachée, probablement pas.
Ce qui a réellement atteint la fin de support
La date est le 14 avril 2026, et elle s'applique à une liste précise.
Dans le cadre de la politique de cycle de vie fixe de Microsoft, ce jour-là a retiré la génération d'outils du Microsoft Desktop Optimization Pack. Application Virtualization Hosting for Windows Desktops en fait partie, aux côtés de BitLocker Administration and Monitoring, du Diagnostics and Recovery Toolset, d'User Experience Virtualization et d'Advanced Group Policy Management. En termes App-V, « hosting » désigne le serveur de gestion, le serveur de publication et le serveur de rapports, ainsi que les bases de données qui les sous-tendent.
Le client et le Sequencer sont traités séparément, et la politique de support App-V de Microsoft est explicite à ce sujet. Ils sont passés en support étendu fixe et ne sont plus dépréciés. Il n'existe aucune nouvelle date de fin de support pour eux.
Deux détails expliquent pourquoi le client survit aux serveurs. Le client App-V est livré dans Windows Enterprise et Windows Education depuis Windows 10 version 1607, c'est donc une fonctionnalité Windows que vous activez plutôt qu'un produit distinct que vous installez. Le Sequencer a rejoint le Windows Assessment and Deployment Kit. Tous deux suivent désormais le calendrier de maintenance de Windows.
Le support étendu signifie que Microsoft continue de livrer la fonctionnalité dans Windows et continue de publier des correctifs de bogues et de sécurité, mais n'acceptera ni changements de conception ni nouvelles fonctionnalités. Pas abandonné. Plus développé non plus.
Ce que cela signifie en pratique
Deux situations différentes, souvent confondues.
Si vous exploitez l'infrastructure App-V complète, avec des serveurs de gestion, de publication et de rapports, c'est la partie qui a une véritable échéance derrière elle. Exploiter une infrastructure serveur non prise en charge qui arbitre la livraison des applications est un risque réel, et cette migration n'est pas facultative.
Si vous livrez des packages App-V sans ces serveurs, via Intune, Configuration Manager ou des scripts s'appuyant sur le client, votre position est bien plus confortable que ne le laissaient entendre les titres. Le client est pris en charge. Vous avez le temps de planifier correctement.
La plupart des parcs que je vois relèvent du second cas et se croient dans le premier.
Vous pouvez trancher en une minute sur n'importe quel poste qui exécute les packages :
Get-AppvPublishingServer | Select-Object Name, Url
Get-AppvClientPackage -All | Select-Object Name, Version, PackageId
Si la première commande renvoie un serveur de publication pointant vers une URL interne, vous avez une infrastructure serveur dans le chemin de livraison et un chantier daté sur les bras. Si elle ne renvoie rien alors que la seconde liste des packages, ces packages ont été ajoutés et publiés localement par Configuration Manager, un script Intune ou une séquence de tâches, et aucun serveur n'est impliqué.
Exécutez-la sur un échantillon représentatif plutôt que sur une seule machine. Les parcs qui ont grandi sur une décennie sont rarement cohérents, et il est courant de trouver une entité encore pointée vers un serveur de publication que tout le monde a cessé d'utiliser il y a des années.
Deux positions très différentes, et la vérification qui vous dit dans laquelle vous êtes.
Pourquoi cela a été exagéré
En partie par confusion honnête entre « serveur App-V » et « App-V ». En partie parce qu'une échéance est une raison plus convaincante de lancer un projet que « ceci devient progressivement du patrimoine ».
L'effet secondaire fâcheux est que certaines organisations ont précipité des conversions pour lesquelles elles n'étaient pas prêtes, ce qui a produit des packages qui fonctionnent en test et génèrent des tickets de support en production. Une migration précipitée d'une application difficile vaut moins qu'une migration planifiée six mois plus tard.
Cela coûte aussi de la crédibilité en interne. Demandez un budget au nom d'une échéance qui s'avère ne pas concerner votre parc, et le prochain projet applicatif que vous proposerez partira d'une position plus faible que celui-ci.
Ce qui est réellement vrai
- Les composants serveur ont atteint la fin de support. Quittez-les.
- Le client et le Sequencer sont en support étendu. Ils ne vont pas cesser de fonctionner à une date précise.
- Le support étendu n'est pas une stratégie. C'est du temps pour en exécuter une.
- App-V ne reçoit pas de nouveaux investissements. Tout ce qui est nouveau se passe autour de MSIX et d'App Attach.
- App-V app attach est un moyen pris en charge de continuer à exécuter des packages App-V existants sur Azure Virtual Desktop sans monter votre propre serveur App-V, ce qui constitue une véritable option pendant que vous planifiez le reste.
Ce que le support étendu ne vous achète pas mérite d'être dit clairement. Cela ne veut pas dire que le format suit le rythme de la plateforme. Cela ne veut pas dire qu'un éditeur d'application vous aidera encore quand vous signalerez une anomalie depuis un environnement virtuel. Et cela ne veut pas dire que vos packagers sauront encore séquencer dans trois ans, car les gens qui le faisaient bien ont tendance à se tourner vers les formats dans lesquels on investit. C'est cette dernière contrainte qui mord en premier dans la plupart des parcs, et aucune politique de support ne la résout.
La bonne lecture n'est pas « rien ne presse ». C'est « vous avez assez de temps pour le faire correctement, alors faites-le correctement ».
Planifier sans la panique
La séquence utile est la même que pour toute migration de parc applicatif, et elle commence par savoir ce que vous avez.
Inventoriez ce qui sert réellement. Les parcs App-V accumulent des packages que personne n'a lancés depuis deux ans. Chacun de ceux-là que vous migrez est un effort gaspillé. Les données d'usage d'abord, les décisions ensuite. Si vous n'avez aucune télémétrie d'usage, les événements de publication et de lancement sur le client sépareront suffisamment bien le vivant de l'archivé pour travailler avec.
Triez par destination, pas par ancienneté. Certains packages deviennent des MSIX. D'autres valent mieux en MSI ou en packages PowerShell App Deployment Toolkit. Certains devraient être retirés. Certains sont candidats à App Attach dans un parc de bureaux virtuels. Décider cela par application, en amont, évite le schéma où tout est poussé vers MSIX et où un tiers résiste.
Les critères qui tranchent généralement, dans l'ordre où ils s'appliquent :
- Quelqu'un la lance-t-il encore ? Retirer vaut mieux que convertir à chaque fois, et c'est la seule route sans charge de tests.
- L'éditeur livre-t-il encore un installateur ? Packagez la version actuelle depuis la source plutôt que de convertir un package construit à partir d'une livraison vieille de quatre versions.
- Installe-t-elle un pilote ou un service système, ou écrit-elle dans des emplacements au niveau machine que d'autres applications lisent ? C'est un travail MSI ou PSADT, pas MSIX.
- N'est-elle utilisée qu'à l'intérieur d'un parc de bureaux virtuels ? App Attach est peut-être une meilleure destination qu'une installation par poste, et MSIX natif contre App Attach expose l'arbitrage.
- Est-ce un package App-V 5.1 propre en usage quotidien ? C'est la conversion la plus rapide disponible et la bonne forme pour votre première passe.
Convertissez les faciles d'abord, pour construire la chaîne. Pas la plus difficile pour prouver que c'est faisable. Vous voulez un processus qui fonctionne, une configuration de signature qui se tient et un anneau de test qui attrape réellement les problèmes, avant de rencontrer les cas épineux.
Attendez-vous à ce que des choses précises cassent. App-V et MSIX traitent différemment les variables d'environnement, les raccourcis, les scripts et les associations de types de fichiers, et ces différences sont là où l'effort de conversion atterrit réellement. Migration App-V vers MSIX couvre ce qui a tendance à mal tourner et pourquoi, et conversion des applications héritées vers MSIX couvre les comportements de conteneur qui apparaissent ensuite.
Conservez le package App-V jusqu'à ce que le remplaçant ait fait ses preuves en production. Pas jusqu'à ce qu'il passe les tests. Jusqu'à ce que de vrais utilisateurs s'en soient servis pendant quinze jours. Gardez aussi un environnement de séquencement opérationnel un moment, car la semaine où vous le démontez est celle où vous trouvez un package de plus à reconstruire.
La seule chose à faire dès maintenant
Établissez dans laquelle des deux situations vous êtes. Si vous exploitez l'infrastructure serveur, cela a une véritable échéance attachée et doit être planifié correctement. Si ce n'est pas le cas, on vous a offert du temps, et le meilleur usage à en faire est l'inventaire et le tri plutôt qu'une rafale de conversions.
Dans les deux cas, le travail qui paie est le même : savoir ce que vous avez, savoir ce que chaque élément doit devenir, et convertir délibérément. Une équipe qui passe quinze jours sur l'inventaire et l'orientation termine généralement tout le parc plus vite qu'une équipe qui a commencé à convertir dès le premier jour, car elle n'a jamais à reconstruire les packages qu'elle n'aurait pas dû faire.
La place d'EtherApps Forge
EtherApps Forge capture les applications, y compris depuis des environnements et des versions de Windows plus anciens, décide de la route de packaging, et produit des sorties MSIX, MSI, PSADT ou prêtes pour Intune à partir de la même capture. La décision d'orientation est ce qui compte ici, car l'erreur dans la plupart des migrations App-V n'est pas la conversion elle-même. C'est de convertir des choses qui auraient dû être retirées, et de forcer dans MSIX des choses qui avaient leur place ailleurs.
EtherApps Forge est une application de bureau Windows avec un essai gratuit de 7 jours, pas un service hébergé, donc les captures et les sorties restent dans votre propre environnement. Notre route applications héritées couvre le volet découverte et remédiation, modernisation et migration applicative couvre la planification, et packaging et déploiement MSIX couvre la signature, la validation et la livraison une fois qu'un package existe.
Découvrez la modernisation des applications héritées
Commencez par l'inventaire et la décision d'orientation, et les conversions deviennent la partie facile.