Una migrazione da App-V a MSIX sposta un parco applicativo App-V legacy sul formato di packaging moderno MSIX, così che quelle applicazioni continuino a funzionare in modo pulito su Windows 11 e si distribuiscano tramite Intune. In pratica il lavoro è una sequenza breve e ripetibile: valutare il parco App-V, convertire i pacchetti che si convertono direttamente, correggere eventuali lacune di runtime che emergono, testare su dispositivi reali, firmare ogni pacchetto con un certificato attendibile, poi distribuire tramite Intune con anelli di assegnazione graduali. Alcuni pacchetti si convertono in pochi minuti; altri richiedono un percorso diverso, e sapere quale sia quale prima di iniziare è ciò che rende il progetto prevedibile.
Perché le organizzazioni stanno abbandonando App-V
App-V funziona ancora, e Microsoft è esplicita: i team il cui insieme di funzionalità App-V continua a soddisfare le loro esigenze non sono obbligati a migrare. Il motivo per cui così tanti parchi pianificano comunque il passaggio è che la piattaforma è ormai congelata. App-V non è più in sviluppo. Il client e il sequencer App-V sono passati al supporto esteso fisso: vengono ancora forniti con Windows e ricevono correzioni di bug e di sicurezza, ma non vengono aggiunte nuove funzionalità. I componenti server di App-V sono andati oltre: sono stati deprecati e il loro supporto è terminato ad aprile 2026, quindi il lato server di una distribuzione App-V ha ormai superato la propria vita supportata.
Questa combinazione di un client congelato e di un server non supportato è il motivo per cui una pianificazione anticipata ha senso ora, finché c'è tempo per farla con calma anziché contro una scadenza. I team che devono continuare a eseguire pacchetti App-V su Azure Virtual Desktop senza allestire un'infrastruttura server App-V possono usare App-V app attach, il percorso supportato da Microsoft, che offre spazio per pianificare un passaggio come si deve a MSIX.
Cosa si converte e cosa no
Non tutti i pacchetti App-V prendono la stessa strada verso MSIX, e la linea di demarcazione è la versione di App-V.
Il MSIX Packaging Tool converte direttamente i pacchetti App-V 5.1. Puntatelo al file .appv, tramite l'interfaccia o la riga di comando, e lo strumento traduce il manifesto esistente in un pacchetto MSIX. Poiché le informazioni del pacchetto sono già strutturate, questa è la conversione più rapida e pulita disponibile.
I pacchetti App-V 4.x sono un'altra faccenda. La conversione diretta non è supportata, e la raccomandazione di Microsoft è di tornare all'installer sorgente originale e convertire quello in MSIX. Dove l'installer sorgente è andato perso, e nei parchi più datati capita spesso, un riconfezionamento capture-first da un'installazione live è la strada pratica: si tratta l'applicazione in esecuzione come fonte di verità e la si ricostruisce come pacchetto firmato.
La conversione raramente finisce al pacchetto. Alcune applicazioni si comportano in modo diverso all'interno di un contenitore MSIX, che reindirizza alcune scritture su file e registro. Questi comportamenti di runtime si correggono con il Package Support Framework (PSF), che applica correzioni mirate e può eseguire script all'avvio per preparare l'ambiente che l'applicazione si aspetta.
Verificate il parco App-V prima di migrare
Una migrazione vale solo quanto il suo inventario. Prima di convertire qualsiasi cosa, costruite un quadro di ciò che il parco contiene e di come viene usato. L'audit dovrebbe rilevare:
- Inventario dei pacchetti. Ogni pacchetto App-V in circolazione, con versione, proprietario e dove è pubblicato.
- Utilizzo. Quali pacchetti vengono attivamente avviati e da chi; i pacchetti dormienti potrebbero non valere la migrazione.
- Ripartizione App-V 4.x rispetto a 5.x. Questo decide il percorso per pacchetto: 5.1 si converte direttamente, 4.x passa dall'installer sorgente o da capture-first.
- Media sorgente mancante. Segnalate i pacchetti il cui installer originale è sparito, perché sono i vostri candidati capture-first.
- Script e middleware. Script App-V, runtime e dipendenze condivise che andranno gestiti dopo la conversione.
- Gruppi di connessione. I pacchetti che vengono eseguiti insieme richiedono che le loro relazioni siano comprese prima di essere separati.
- Candidati al ritiro. Le applicazioni che nessuno usa, o che hanno già un sostituto moderno, andrebbero ritirate anziché migrate.
L'esito è una decisione per pacchetto: convertire direttamente, convertire dalla sorgente, capture-first, oppure ritirare. Quell'elenco è la spina dorsale dell'intero progetto.
Dall'audit del parco App-V ai pacchetti MSIX firmati distribuiti tramite Intune.
Scegliere un metodo di migrazione da App-V a MSIX
Con l'audit in mano, ogni pacchetto può essere indirizzato al metodo giusto, che dipende dalla sua versione, dal fatto che la sua sorgente sopravviva e da quanti ne dovete spostare.
| Metodo | Ideale per | Livello di automazione | Punti di attenzione |
|---|---|---|---|
| Riconfezionamento manuale | Applicazioni senza sorgente App-V e con logica di installazione ostica | Basso, manuale dall'inizio alla fine | Lento e difficile da ripetere in modo coerente tra i packager |
| Conversione con MSIX Packaging Tool | Pacchetti App-V 5.1 dal comportamento pulito e ben compreso | Medio, workflow guidato da interfaccia | Solo App-V 5.1 si converte direttamente; 4.x richiede l'installer sorgente |
| Conversione batch scriptata (esecuzioni di modello da riga di comando) | Grandi parchi App-V 5.x convertiti in blocco | Alto, esecuzioni guidate da modello | Richiede modelli solidi e una validazione per applicazione a posteriori |
| Riconfezionamento capture-first (EtherApps Forge) | App-V 4.x o pacchetti la cui sorgente è persa | Alto, agentico con revisione umana | Confermate i diritti di licenza prima di ricatturare un'applicazione installata |
Il workflow di conversione
Qualunque metodo prenda un pacchetto, la conversione in sé segue una forma coerente.
Iniziate su una macchina pulita. Usate una macchina virtuale o di riferimento Windows 11 pulita e aggiornata come ambiente di conversione, così da confezionare l'applicazione e non il disordine di un desktop in uso.
Valutate prima. Comprendete l'installer o il pacchetto App-V prima di convertirlo, così da sapere se si convertirà in modo pulito e cosa scrive.
Convertite. Per un pacchetto App-V 5.1, eseguite il MSIX Packaging Tool. Per un'esecuzione in blocco su un parco App-V 5.x più ampio, pilotatela dalla riga di comando con un modello:
MsixPackagingTool.exe create-package --template C:\conversions\LineOfBusinessApp.xml -v
Il modello porta le informazioni e le impostazioni del pacchetto, quindi una configurazione può essere riutilizzata per versioni successive e scriptata su molti pacchetti. Generatelo una volta tramite l'interfaccia, poi riutilizzatelo per le esecuzioni batch.
Rivedete il pacchetto. Aprite il MSIX risultante nell'editor del pacchetto e controllate il manifesto, i punti di ingresso e le funzionalità prima di firmare.
Applicate PSF dove serve. Dove un'applicazione convertita si comporta male all'interno del contenitore, aggiungete il Package Support Framework con la correzione di cui ha bisogno, incluso uno script di avvio se l'applicazione se ne aspetta uno.
Test, firma e distribuzione Intune
Un pacchetto convertito è solo un candidato finché non viene testato e firmato.
Firmatelo. I pacchetti MSIX devono essere firmati con un certificato di cui il parco si fida prima che si installino sui dispositivi gestiti. Non c'è alcuna firma App-V da ereditare, quindi il pacchetto prende il certificato di firma del codice della vostra organizzazione, la cui identità deve corrispondere all'editore indicato nel manifesto.
Testate su dispositivi rappresentativi. Installate ed esercitate ogni pacchetto su dispositivi Windows 11 reali che rispecchiano il parco di destinazione: verificate l'avvio, i flussi di lavoro principali, l'attivazione delle licenze, le impostazioni per utente e la disinstallazione, non semplicemente che si installi.
Distribuite tramite Intune con anelli. Aggiungete il MSIX firmato a Intune e assegnatelo per fasi: prima un anello pilota, poi anelli più ampi, così che un problema emerga su una manciata di dispositivi anziché sull'intero parco.
Un esempio concreto
Considerate due pacchetti dello stesso audit.
Il primo è un'applicazione line-of-business App-V 5.1 in uso quotidiano, dal comportamento ben compreso. Si converte direttamente: il MSIX Packaging Tool legge il file .appv e produce un pacchetto MSIX in un solo passaggio. Un pilota su Windows 11 fa emergere un ostacolo, l'applicazione si affida a uno script di avvio che impostava una variabile d'ambiente che il contenitore non ha riportato. Una correzione Package Support Framework esegue quello script all'avvio e l'applicazione si comporta bene. Il pacchetto viene firmato, pilotato su un piccolo anello, poi assegnato più ampiamente in Intune.
Il secondo è un pacchetto App-V 4.x più datato il cui installer è andato perso anni fa, senza media sorgente a cui ripiegare. La conversione diretta non è disponibile, quindi prende invece la strada capture-first: catturato da un'installazione live, ricostruito come MSIX firmato, testato su Windows 11 e distribuito allo stesso modo. Stessa destinazione, strada diversa, e l'audit ha detto al team di cosa avesse bisogno ciascun pacchetto prima che venisse speso qualsiasi tempo.
Domande sulla migrazione da App-V a MSIX, con risposte
I pacchetti App-V possono essere convertiti direttamente in MSIX?
I pacchetti App-V 5.1 sì: il MSIX Packaging Tool li converte direttamente dal file .appv, tramite l'interfaccia o la riga di comando. I pacchetti App-V 4.x no; Microsoft raccomanda di convertire dall'installer sorgente originale, oppure un riconfezionamento capture-first da un'installazione live dove quell'installer è perso.
Quali strumenti sono disponibili per la migrazione da App-V a MSIX?
Il MSIX Packaging Tool di Microsoft gestisce la conversione diretta App-V 5.1 e le esecuzioni batch scriptate dalla riga di comando, e il Package Support Framework gestisce poi le correzioni di runtime. Per i pacchetti che non si convertono direttamente, un approccio capture-first ricostruisce l'applicazione da un'installazione in esecuzione, ed è qui che si inserisce EtherApps Forge.
Cosa si rompe durante la conversione?
Le rotture comuni sono comportamenti di runtime che il contenitore MSIX modifica: scritture su file o registro che reindirizza, script di avvio che predispongono l'ambiente, e configurazioni per utente che una conversione a livello di macchina non trasporta. La maggior parte si risolve con una correzione Package Support Framework; i pacchetti App-V 4.x rompono del tutto la strada diretta.
I pacchetti convertiti devono essere firmati di nuovo?
Sì. Ogni pacchetto MSIX deve essere firmato con un certificato di cui il parco si fida prima che si installi sui dispositivi gestiti, e non c'è alcuna firma App-V da riutilizzare. Assicuratevi che l'identità del certificato corrisponda all'editore del manifesto.
Come distribuisco le app MSIX migrate con Intune?
Aggiungete il MSIX firmato a Intune e assegnatelo in anelli graduali, iniziando da un gruppo pilota. Testate prima su dispositivi Windows 11 rappresentativi, poi allargate anello dopo anello così che ogni problema venga colto in anticipo.
Dove si inserisce EtherApps Forge
La maggior parte dei parchi App-V è un misto: pacchetti App-V 5.1 che si convertono direttamente, e una coda ostinata di pacchetti App-V 4.x o con sorgente persa che non lo fanno. EtherApps Forge è costruito per quella coda. In quanto strumento di packaging capture-first, cattura l'applicazione da un'installazione live e la ricostruisce, così che un installer perso non sia più un vicolo cieco.
Il workflow è agentico con revisione umana: EtherApps Forge analizza l'impronta catturata e raccomanda un percorso, che un packager conferma, anziché fingere che le applicazioni difficili si confezionino da sole. Gli output spaziano tra MSIX, MSI, PowerShell App Deployment Toolkit, IntuneWin e App Attach, così che una sola cattura possa alimentare una consegna Intune o uno scenario App Attach su Azure Virtual Desktop. Provatelo prima su una vera applicazione con la prova gratuita di 7 giorni prima di impegnare il parco più ampio.
Per il lato consegna, vedi packaging e distribuzione MSIX, e per i pacchetti la cui sorgente è sparita, modernizzare le app Windows legacy copre il percorso dell'installer perso. Le guide complementari su un percorso capture-first verso MSIX per applicazioni complesse e su come riconfezionare un'applicazione quando l'installer è perso approfondiscono, e il packaging di applicazioni agentico spiega il modello automatizzato di cattura e revisione.
Una migrazione da App-V a MSIX è prima di tutto un lavoro di pianificazione e solo poi un lavoro di packaging: verificate il parco, indirizzate ogni pacchetto al metodo che si adatta, correggete le lacune di runtime, firmate, testate e distribuite tramite Intune ad anelli. Fate bene l'audit e il resto diventa routine.
Esplora il packaging e distribuzione MSIX per un supporto alla migrazione da App-V a MSIX lungo conversione, correzioni PSF, firma e rollout Intune.