Microsoft ha llevado a disponibilidad general Managed Instance on Azure App Service, una modalidad pensada para aplicaciones web Windows que no encajan en el App Service convencional por sus dependencias del sistema operativo. El objetivo es dar una salida gestionada a aplicaciones IIS que todavía necesitan componentes COM, claves de registro, instaladores MSI, funciones de Windows o rutas de red.
La propuesta no consiste en entregar una máquina virtual con otro nombre. La configuración se aplica al plan de App Service y la plataforma conserva balanceo, parcheado, escalado, diagnósticos e identidades administradas. La diferencia es que admite más personalización de Windows mediante scripts de instalación, adaptadores de registro y montajes de almacenamiento.
Qué bloqueos de migración puede absorber
Los scripts PowerShell pueden instalar componentes COM, paquetes MSI, elementos de la Global Assembly Cache, funciones de Windows, servicios y configuraciones de IIS. Los valores persistentes del registro pueden quedar respaldados por Azure Key Vault, y Azure Files o rutas UNC se pueden montar con letras de unidad personalizadas.
También admite integración de red virtual a nivel de plan, con endpoints privados, DNS privado, grupos de seguridad de red, tablas de rutas y NAT Gateway. Para diagnóstico existe acceso RDP just-in-time mediante Azure Bastion, siempre que se haya integrado la red virtual.
La documentación de Managed Instance sitúa bien su alcance: es una opción de “lift and improve” para aplicaciones .NET Framework que necesitan personalización de Windows, no el destino natural para una aplicación moderna que ya funciona con Linux, contenedores o varios lenguajes.
Los límites que deciden la arquitectura
En disponibilidad general solo funciona con aplicaciones web Windows y con planes Pv4 o Pmv4. Microsoft enumera siete regiones iniciales: East Asia, West Central US, North Europe, East US, Australia East, Central India y South India. La capacidad real depende además de que la SKU esté disponible y exista cuota en la suscripción.
No admite Linux, contenedores, WebJobs, TCP, NetPipes ni App Service Environment. Tampoco permite unión a dominio ni autenticación NTLM o Kerberos; las opciones son Microsoft Entra ID e identidad administrada. El almacenamiento temporal local está limitado a 2 GB y se pierde al reiniciar.
Hay otra frontera operativa importante: los cambios realizados manualmente por RDP son temporales. Si una modificación debe sobrevivir a un reinicio o a mantenimiento de plataforma, tiene que expresarse en el script de configuración. Esto obliga a convertir el conocimiento del servidor antiguo en una instalación repetible.
Cómo decidir si merece un piloto
Yo empezaría con un inventario de dependencias: COM, registro, MSI, servicios, fuentes, rutas UNC, autenticación y puertos. Después comprobaría región, SKU, cuota y coste, y separaría lo que puede declararse mediante script de lo que exige cambiar la aplicación.
La guía de inicio rápido muestra el despliegue por portal y plantilla. Para una prueba real usaría un slot o entorno de staging, centralizaría secretos en Key Vault y enviaría los registros del plan a Azure Monitor antes de cargar datos o tráfico.
Managed Instance puede evitar mantener una VM solo para conservar unas cuantas dependencias históricas. No elimina el trabajo de modernización: lo desplaza hacia scripts, identidad, red y pruebas. Si la aplicación depende de dominio, protocolos no web o cambios manuales permanentes, la VM puede seguir siendo la opción honesta.