Una migración de App-V a MSIX traslada un estate de aplicaciones App-V heredado al moderno formato de empaquetado MSIX para que esas aplicaciones sigan funcionando limpiamente en Windows 11 y se desplieguen a través de Intune. En la práctica el trabajo es una secuencia corta y repetible: evaluar el estate de App-V, convertir los paquetes que se convierten directamente, corregir cualquier brecha de tiempo de ejecución que aparezca, probar en dispositivos reales, firmar cada paquete con un certificado de confianza y luego desplegar a través de Intune con anillos de asignación escalonados. Algunos paquetes se convierten en minutos; otros necesitan una ruta diferente, y saber cuál es cuál antes de empezar es lo que mantiene el proyecto predecible.
Por qué las organizaciones se están alejando de App-V
App-V sigue funcionando, y Microsoft es explícito en que los equipos cuyo conjunto de funciones de App-V sigue cubriendo sus necesidades no están obligados a migrar. La razón por la que tantos estates están planificando el cambio de todos modos es que la plataforma ahora está congelada. App-V ya no se desarrolla. El cliente y el sequencer de App-V pasaron a soporte extendido fijo: siguen incluyéndose en Windows y reciben correcciones de errores y de seguridad, pero no se añaden funciones nuevas. Los componentes de servidor de App-V fueron más allá: quedaron obsoletos y su soporte terminó en abril de 2026, así que el lado de servidor de un despliegue de App-V está ahora más allá de su vida soportada.
Esa combinación de un cliente congelado y un servidor sin soporte es la razón por la que planificar por adelantado tiene sentido ahora, mientras hay tiempo para hacerlo con calma en lugar de contra una fecha límite. Los equipos que necesitan seguir ejecutando paquetes App-V en Azure Virtual Desktop sin levantar infraestructura de servidor App-V pueden usar App-V App Attach, la ruta soportada de Microsoft, que da margen para planificar un traslado adecuado a MSIX.
Qué se convierte y qué no
No todo paquete App-V toma el mismo camino hacia MSIX, y la línea divisoria es la versión de App-V.
El MSIX Packaging Tool convierte los paquetes App-V 5.1 directamente. Apúntelo al archivo .appv, a través de la interfaz o la línea de comandos, y la herramienta traduce el manifiesto existente en un paquete MSIX. Como la información del paquete ya está estructurada, esta es la conversión más rápida y limpia disponible.
Los paquetes App-V 4.x son otra cuestión. La conversión directa no se soporta, y la recomendación de Microsoft es volver al instalador de origen original y convertir ese a MSIX en su lugar. Donde el instalador de origen se ha perdido, y en estates más antiguos a menudo lo ha hecho, un repackaging capture-first desde una instalación en vivo es la ruta práctica: trata la aplicación en ejecución como la fuente de la verdad y la reconstruye como un paquete firmado.
La conversión además rara vez termina en el paquete. Algunas aplicaciones se comportan de forma diferente dentro de un contenedor MSIX, que redirige ciertas escrituras de archivos y de registry. Esos comportamientos de tiempo de ejecución se corrigen con el Package Support Framework (PSF), que aplica ajustes específicos y puede ejecutar scripts en el arranque para preparar el entorno que la aplicación espera.
Audite el estate de App-V antes de migrar
Una migración es solo tan buena como su inventario. Antes de convertir nada, forme una imagen de lo que contiene el estate y de cómo se usa. La auditoría debería captar:
- Inventario de paquetes. Cada paquete App-V en circulación, con versión, propietario y dónde está publicado.
- Uso. Qué paquetes se inician activamente y por quién; los paquetes latentes quizá no merezcan la migración.
- División App-V 4.x frente a 5.x. Esto decide la ruta por paquete: 5.1 convierte directamente, 4.x va vía el instalador de origen o capture-first.
- Medios de origen ausentes. Marque los paquetes cuyo instalador original ha desaparecido, porque esos son sus candidatos capture-first.
- Scripts y middleware. Scripts de App-V, runtimes y dependencias compartidas que necesitarán manejo tras la conversión.
- Grupos de conexión. Los paquetes que se ejecutan juntos necesitan que se comprendan sus relaciones antes de separarlos.
- Candidatos a retirada. Las aplicaciones que nadie usa, o que ya tienen un reemplazo moderno, deberían retirarse en lugar de migrarse.
El resultado es una decisión por paquete: convertir directamente, convertir desde el origen, capture-first o retirar. Esa lista es la columna vertebral de todo el proyecto.
De la auditoría del estate de App-V a paquetes MSIX firmados desplegados a través de Intune.
Elegir un método de migración de App-V a MSIX
Con la auditoría en mano, cada paquete puede apuntarse al método adecuado, que depende de su versión, de si su origen sobrevive y de cuántos tiene que mover.
| Método | Ideal para | Nivel de automatización | A tener en cuenta |
|---|---|---|---|
| Repackaging manual | Aplicaciones sin origen App-V y con lógica de instalación complicada | Bajo, manual de principio a fin | Lento y difícil de repetir de forma consistente entre packagers |
| Conversión con MSIX Packaging Tool | Paquetes App-V 5.1 con comportamiento limpio y bien comprendido | Medio, flujo guiado por interfaz | Solo App-V 5.1 convierte directamente; 4.x necesita el instalador de origen |
| Conversión por lotes con scripts (corridas de plantilla por línea de comandos) | Estates App-V 5.x grandes convertidos en bloque | Alto, corridas basadas en plantillas | Necesita plantillas sólidas y validación por app después |
| Repackaging capture-first (EtherApps Forge) | App-V 4.x o paquetes cuyo origen está perdido | Alto, agéntico con revisión humana | Confirme los derechos de licencia antes de recapturar una aplicación instalada |
El flujo de conversión
Sea cual sea el método que tome un paquete, la conversión en sí sigue una forma consistente.
Empiece en una máquina limpia. Use una máquina virtual o de referencia Windows 11 limpia y parcheada como entorno de conversión, para que empaquete la aplicación y no el desorden de un escritorio de trabajo.
Evalúe primero. Comprenda el instalador o el paquete App-V antes de convertirlo, para saber si se convertirá limpiamente y qué escribe.
Convierta. Para un paquete App-V 5.1, ejecute el MSIX Packaging Tool. Para una corrida en bloque a través de un estate App-V 5.x más grande, condúzcalo desde la línea de comandos con una plantilla:
MsixPackagingTool.exe create-package --template C:\conversions\LineOfBusinessApp.xml -v
La plantilla lleva la información y los ajustes del paquete, así que una configuración puede reutilizarse para versiones posteriores y ejecutarse con scripts a través de muchos paquetes. Genérela una vez a través de la interfaz, luego reutilícela para corridas por lotes.
Revise el paquete. Abra el MSIX resultante en el editor de paquetes y revise el manifiesto, los puntos de entrada y las capabilities antes de firmar.
Aplique PSF donde haga falta. Donde una aplicación convertida se comporte mal dentro del contenedor, añada el Package Support Framework con el ajuste que necesita, incluido un script de arranque si la aplicación espera uno.
Pruebas, firma y despliegue en Intune
Un paquete convertido es solo un candidato hasta que se prueba y se firma.
Fírmelo. Los paquetes MSIX deben firmarse con un certificado en el que el estate confíe antes de que se instalen en dispositivos gestionados. No hay una firma de App-V que heredar, así que el paquete toma el certificado de firma de código de su organización, cuya identidad debe coincidir con el editor nombrado en el manifiesto.
Pruebe en dispositivos representativos. Instale y ejercite cada paquete en dispositivos Windows 11 reales que coincidan con el estate objetivo: compruebe el arranque, los flujos principales, la activación de licencia, los ajustes por usuario y la desinstalación, no solo que se instale.
Despliegue a través de Intune con anillos. Añada el MSIX firmado a Intune y asígnelo por etapas: primero un anillo piloto, luego anillos más amplios, para que un problema aparezca en un puñado de dispositivos en lugar de en todo el estate.
Un ejemplo trabajado
Considere dos paquetes de la misma auditoría.
El primero es una aplicación de negocio App-V 5.1 en uso diario, con su comportamiento bien comprendido. Convierte directamente: el MSIX Packaging Tool lee el archivo .appv y produce un paquete MSIX en una sola pasada. Un piloto en Windows 11 saca a la luz un bloqueador, la aplicación se apoya en un script de arranque que fijaba una variable de entorno que el contenedor no trasladó. Un ajuste del Package Support Framework ejecuta ese script en el arranque y se comporta. El paquete se firma, se pilota en un anillo pequeño y luego se asigna más ampliamente en Intune.
El segundo es un paquete App-V 4.x más antiguo cuyo instalador se perdió hace años, sin medios de origen a los que recurrir. La conversión directa no está disponible, así que toma la ruta capture-first en su lugar: capturado desde una instalación en vivo, reconstruido como un MSIX firmado, probado en Windows 11 y desplegado de la misma manera. Mismo destino, camino diferente, y la auditoría le dijo al equipo qué necesitaba cada paquete antes de gastar tiempo alguno.
Preguntas sobre la migración de App-V a MSIX, respondidas
¿Se pueden convertir los paquetes App-V directamente a MSIX?
Los paquetes App-V 5.1 sí: el MSIX Packaging Tool los convierte directamente desde el archivo .appv, a través de la interfaz o la línea de comandos. Los paquetes App-V 4.x no; Microsoft recomienda convertir desde el instalador de origen original, o un repackaging capture-first desde una instalación en vivo donde ese instalador se haya perdido.
¿Qué herramientas hay disponibles para la migración de App-V a MSIX?
El MSIX Packaging Tool de Microsoft se encarga de la conversión directa de App-V 5.1 y de las corridas por lotes con scripts desde la línea de comandos, y el Package Support Framework se encarga de los ajustes de tiempo de ejecución después. Para los paquetes que no se pueden convertir directamente, un enfoque capture-first reconstruye la aplicación desde una instalación en ejecución, que es donde encaja EtherApps Forge.
¿Qué se rompe durante la conversión?
Las roturas comunes son comportamientos de tiempo de ejecución que el contenedor MSIX cambia: escrituras de archivos o de registry que redirige, scripts de arranque que preparan el entorno y configuración por usuario que una conversión a nivel de máquina no traslada. La mayoría se resuelven con un ajuste del Package Support Framework; los paquetes App-V 4.x rompen la ruta directa por completo.
¿Los paquetes convertidos necesitan volver a firmarse?
Sí. Cada paquete MSIX debe firmarse con un certificado en el que el estate confíe antes de que se instale en dispositivos gestionados, y no hay una firma de App-V que reutilizar. Asegúrese de que la identidad del certificado coincida con el editor del manifiesto.
¿Cómo despliego apps MSIX migradas con Intune?
Añada el MSIX firmado a Intune y asígnelo en anillos escalonados, empezando por un grupo piloto. Pruebe primero en dispositivos Windows 11 representativos, luego amplíe anillo por anillo para que cualquier problema se detecte pronto.
Dónde encaja EtherApps Forge
La mayoría de los estates de App-V son una mezcla: paquetes App-V 5.1 que convierten directamente, y una cola obstinada de App-V 4.x o paquetes de origen perdido que no. EtherApps Forge está construido para esa cola. Como packager capture-first, captura la aplicación desde una instalación en vivo y la reconstruye, así que un instalador perdido ya no es un callejón sin salida.
El flujo es agéntico con revisión humana: EtherApps Forge analiza el footprint capturado y recomienda una ruta, y un packager la confirma, en lugar de fingir que las aplicaciones difíciles se empaquetan solas. Las salidas abarcan MSIX, MSI, PowerShell App Deployment Toolkit, IntuneWin y App Attach, así que una captura puede alimentar la entrega en Intune o un escenario de App Attach en Azure Virtual Desktop. Demuéstrelo primero en una aplicación real con la prueba gratuita de 7 días antes de comprometer el estate más amplio.
Para el lado de la entrega, vea empaquetado y despliegue MSIX, y para los paquetes cuyo origen ha desaparecido, modernizar apps de Windows heredadas cubre la ruta del instalador perdido. Las guías complementarias sobre una ruta capture-first a MSIX para aplicaciones complejas y cómo reempaquetar una aplicación cuando el instalador está perdido profundizan más, y el empaquetado de aplicaciones agéntico explica el modelo automatizado de captura y revisión.
Una migración de App-V a MSIX es primero un trabajo de planificación y luego un trabajo de empaquetado: audite el estate, enrute cada paquete al método que encaje, corrija las brechas de tiempo de ejecución, firme, pruebe y despliegue a través de Intune en anillos. Haga bien la auditoría y el resto se vuelve rutina.
Explore el empaquetado y despliegue MSIX para obtener apoyo en la migración de App-V a MSIX a través de la conversión, los ajustes de PSF, la firma y el despliegue en Intune.