MSIX a escala: lo que revelan 3.261 casos de empaquetado automatizado

¿Puede un flujo de trabajo automatizado convertir aplicaciones Windows existentes en paquetes MSIX en miles de casos, y no solo en un puñado de demostraciones? Nuestro nuevo estudio dice que sí para una gran parte de los casos intentados: de 3.261 casos de aplicaciones, 2.957 produjeron un paquete MSIX (90,68 %) y 2.610 registraron un smoke test superado por completo (80,04 %). El artículo, "MSIX at Scale: An Automated Packaging Study of 3,261 Windows Application Cases", está disponible ahora en Zenodo bajo una licencia CC BY 4.0 con el DOI 10.5281/zenodo.21985871, junto con un suplemento que permite a cualquiera recalcular cada cifra.

Si gestiona el parque de aplicaciones de una organización de 50 a 600 usuarios, o empaqueta aplicaciones para clientes como MSP, la pregunta detrás de esta investigación le resultará familiar. Tiene instaladores, archivos MSI, archivos ZIP y herramientas portables de todas las formas imaginables. Reempaquetarlos a mano es lento, cada empaquetador lo hace de forma ligeramente distinta y la cola de trabajo rara vez se reduce. El estudio se pregunta si ese trabajo puede repetirse de forma fiable a gran volumen, y define con cuidado qué significa "funcionó".

Qué midió el estudio

MSIX es el formato de paquete de Microsoft para instalar y gestionar aplicaciones Windows. Un paquete reúne los archivos de la aplicación con un manifiesto que indica a Windows qué contiene el paquete y cómo se inician sus aplicaciones. La guía de conversión de Microsoft trata la preparación, la captura, la creación del paquete y las pruebas como pasos separados, y el estudio también mantiene esos pasos separados.

Analizamos los registros, cerrados el 27 de junio de 2026, de cada caso en el que se registró un intento de empaquetado MSIX. Las aplicaciones proceden de búsquedas en el catálogo público de Windows Package Manager (WinGet). Cada caso intentado cuenta en el denominador, incluidos los que se detuvieron pronto, de modo que los porcentajes principales no pueden inflarse descartando fallos en silencio.

Cada caso se informó en cuatro etapas:

1. Paquete producido: la compilación MSIX se completó.
2. Instalado y registrado: el paquete se instaló para un usuario de prueba y Windows lo registró.
3. Punto de entrada iniciado: se inició un programa seleccionado dentro del paquete.
4. Smoke test superado por completo: la instalación, el inicio, el cierre y la limpieza se registraron como correctos, sin ningún bloqueo detectado.

Un smoke test es una primera comprobación breve, no una prueba completa. Confirma que un paquete se instala, que un programa seleccionado se inicia y que la prueba se cierra y limpia. No prueba el inicio de sesión, la edición de un documento ni el guardado de datos. Mantuvimos esa distinción visible en todo el artículo, y aquí también la mantenemos visible.

Los resultados

Cada porcentaje usa los 3.261 casos intentados. Las etapas se solapan, por lo que no deben sumarse.

Fíjese en dónde se van quedando los casos. 304 intentos no produjeron un paquete, pero casi otros tantos, 281, se instalaron y registraron sin problemas y después no registraron el inicio de ningún programa. Esa es la lección práctica para cualquier programa de empaquetado: que exista un archivo de paquete en el disco, o incluso que se instale sin problemas, no es lo mismo que una aplicación que funciona. El éxito de la compilación y el éxito de la aplicación deben informarse por separado, o un plan de migración parecerá más sano de lo que es.

Además, hubo casos superados en todos los tipos de origen del estudio. Estos son los smoke tests superados por completo según el tipo de instalador o de distribución:

Estos grupos contienen aplicaciones distintas con requisitos distintos, así que la tabla no demuestra que un tipo de instalador cause una probabilidad de éxito mayor o menor. Lo que sí muestra es que los resultados correctos no se limitaron a un solo tipo de instalador. Eso importa cuando su parque es una mezcla de todos ellos.

Cómo comprobamos la evidencia

Cifras como estas merecen un examen riguroso, por eso el artículo describe cómo se comprobaron antes de publicarlas.

• Cada caso superado se contrastó con su informe guardado. Los 2.610 smoke tests superados registrados se compararon con sus informes de prueba originales vinculados en los seis campos de etapa de prueba. Todos coincidieron.
• Se identificaron informes duplicados. Las huellas de archivo mostraron seis pares de casos que compartían informes idénticos, por lo que el artículo cuenta casos del catálogo y resultados guardados, no ejecuciones de prueba independientes.
• Informamos del hallazgo incómodo. Dos casos superados iniciaron una utilidad de desactivación en lugar de la aplicación principal, y la comprobación automática de identidad no lo detectó. Permanecen en el total según la regla establecida, y el artículo los usa como el ejemplo más claro de por qué un inicio no demuestra que la aplicación prevista funcione.
• Se declaran los reintentos. Los historiales guardados contienen 3.942 resúmenes de intentos: 2.712 casos tuvieron un intento, 417 tuvieron dos y 132 tuvieron tres. Son resultados del flujo de trabajo, no tasas de éxito al primer intento.

El suplemento incluye los resultados por caso, notas de selección y scripts de Python que reproducen cada tabla y cada porcentaje.

Lo que el estudio no afirma

Los límites son tan útiles como los resultados, sobre todo si piensa compartir esta investigación con otras personas de su organización.

• No es una tasa general de compatibilidad. Las aplicaciones se obtuvieron de búsquedas en el catálogo, no de una muestra aleatoria, y no representan su lista de aplicaciones ni el software de Windows en general.
• No es una prueba de preparación para producción. No se midieron las pruebas de tareas de negocio, la fiabilidad a largo plazo ni la implementación para usuarios finales.
• No mide ahorros de tiempo ni de costes. No hubo comparación con el empaquetado manual ni con otros enfoques.
• No se ha repetido de forma independiente. El artículo es un preprint y no ha pasado revisión por pares. Desarrollo EtherApps Forge, la herramienta utilizada en el estudio, y tengo un interés comercial en los resultados. Esa relación se declara en el artículo y todo lector debería tenerla en cuenta.

Un caso sin resultado correcto tampoco es prueba de que la aplicación no pueda funcionar con MSIX. Algunas aplicaciones necesitan correcciones (fix-ups), otro formato de paquete o un análisis más detallado.

Qué significa esto para su programa de empaquetado

Para los responsables de TI y los directivos de MSP, la investigación respalda una posición clara: MSIX es una opción de empaquetado práctica para aplicaciones Windows existentes adecuadas, y debe formar parte de su estrategia de empaquetado. No debería ser obligatorio para todas las aplicaciones, y la decisión se toma mejor aplicación por aplicación.

Para los profesionales que hacen el trabajo, el artículo apunta a un proceso de decisión que puede aplicar a su propio parque:

1. Pruebe con sus propias aplicaciones. Evalúe MSIX con las aplicaciones que su organización usa realmente, no con la lista de ejemplo de un proveedor.
2. Mantenga las etapas separadas. Registre la creación del paquete, la instalación, la comprobación inicial y las pruebas de tareas de negocio como resultados distintos.
3. Confirme que se inicia el programa correcto. Compruebe que la prueba de inicio selecciona la aplicación principal prevista, no un asistente ni una utilidad.
4. Pruebe el trabajo real. Inicio de sesión, manejo de archivos, integraciones, actualizaciones y uso prolongado, y después la implementación en dispositivos de destino limpios.
5. Encauce las excepciones. Las aplicaciones que necesitan controladores, servicios o cambios en todo el equipo pueden corresponder a otro formato. La ruta de captura primero hacia MSIX para aplicaciones Windows complejas explica cómo tomar esa decisión.

Tenga también en cuenta el comportamiento de plena confianza (full trust). La guía de contenedorización de Microsoft señala que una aplicación de escritorio empaquetada de plena confianza se ejecuta con los mismos permisos que una aplicación de escritorio estándar, así que MSIX le ofrece una instalación y desinstalación limpias, no un límite de seguridad automático.

Si necesita llevar esto a un comité de cambios o a un cliente, el DOI y el suplemento reproducible le proporcionan evidencia que puede reenviar y que otros pueden comprobar.

Dónde encaja EtherApps Forge

EtherApps Forge fue el flujo de trabajo utilizado en todo el estudio. Revisó cada origen, capturó los archivos y la configuración de la aplicación, creó y firmó el paquete MSIX, y después lo instaló, lo inició y lo limpió como primera prueba. La conclusión del artículo es deliberadamente mesurada: EtherApps Forge puede ayudarle a convertir orígenes de aplicaciones existentes adecuados en paquetes MSIX listos para su propia validación. No es una promesa de migración totalmente desatendida y lista para producción.

EtherApps Forge es una aplicación de escritorio de Windows que se ejecuta en su propio entorno, de modo que las capturas y los paquetes se quedan con usted. Su flujo de empaquetado de aplicaciones agéntico recomienda una ruta a partir de la huella real de la aplicación, y sus correcciones del Package Support Framework ayudan a las aplicaciones capturadas que necesitan redirección de archivos o del registro. Para parques con años de instaladores acumulados, la modernización de aplicaciones heredadas cubre la detección y la corrección. Artículos anteriores del mismo programa de investigación analizan MSIX nativo frente a App Attach para Azure Virtual Desktop y dónde el Package Support Framework añade riesgo a MSIX y App Attach.

La forma más rápida de ver si sus propias aplicaciones se comportan como los casos del estudio es pasarlas por el mismo flujo de trabajo. EtherApps Forge incluye una prueba gratuita de 7 días del flujo de trabajo completo, y cada licencia incluye formación y soporte.

Descubra el empaquetado y la implementación de MSIX para ver cómo la evidencia en cuatro etapas del estudio se convierte en un proceso repetible de empaquetado y entrega para su parque.