Buena parte de los consejos de migración publicados en la antesala de abril de 2026 decían que App-V terminaba. Eso no era del todo exacto, y la diferencia importa si está planificando trabajo apoyándose en ello.
Lo que alcanzó el fin de soporte fue la infraestructura de servidor de App-V. El cliente y el Sequencer no. Pasaron a soporte extendido en noviembre de 2024 y continúan en el calendario de servicing de Windows.
Si reconstruyó su hoja de ruta en torno a "App-V muere en abril", conviene releer a qué se comprometió realmente. El trabajo puede seguir siendo el trabajo correcto. La urgencia que se le atribuyó probablemente no lo era.
Qué alcanzó realmente el fin de soporte
La fecha es el 14 de abril de 2026, y se aplica a una lista concreta.
Bajo la política de ciclo de vida fijo de Microsoft, ese día se retiró la generación de herramientas del Microsoft Desktop Optimization Pack. Application Virtualization Hosting for Windows Desktops figura en ella, junto a BitLocker Administration and Monitoring, el Diagnostics and Recovery Toolset, User Experience Virtualization y Advanced Group Policy Management. En términos de App-V, "hosting" significa el servidor de gestión, el servidor de publicación y el servidor de informes, más las bases de datos que hay detrás.
El cliente y el Sequencer se tratan por separado, y la política de soporte de App-V de Microsoft es explícita al respecto. Han pasado a soporte extendido fijo y ya no están obsoletos. No hay una nueva fecha de fin de soporte para ellos.
Dos detalles explican por qué el cliente sobrevive a los servidores. El cliente de App-V se incluye dentro de Windows Enterprise y Windows Education desde Windows 10 versión 1607, así que es una función de Windows que se habilita, no un producto aparte que se instala. El Sequencer pasó al Windows Assessment and Deployment Kit. Ambos siguen ahora el calendario de servicing de Windows.
Soporte extendido significa que Microsoft sigue incluyendo la función como parte de Windows y sigue publicando correcciones de errores y de seguridad, pero no aceptará cambios de diseño ni funciones nuevas. No está abandonado. Tampoco se está desarrollando.
Qué significa esto en la práctica
Dos situaciones distintas, a menudo confundidas.
Si ejecuta la infraestructura completa de App-V, con servidores de gestión, publicación e informes, esa es la parte que tiene una fecha límite real detrás. Ejecutar infraestructura de servidor sin soporte que intermedia la entrega de aplicaciones es un riesgo genuino, y esa migración no es opcional.
Si entrega paquetes App-V sin esos servidores, a través de Intune, Configuration Manager o scripts contra el cliente, su posición es bastante más cómoda de lo que sugerían los titulares. El cliente está soportado. Tiene tiempo para planificar como es debido.
La mayoría de los estates que veo son el segundo caso y creen ser el primero.
Puede zanjarlo en un minuto en cualquier dispositivo que ejecute los paquetes:
Get-AppvPublishingServer | Select-Object Name, Url
Get-AppvClientPackage -All | Select-Object Name, Version, PackageId
Si el primer comando devuelve un servidor de publicación apuntando a una URL interna, tiene infraestructura de servidor en la ruta de entrega y un trabajo con fecha entre manos. Si no devuelve nada mientras el segundo comando lista paquetes, esos paquetes fueron añadidos y publicados localmente por Configuration Manager, un script de Intune o una secuencia de tareas, y no hay servidor alguno implicado.
Ejecútelo sobre una muestra representativa en lugar de sobre una sola máquina. Los estates que crecieron durante una década rara vez son consistentes, y es habitual encontrar una unidad de negocio todavía apuntando a un servidor de publicación que todos los demás dejaron de usar hace años.
Dos posiciones muy distintas, y la comprobación que le dice en cuál está.
Por qué esto se exageró
En parte, confusión honesta entre "servidor de App-V" y "App-V". En parte, porque una fecha límite es una razón más convincente para arrancar un proyecto que "esto se está volviendo heredado poco a poco".
El efecto secundario desafortunado es que algunas organizaciones precipitaron conversiones para las que no estaban preparadas, lo que produjo paquetes que funcionan en pruebas y generan tickets de soporte en producción. Una migración apresurada de una aplicación difícil es peor que una planificada seis meses después.
También cuesta credibilidad internamente. Pida presupuesto contra una fecha límite que resulta no aplicar a su estate, y el siguiente proyecto de aplicaciones que proponga arrancará desde una posición peor que este.
Qué es cierto realmente
- Los componentes de servidor alcanzaron el fin de soporte. Migre fuera de ellos.
- El cliente y el Sequencer están en soporte extendido. No van a dejar de funcionar en una fecha concreta.
- El soporte extendido no es una estrategia. Es tiempo para ejecutar una.
- App-V no recibe inversión nueva. Todo lo nuevo ocurre alrededor de MSIX y App Attach.
- App-V App Attach es una forma soportada de seguir ejecutando paquetes App-V existentes en Azure Virtual Desktop sin levantar un servidor App-V propio, y es una opción real mientras planifica el resto.
Lo que el soporte extendido no le compra merece decirse con claridad. No significa que el formato siga el ritmo de la plataforma. No significa que un fabricante de aplicaciones vaya a ayudarle cuando reporte un fallo desde dentro de un entorno virtual. Y no significa que sus packagers vayan a saber secuenciar dentro de tres años, porque quienes lo hacían bien tienden a moverse hacia los formatos en los que se invierte. Esa última es la restricción que muerde primero en la mayoría de los estates, y ninguna política de soporte la arregla.
La lectura correcta no es "no hay prisa". Es "tiene tiempo suficiente para hacerlo bien, así que hágalo bien".
Planificar sin el pánico
La secuencia útil es la misma que se aplica a cualquier migración de un estate de aplicaciones, y empieza por saber qué tiene.
Inventaríe lo que está realmente en uso. Los estates de App-V acumulan paquetes que nadie ha iniciado en dos años. Cada uno de esos que migre es esfuerzo desperdiciado. Primero los datos de uso, luego las decisiones. Si no tiene telemetría de uso, los eventos de publicación e inicio en el cliente separarán lo vivo de lo archivado lo bastante bien para trabajar.
Ordene por destino, no por antigüedad. Algunos paquetes se convierten en MSIX. Otros están mejor como paquetes MSI o de PowerShell App Deployment Toolkit. Algunos deberían retirarse. Otros son candidatos a App Attach en un estate de escritorio virtual. Decidir esto por aplicación, de antemano, evita el patrón donde todo se fuerza hacia MSIX y un tercio se resiste.
Los criterios que suelen zanjarlo, en el orden en que tienden a aplicarse:
- ¿La inicia alguien todavía? Retirar gana a convertir siempre, y es la única ruta sin carga de pruebas.
- ¿El fabricante sigue publicando un instalador? Empaquete la versión actual desde el origen en lugar de convertir un paquete construido a partir de una release cuatro versiones atrás.
- ¿Instala un driver o un servicio de sistema, o escribe en ubicaciones de máquina que otras aplicaciones leen? Eso es trabajo de MSI o PSADT, no de MSIX.
- ¿Se usa únicamente dentro de un estate de escritorio virtual? App Attach puede ser mejor destino que la instalación por dispositivo, y MSIX nativo frente a App Attach expone el compromiso.
- ¿Es un paquete App-V 5.1 limpio en uso diario? Esa es la conversión más rápida disponible y la forma adecuada para su primera pasada.
Convierta primero los fáciles, para construir el pipeline. No el más difícil para demostrar que se puede. Quiere un proceso que funcione, una configuración de firma que se porte bien y un anillo de pruebas que realmente detecte cosas, antes de encontrarse con los casos incómodos.
Espere que se rompan cosas concretas. App-V y MSIX manejan las variables de entorno, los accesos directos, los scripts y las asociaciones de tipo de archivo de forma diferente, y en esas diferencias es donde aterriza realmente el esfuerzo de conversión. Migración de App-V a MSIX cubre qué suele salir mal y por qué, y conversión de legacy a MSIX cubre los comportamientos de contenedor que emergen después.
Conserve el paquete App-V hasta que el reemplazo esté probado en producción. No hasta que pase las pruebas. Hasta que usuarios reales lo hayan usado durante quince días. Conserve también un entorno de sequencing operativo durante un tiempo, porque la semana en que lo desmonte es la semana en que encontrará un paquete más que necesita reconstrucción.
Lo único que merece la pena hacer ahora
Determine en cuál de las dos situaciones está. Si ejecuta la infraestructura de servidor, eso lleva una fecha límite real y debería planificarse como es debido. Si no, le han regalado tiempo, y el mejor uso es el inventario y la clasificación en lugar de una avalancha de conversiones.
En cualquier caso, el trabajo que rinde es el mismo: saber qué tiene, saber en qué debe convertirse cada cosa y convertir de forma deliberada. Un equipo que dedica quince días a inventario y enrutamiento suele terminar todo el estate más rápido que uno que empezó a convertir el primer día, porque nunca tiene que reconstruir los paquetes que no debería haber hecho.
Dónde encaja EtherApps Forge
EtherApps Forge captura aplicaciones, incluso desde entornos antiguos y versiones antiguas de Windows, decide la ruta de empaquetado y produce salidas MSIX, MSI, PSADT o listas para Intune desde la misma captura. La decisión de enrutamiento es lo que importa aquí, porque el error en la mayoría de las migraciones de App-V no es la conversión en sí. Es convertir cosas que deberían haberse retirado, y forzar hacia MSIX cosas que pertenecían a otro sitio.
EtherApps Forge es una aplicación de escritorio de Windows con una prueba gratuita de 7 días, no un servicio alojado, así que las capturas y las salidas permanecen dentro de su propio entorno. Nuestra ruta de apps heredadas cubre el lado de descubrimiento y remediación, modernización y migración de aplicaciones cubre la planificación, y empaquetado y despliegue MSIX cubre la firma, la validación y la entrega una vez que existe un paquete.
Explore la modernización de aplicaciones heredadas
Empiece por el inventario y la decisión de enrutamiento, y las conversiones se vuelven la parte fácil.