Molti consigli di migrazione pubblicati in avvicinamento ad aprile 2026 dicevano che App-V stesse per finire. Non era esattamente così, e la differenza conta se state pianificando del lavoro basandovi su quello.
Ciò che ha raggiunto la fine del supporto è l'infrastruttura server di App-V. Il client e il Sequencer no. Sono passati al supporto esteso a novembre 2024 e proseguono lungo la tempistica di manutenzione di Windows.
Se avete ricostruito la vostra roadmap attorno a «App-V muore ad aprile», vale la pena rileggere ciò a cui vi siete davvero impegnati. Il lavoro può comunque essere quello giusto. L'urgenza che gli è stata attribuita probabilmente no.
Che cosa è arrivato davvero a fine supporto
La data è il 14 aprile 2026, e si applica a un elenco preciso.
Secondo la politica di ciclo di vita fisso di Microsoft, quel giorno ha ritirato la generazione di strumenti del Microsoft Desktop Optimization Pack. Application Virtualization Hosting for Windows Desktops è nell'elenco, insieme a BitLocker Administration and Monitoring, al Diagnostics and Recovery Toolset, a User Experience Virtualization e ad Advanced Group Policy Management. In termini App-V, «hosting» significa il server di gestione, il server di pubblicazione e il server di reporting, più i database dietro di essi.
Il client e il Sequencer sono trattati separatamente, e l'informativa di supporto App-V di Microsoft è esplicita in merito. Sono passati al supporto esteso fisso e non sono più deprecati. Per loro non esiste una nuova data di fine supporto.
Due dettagli spiegano perché il client sopravvive ai server. Il client App-V è distribuito dentro Windows Enterprise e Windows Education dalla versione 1607 di Windows 10, quindi è una funzionalità di Windows che abilitate anziché un prodotto separato che installate. Il Sequencer è confluito nel Windows Assessment and Deployment Kit. Entrambi seguono ora la tempistica di manutenzione di Windows.
Supporto esteso significa che Microsoft continua a distribuire la funzionalità come parte di Windows e continua a rilasciare correzioni di bug e di sicurezza, ma non accetterà modifiche di progettazione né nuove funzionalità. Non abbandonata. E nemmeno in sviluppo.
Che cosa significa in pratica
Due situazioni diverse, spesso confuse.
Se eseguite l'infrastruttura App-V completa, con server di gestione, pubblicazione e reporting, quella è la parte con una scadenza reale alle spalle. Eseguire un'infrastruttura server non supportata che fa da intermediario nella consegna delle applicazioni è un rischio concreto, e quella migrazione non è facoltativa.
Se consegnate pacchetti App-V senza quei server, tramite Intune, Configuration Manager o script contro il client, la vostra posizione è considerevolmente più comoda di quanto suggerissero i titoli. Il client è supportato. Avete tempo per pianificare come si deve.
La maggior parte dei parchi che vedo è nel secondo caso e crede di essere nel primo.
Potete chiarirlo in un minuto su qualsiasi dispositivo che esegua i pacchetti:
Get-AppvPublishingServer | Select-Object Name, Url
Get-AppvClientPackage -All | Select-Object Name, Version, PackageId
Se il primo comando restituisce un server di pubblicazione che punta a un URL interno, avete infrastruttura server nel percorso di consegna e un lavoro con una data sul groppone. Se non restituisce nulla mentre il secondo comando elenca pacchetti, quei pacchetti sono stati aggiunti e pubblicati localmente da Configuration Manager, da uno script Intune o da una task sequence, e non c'è alcun server coinvolto.
Eseguitelo su un campione rappresentativo anziché su una sola macchina. I parchi cresciuti nell'arco di un decennio sono raramente coerenti, ed è comune trovare un'unità di business ancora puntata a un server di pubblicazione che tutti gli altri hanno smesso di usare anni fa.
Due posizioni molto diverse, e la verifica che vi dice in quale delle due siete.
Perché la cosa è stata esagerata
In parte per onesta confusione fra «server App-V» e «App-V». In parte perché una scadenza è una ragione più convincente per avviare un progetto rispetto a «questo sta diventando gradualmente legacy».
Lo sfortunato effetto collaterale è che alcune organizzazioni hanno affrettato conversioni per cui non erano pronte, il che ha prodotto pacchetti che funzionano nei test e generano ticket di supporto in produzione. Una migrazione affrettata di un'applicazione difficile è peggio di una pianificata sei mesi dopo.
Costa anche credibilità internamente. Chiedete budget contro una scadenza che poi si scopre non applicarsi al vostro parco, e il prossimo progetto applicativo che proporrete partirà da una posizione peggiore di questo.
Che cosa è vero davvero
- I componenti server hanno raggiunto la fine del supporto. Migrate via da loro.
- Il client e il Sequencer sono in supporto esteso. Non smetteranno di funzionare a una data precisa.
- Il supporto esteso non è una strategia. È il tempo per eseguirne una.
- App-V non riceve nuovi investimenti. Tutto ciò che è nuovo accade attorno a MSIX e App Attach.
- App-V app attach è un modo supportato per continuare a eseguire pacchetti App-V esistenti su Azure Virtual Desktop senza allestire un server App-V vostro, ed è un'opzione concreta mentre pianificate il resto.
Vale la pena dire chiaramente che cosa il supporto esteso non vi compra. Non significa che il formato tenga il passo con la piattaforma. Non significa che un fornitore di applicazioni vi aiuterà ancora quando segnalate un guasto dall'interno di un ambiente virtuale. E non significa che i vostri packager sapranno ancora sequenziare fra tre anni, perché chi lo faceva bene tende a spostarsi verso i formati su cui si investe. Quest'ultimo è il vincolo che morde per primo nella maggior parte dei parchi, e nessuna politica di supporto lo risolve.
La lettura corretta non è «nessuna fretta». È «avete abbastanza tempo per farlo come si deve, quindi fatelo come si deve».
Pianificare senza il panico
La sequenza utile è la stessa che vale per qualsiasi migrazione di un parco applicativo, e inizia dal sapere che cosa avete.
Inventariate ciò che è davvero in uso. I parchi App-V accumulano pacchetti che nessuno avvia da due anni. Ognuno di quelli che migrate è fatica sprecata. Prima i dati di utilizzo, poi le decisioni. Se non avete telemetria d'uso, gli eventi di pubblicazione e di avvio sul client separano il vivo dall'archiviato abbastanza bene da poterci lavorare.
Ordinate per destinazione, non per età. Alcuni pacchetti diventano MSIX. Altri stanno meglio come pacchetti MSI o PowerShell App Deployment Toolkit. Alcuni andrebbero ritirati. Altri sono candidati ad App Attach in un parco di desktop virtuali. Deciderlo per applicazione, in anticipo, previene lo schema in cui tutto viene forzato verso MSIX e un terzo oppone resistenza.
I criteri che di solito risolvono la questione, nell'ordine in cui tendono ad applicarsi:
- Qualcuno la avvia ancora? Ritirare batte convertire ogni volta, ed è l'unica strada senza carico di test.
- Il fornitore distribuisce ancora un installer? Confezionate la versione corrente dalla sorgente anziché convertire un pacchetto costruito su una release di quattro versioni fa.
- Installa un driver o un servizio di sistema, o scrive in posizioni a livello di macchina che altre applicazioni leggono? Quello è un lavoro da MSI o PSADT, non da MSIX.
- Viene usata solo dentro un parco di desktop virtuali? App Attach può essere una destinazione migliore dell'installazione per dispositivo, e MSIX nativo rispetto ad App Attach espone il compromesso.
- È un pacchetto App-V 5.1 pulito in uso quotidiano? È la conversione più rapida disponibile e la forma giusta per il vostro primo passaggio.
Convertite prima quelle facili, per costruire la pipeline. Non la più difficile per dimostrare che si può fare. Volete un processo funzionante, una configurazione di firma che si comporti bene e un anello di test che colga davvero le cose, prima di incontrare i casi scomodi.
Aspettatevi che si rompano cose precise. App-V e MSIX gestiscono variabili d'ambiente, collegamenti, script e associazioni dei tipi di file in modo diverso, ed è lì che finisce davvero lo sforzo di conversione. Migrazione da App-V a MSIX copre ciò che tende ad andare storto e perché, e conversione da legacy a MSIX copre i comportamenti del contenitore che emergono dopo.
Tenete il pacchetto App-V finché il sostituto non è provato in produzione. Non finché non supera i test. Finché utenti reali non lo usano da due settimane. Tenete per un po' anche un ambiente di sequenziamento funzionante, perché la settimana in cui lo smontate è la settimana in cui trovate un altro pacchetto da ricostruire.
L'unica cosa che vale la pena fare ora
Stabilite in quale delle due situazioni siete. Se state eseguendo l'infrastruttura server, quella ha una scadenza reale collegata e andrebbe pianificata come si deve. Se non lo state facendo, vi è stato regalato del tempo, e l'uso migliore è l'inventario e lo smistamento anziché una corsa alle conversioni.
In entrambi i casi, il lavoro che ripaga è lo stesso: sapere che cosa avete, sapere che cosa ciascuna cosa dovrebbe diventare, e convertire deliberatamente. Un team che passa due settimane su inventario e instradamento di solito finisce l'intero parco più in fretta di uno che ha iniziato a convertire il primo giorno, perché non deve mai ricostruire i pacchetti che non avrebbe dovuto fare.
Dove si inserisce EtherApps Forge
EtherApps Forge cattura le applicazioni, anche da ambienti più datati e da versioni di Windows più vecchie, decide il percorso di packaging e produce output MSIX, MSI, PSADT o pronti per Intune dalla stessa cattura. La decisione di instradamento è la parte che conta qui, perché l'errore nella maggior parte delle migrazioni App-V non è la conversione in sé. È convertire cose che andavano ritirate, e forzare dentro MSIX cose che appartenevano altrove.
EtherApps Forge è un'applicazione desktop per Windows con una prova gratuita di 7 giorni, non un servizio ospitato, quindi le catture e gli output restano dentro il vostro ambiente. Il nostro percorso app legacy copre il lato scoperta e remediation, modernizzazione e migrazione delle applicazioni copre la pianificazione, e packaging e distribuzione MSIX copre firma, validazione e consegna una volta che il pacchetto esiste.
Esplora la modernizzazione delle applicazioni legacy
Iniziate dall'inventario e dalla decisione di instradamento, e le conversioni diventano la parte facile.