Azure Cloud Services (soporte extendido) se retira el 31 de marzo de 2027: cómo trasladar los roles web y de trabajo

Microsoft declaró obsoleto Azure Cloud Services (soporte extendido) el 31 de marzo de 2025 y lo retira por completo el 31 de marzo de 2027. Si una aplicación de negocio tuya funciona como roles web y roles de trabajo, tiene que estar funcionando en otro sitio de Azure antes de esa fecha. Las preguntas frecuentes sobre la retirada son tajantes sobre las dos preguntas que todo el mundo hace primero: Microsoft «no puede conceder solicitudes de prórroga», y «no hay ninguna herramienta de migración con un solo clic».

Desde hoy, 3 de octubre de 2026, eso deja seis meses.

Para quién es esto

El caso típico: una aplicación ASP.NET sobre .NET Framework, con un rol web delante y uno o dos roles de trabajo procesando colas detrás, construida por una agencia hace ocho o diez años. La agencia a menudo ya no está, la aplicación sigue gestionando el procesamiento de pedidos o un portal de clientes, y nadie ha abierto el fichero .csdef desde la última migración.

Para comprobar si te afecta, abre el portal de Azure y lista los recursos del tipo «Cloud services (extended support)». El aviso de retirada de Microsoft enlaza directamente a esa vista. Si está vacía, has terminado.

Este artículo no trata de Cloud Services (clásico), que se retiró en 2024. Si un proveedor te aloja el producto, la migración es trabajo suyo: pídele la fecha por escrito. Todo lo que sigue es para los equipos que son dueños del código, o lo son sobre el papel y tienen que encontrar a alguien que lo entienda.

Por qué esto es más difícil que el traslado de 2024

Muchas empresas pasaron al soporte extendido en 2024, cuando se retiró la versión clásica. Ese traslado era barato por diseño. La descripción general del soporte extendido de Microsoft dice que los ficheros .csdef, .cscfg y .cspkg «se mantienen y no hay ningún cambio en los formatos», y que «no es necesario ningún cambio en el código de ejecución». Incluso había una migración in situ. La misma página recomendaba el soporte extendido para las aplicaciones que no evolucionan, porque «ofrece una vía de migración rápida».

Esta vez no hay un destino equivalente. Con palabras de Microsoft, Cloud Services «consiste en desplegar aplicaciones como máquinas virtuales. El código que escribes está estrechamente acoplado a una instancia de máquina virtual». Tu código sabe que se ejecuta en un rol. Lee la configuración del rol, encuentra espacio en disco a través del rol, recibe certificados instalados por el rol y ejecuta scripts de preparación como administrador antes de que arranque el rol. Todo eso hay que sustituirlo.

Una cosa más antes de leer la documentación oficial. El aviso de retirada y las preguntas frecuentes de Microsoft nombran un único destino, Service Fabric managed cluster. La página de descripción general enumera cinco, y la propia matriz de decisión de migración de Microsoft compara siete. Service Fabric es una opción por defecto, no un requisito, y para muchos roles web es la equivocada.

Los destinos, y cuándo encaja cada uno

Los roles web y los de trabajo no tienen por qué acabar en el mismo sitio. Elige un destino por rol.

App Service (Windows). Lo más parecido a un rol web para una aplicación ASP.NET. Las instancias Windows vienen con las versiones compatibles de .NET Framework instaladas, así que Web Forms y MVC 5 funcionan sin reescribirlos. Los roles de trabajo pueden ir detrás como WebJobs, que se ejecutan «en la misma instancia que una aplicación web» sin coste adicional. El límite es la propia máquina: Microsoft dirige las aplicaciones que necesitan componentes COM, acceso al registro o instaladores MSI hacia Managed Instance, así que las tareas de inicio con privilegios elevados no tienen adónde ir en un plan estándar.

App Service Managed Instance. Pensado para aplicaciones web Windows heredadas. Según la descripción general de Microsoft, está «disponible con carácter general para aplicaciones web Windows en determinadas regiones», limitado a los planes Pv4 y Pmv4, con .NET Framework 3.5 y 4.8 preinstalados y scripts de instalación en PowerShell que pueden registrar componentes COM, escribir claves de registro, ejecutar instaladores MSI y configurar IIS. Eso cubre la mayor parte de lo que hacían las tareas de inicio con privilegios elevados. Los límites: solo aplicaciones web (sin WebJobs), sin contenedores, solo Entra ID e identidad administrada (sin unión a dominio, NTLM ni Kerberos), y en el momento de escribir esto la única región europea que figura es North Europe.

Container Apps. Buena opción para los roles de trabajo una vez que están en .NET moderno: escalado en función de colas, trabajos programados y desencadenados por eventos, escalado a cero. Pero los requisitos de los contenedores dicen que «se requieren imágenes de contenedor basadas en Linux (linux/amd64)». El código en .NET Framework no funciona ahí hasta que se porta.

Azure Kubernetes Service. Ejecuta contenedores de Windows Server en grupos de nodos Windows, así que un rol en .NET Framework puede contenerizarse y trasladarse. La matriz de decisión califica de altas tanto su complejidad de migración como su carga operativa. Encaja si ya usas Kubernetes, no como primer clúster para una sola aplicación heredada.

Virtual Machine Scale Sets. La matriz lo describe como «más cercano al modelo de Cloud Services, con un lift-and-shift más sencillo». Recuperas la máquina virtual, y con ella los parches, la construcción de imágenes y la configuración de IIS que antes hacía el rol por ti.

Service Fabric managed cluster. El destino que nombra Microsoft. Los roles de trabajo encajan en él sin problemas. Los roles web, a menudo no: Service Fabric «no admite IIS», y la guía de conversión da ASP.NET Web Forms como no compatible, con la conversión a ASP.NET Core MVC como camino. La guía de migración a Service Fabric añade que los clústeres administrados «actualmente no admiten contenedores», así que una aplicación que dependa de IIS necesita un clúster tradicional, con más que operar.

Tabla de decisión

Qué cambia en el código

Busca Microsoft.WindowsAzure.ServiceRuntime en la solución. Todos los ficheros que lo importan van a la lista.

RoleEntryPoint

Un rol de trabajo es una clase que hereda de RoleEntryPoint y sobrescribe OnStart, Run y OnStop. Si Run termina, la instancia se recicla. Service Fabric reúne los tres en un único RunAsync que debe detenerse «cuando se señaliza el CancellationToken del método RunAsync». En App Service o en un contenedor, la misma lógica pasa a ser una aplicación de consola o un servicio en segundo plano alojado, con un bucle y un token de cancelación.

La parte que se suele pasar por alto es el apagado. OnStop te daba un momento para terminar el mensaje que tenías entre manos. Asegúrate de que el nuevo host transmite una señal de cancelación, y de que un mensaje abandonado a medio procesar puede procesarse dos veces sin problema.

Los roles web también suelen tener uno, normalmente WebRole.cs. Si su OnStart hace algo (ajustes de IIS, precalentamiento de caché), averigua qué antes de borrarlo.

RoleEnvironment

RoleEnvironment.GetConfigurationSettingValue("Key") lee la configuración del .cscfg. Nada fuera de Cloud Services lo proporciona. Antes de trasladar nada, envuelve todas las llamadas en una pequeña interfaz de configuración, y después apunta esa interfaz a la configuración de la aplicación, a variables de entorno o a Key Vault en el nuevo host. Es el cambio más barato del proyecto y hace que el resto se pueda probar en un portátil.

Otros tres usos que hay que buscar:

• RoleEnvironment.Changed, que aplicaba los cambios de configuración sin reiniciar. Service Fabric tiene un evento equivalente. En los demás destinos, da por hecho que un cambio de configuración reinicia el proceso y prueba qué efecto tiene en el trabajo en curso.
• RoleEnvironment.CurrentRoleInstance, usado para elegir una instancia que haga el trabajo programado. Los WebJobs desencadenados se ejecutan en una sola instancia; los continuos se ejecutan en todas salvo que se restrinja. Decídelo de forma explícita.
• Las ramas RoleEnvironment.IsAvailable e IsEmulated. Separan la ruta «en la nube» de la ruta «en local», y una de ellas está a punto de convertirse en código muerto.

.cscfg y .csdef

El .cscfg contiene la configuración por entorno, el número de instancias y las huellas digitales de los certificados. El .csdef contiene los endpoints, el tamaño de la máquina virtual, el almacenamiento local, las tareas de inicio, los almacenes de certificados y, a veces, varios sitios de IIS dentro de un mismo rol web. Repasa ambos línea a línea y apunta dónde vivirá después cada entrada: una opción de configuración de la aplicación, una referencia a Key Vault, código de infraestructura o ninguna parte. Los endpoints internos que permiten a los roles llamarse directamente entre sí necesitan un sustituto, ya sea una dirección de servicio o una cola.

Certificados

El soporte extendido ya obligó a llevar los certificados a Key Vault, así que esa parte del trabajo de 2024 da sus frutos. Lo que cambia es cómo los encuentra el código. Un .csdef instala los certificados en un almacén con nombre, a menudo LocalMachine. En App Service para Windows, la opción WEBSITE_LOAD_CERTIFICATES los pone a disposición en Current User\My. El código que abre el almacén LocalMachine no encuentra nada, y la primera llamada que necesita el certificado falla. En contenedores Linux, cárgalo desde Key Vault al arrancar.

Tareas de inicio

Abre Startup.cmd. Aquí es donde viven las sorpresas, normalmente ejecutadas con executionContext="elevated": fuentes para generar PDF, un componente COM, un módulo de reescritura de IIS, un cambio de registro para TLS. Cada línea tiene tres destinos posibles: ya no hace falta, se traslada a un script de instalación en Managed Instance, o se incorpora a una imagen de contenedor o de máquina virtual.

Almacenamiento local

Un recurso LocalStorage en el .csdef, leído a través de RoleEnvironment.GetLocalResource, daba a cada instancia un disco de trabajo temporal. Usa el directorio temporal de la plataforma para los ficheros que de verdad son temporales. Todo lo que tenga que sobrevivir a un reinicio, incluidos los ficheros que alguien dio por permanentes, va a Blob Storage.

Web Forms

Esta es la decisión que condiciona todo lo demás. Web Forms se apoya en System.Web y no tiene versión en ASP.NET Core, así que llevar una aplicación Web Forms a Service Fabric o a Container Apps significa reescribir su interfaz de usuario. App Service, Managed Instance, un contenedor Windows o un conjunto de escalado pueden ejecutarla sin cambios. Trasládala tal como está y haz de la modernización un proyecto aparte con su propio presupuesto. Reescribir una interfaz no debe estar en la ruta crítica de una fecha de apagado.

El resto

El intercambio de VIP entre dos servicios en la nube pasa a ser ranuras de despliegue en App Service o revisiones en Container Apps. Los registros enviados mediante la extensión de diagnóstico (WAD) necesitan un nuevo destino, normalmente Application Insights. App Service estándar y Container Apps no ofrecen escritorio remoto; Managed Instance lo permite a través de Azure Bastion, solo para diagnóstico.

Un plan de seis meses

Contando hacia atrás desde el 31 de marzo de 2027, con las vacaciones de diciembre en medio.

Octubre: inventario y elección de destino. Haz una lista de todos los despliegues con soporte extendido. Para cada rol, anota la versión de .NET Framework, si es Web Forms o MVC, cada llamada a RoleEnvironment, cada tarea de inicio, cada recurso de almacenamiento local, cada certificado y cada endpoint. Después comprueba la parte incómoda: ¿puedes compilar el paquete desplegado a partir del código fuente que tienes? Con sistemas construidos por agencias, la respuesta a veces es no, y octubre es el mes para descubrirlo. Elige un destino por rol.

Noviembre: un rol, de principio a fin. Añade el envoltorio de configuración, escribe el entorno de destino como código de infraestructura y consigue que un rol (normalmente el de trabajo más sencillo) funcione en un entorno de pruebas con registros, certificados y una canalización.

Diciembre y enero: portar el resto. Sustituye los puntos de entrada, las tareas de inicio y el almacenamiento local. Haz pruebas de carga en un entorno de preproducción con datos parecidos a los de producción: un WebJob o un contenedor puede no igualar el rendimiento de una máquina virtual dedicada a un rol.

Febrero: ejecución en paralelo. Pon el nuevo entorno frente a tráfico real. Para los procesos de trabajo que comparten cola con los roles antiguos, haz primero que el procesamiento sea idempotente o detén los procesos antiguos antes de arrancar los nuevos.

Principios de marzo: paso a producción. Cambia el DNS con tiempo de sobra. Mantén el despliegue antiguo detenido pero intacto una o dos semanas, y después bórralo. No programes el paso a producción para la última semana de marzo: si entonces falla, no hay segundo intento.

Si empiezas en enero, olvídate por completo de la modernización. Elige el destino que requiera menos cambios de código (App Service, Managed Instance o conjuntos de escalado), traslada y refactoriza después.

Qué no está claro

Microsoft dice que el servicio quedará «totalmente retirado» y que la migración es necesaria «para evitar la interrupción del servicio». Las páginas que hemos leído no dicen qué pasa con un despliegue que siga funcionando el 1 de abril de 2027. No cuentes con averiguarlo. Las regiones y los planes de Managed Instance probablemente también cambiarán en los próximos meses, así que confírmalos cuando decidas, no a partir de este artículo.

Dónde conseguir ayuda

Nos hacemos cargo de aplicaciones que construyeron otros, averiguamos cómo funcionan y las trasladamos: el inventario, el destino de cada rol, los cambios de RoleEnvironment y de las tareas de inicio, y el paso a producción. Nuestro trabajo de mantenimiento de sistemas heredados cubre .NET Framework y Web Forms; si la migración la está haciendo tu propio equipo y necesita más manos, consulta la ampliación de equipos.

Si tienes un despliegue de Cloud Services y una fecha a seis meses vista, escribe a office@c9group.dev.