Microsoft retira Azure Deployment Environments sin reemplazo

En pocas palabras: Microsoft retira Azure Deployment Environments el 22 de febrero de 2027 sin sucesor. Microsoft Dev Box la sigue el 18 de septiembre de 2028, con Windows 365 como alternativa que la propia Microsoft reconoce que no es equivalente. No hay herramienta de migración oficial.

Microsoft confirmó el retiro de Azure Deployment Environments para el 22 de febrero de 2027, sin producto sucesor. Microsoft Dev Box la sigue el 18 de septiembre de 2028, con Windows 365 como “recommended path forward” que la propia Microsoft aclara que no es equivalente. Los equipos tienen que migrar a mano: no hay herramienta de migración para ninguno de los dos servicios.

Azure Deployment Environments (ADE) es un servicio de Microsoft Azure que daba a los desarrolladores acceso self-service a entornos de desarrollo preconfigurados desde un catálogo gobernado de plantillas. Microsoft Dev Box es el servicio complementario que entregaba workstations en la nube listas para programar. Ambos comparten infraestructura de dev center y Microsoft los retira en fechas distintas, sin reemplazo directo.

¿Qué es Azure Deployment Environments y qué hacía por los equipos de desarrollo?

Azure Deployment Environments le daba a cada desarrollador la posibilidad de levantar un entorno de trabajo desde un catálogo de plantillas pre-aprobadas, sin pedirle nada al equipo de plataforma cada vez. Microsoft lo lanzó en disponibilidad general en mayo de 2023 durante Build, como respuesta justo a ese problema: entornos provisionados uno por uno, a mano, por el equipo de infraestructura.

El entonces senior program manager Sagar Chandra Reddy Lankala lo resumió bien en el lanzamiento, según la nota de InfoQ sobre el retiro: “by enabling self-service deployment for developers, Azure Deployment Environments also benefits platform engineers”, que podían publicar un catálogo estandarizado en vez de armar entornos caso por caso.

El servicio era gratuito. Solo pagabas los recursos de Azure que cada entorno terminaba creando (VMs, storage, redes). Esa combinación de catálogo gobernado más costo cero por el servicio en sí era, para muchos equipos de plataforma, el punto fuerte.

¿Cuándo se retiran Azure Deployment Environments y Microsoft Dev Box?

Azure Deployment Environments se retira el 22 de febrero de 2027. Microsoft Dev Box tiene una fecha separada y más lejana: 18 de septiembre de 2028, aunque con un detalle que mucha gente se perdió. Relacionado: conectarte por SSH a una VM. El “closing-down period” de Dev Box ya arrancó.

Según la documentación oficial de Microsoft Dev Box, ese período empezó a las 16:00 UTC del 14 de septiembre de 2026, más de un mes antes de esta nota. El retiro total llega a las 17:00 UTC del 18 de septiembre de 2028.

Los dos retiros están entrelazados porque ambos servicios comparten dev centers y proyectos. La guía de retiro de ADE lo advierte de forma directa: no borres dev centers compartidos “until you confirm that they have no remaining Microsoft Dev Box dependency”. Si tenés ambos servicios corriendo sobre la misma infraestructura, el orden de desmantelamiento importa.

¿Qué alternativas sugiere Microsoft para Azure Deployment Environments?

Microsoft propone tres caminos, y ninguno es un producto que reemplace a ADE tal cual. Son enfoques que hay que construir y mantener con tu propio equipo.

• Infraestructura como código directa con ARM o Bicep: para equipos que puedan gestionar suscripciones, grupos de recursos, identidades y políticas con sus procesos actuales de platform engineering.
• Azure Verified Modules: módulos reutilizables cuando el equipo necesita bloques estandarizados y gobernados. Hay que validar cobertura, versionado y quién es responsable de mantenerlos.
• Workflows de CI/CD en Azure DevOps o GitHub: cuando el provisioning se puede integrar en repos y pipelines, reconstruyendo a mano los comandos específicos de ADE y la configuración de azd.

Sobre el ecosistema de partners, la guía oficial es tajante: “None of the third-party solutions we identified directly support a Bicep or ARM lifecycle. Use Bicep or ARM directly in Azure for deployment.” Ningún socio externo cubre el hueco. Esa frase, en un documento oficial de Microsoft, no es poca cosa viniendo de la propia empresa que vendía el servicio.

¿Windows 365 es un reemplazo equivalente a Microsoft Dev Box?

No. Microsoft lo dice en su propio FAQ, sin vueltas: “No. Windows 365 is the recommended path forward, but architecture, licensing, management, networking, image delivery, and developer self-service can differ. Validate each workload and don’t assume complete feature parity.”

Windows 365 es un producto de Microsoft 365, gestionado vía Intune y con licenciamiento separado. Dev Box, en cambio, corría como infraestructura de Azure, facturado y gobernado junto con el resto del estado de la nube de cada empresa. Mover ese modelo a Microsoft 365 implica cambiar de superficie comercial, no solo de interfaz. Cubrimos ese tema en detalle en certificaciones de Azure según tu rol. Ojo con un detalle: “developer self-service” está explícitamente en la lista de cosas que pueden diferir.

Esa era justo la capacidad que hacía de Dev Box una plataforma para desarrolladores y no un simple escritorio remoto gestionado. Según la cobertura de InfoQ, el modelo original de Dev Box tenía tres roles claros: admins de infraestructura, líderes de equipo que armaban pools por proyecto, y desarrolladores que tomaban boxes de esos pools por su cuenta. Amanda Silver, entonces VP corporativa en la Developer Division de Microsoft, había dicho que más de 10.000 desarrolladores internos de Microsoft usaban el servicio.

¿Qué funcionalidad se pierde si no hay producto de reemplazo?

Lo que se pierde es el self-service desde un catálogo gobernado, no el provisioning en sí. Bicep, los módulos verificados y los pipelines reconstruyen la parte técnica de crear infraestructura, pero no reconstruyen el catálogo curado, las reglas de rol ni el portal donde un desarrollador pedía su entorno con un clic.

Ese territorio queda en manos de herramientas como Backstage, Port y Humanitec, que ya venían ocupando el espacio de “internal developer platform”. Microsoft, en los hechos, sale de la categoría de environment-as-a-service y le dice a sus clientes que armen eso mismo con piezas sueltas.

El ingeniero Ikiru Yoshizaki, que publica en japonés como guitarrapc_tech, planteó la misma objeción desde el lado del usuario cuando apareció la guía de retiro. Según recoge InfoQ, señaló que la ventaja de ADE estaba justo en lo que no se podía hacer fácil con Bicep, Terraform o Pulumi. Tampoco le perdonó nada al producto: dijo que hasta el final la API fue inestable y la documentación escasa, y que era triste que ese valor nunca se reconociera del todo.

¿Alguien en Microsoft explicó por qué se retira ADE? No, en ningún lado. Para Dev Box al menos hay una frase: la inversión va para Windows 365. Para Deployment Environments no hay declaración equivalente, solo una lista de cosas para construir uno mismo. Lo explicamos a fondo en cómo se compara Microsoft frente a Github.

¿Qué deben hacer los equipos antes de la fecha límite?

Microsoft pide empezar ya con un inventario completo. La guía en español de retiro de ADE detalla el llamado a la acción:

• Inventariar todo: entornos ADE, definiciones, catálogos, tipos de entorno, proyectos, dev centers, suscripciones de despliegue, identidades y asignaciones de roles, usando el Azure Advisor Service Retirement workbook.
• Validar un reemplazo por escenario: cubriendo gobernanza, control de acceso, IaC, redes, gestión de costos, ciclo de vida y self-service para desarrolladores.
• Mover usuarios y automatización al flujo de reemplazo antes del 22 de febrero de 2027.
• Borrar entornos no usados y recursos propios de Azure para reducir costos y cerrar formalmente la baja de ADE.

Para Dev Box el procedimiento es parecido pero sin red de seguridad: hay que provisionar las Cloud PCs de destino, recrear políticas y configuraciones, desplegar aplicaciones y transferir datos de usuario “through approved processes”. No hay script, no hay wizard, no hay migration tool.

¿Qué pasa si no migrás a tiempo?

Para ADE, las operaciones de escritura se bloquean en la fecha de retiro. Create, deploy y redeploy quedan cortados; solo inventario, lectura, log y delete siguen disponibles durante un período de limpieza que Microsoft no especifica cuánto dura.

Para Dev Box la consecuencia está escrita sin matices en el FAQ oficial: “Microsoft Dev Box won’t be available after retirement. Expect deletion of remaining customer workloads.” No hay período de gracia prolongado ni backup automático prometido.

Un criterio práctico para encarar esto, si te toca gestionarlo: tratá cada proyecto ADE o Dev Box como si fuera un servidor on-premise que se apaga en una fecha fija, no como una suscripción que renovás sin pensar. Documentá qué catálogo usa cada equipo, probá la alternativa elegida en un entorno de staging antes de los últimos meses de 2026, y calculá el costo real de reconstruir el self-service con Backstage o similar versus asumir que los desarrolladores pidan accesos a mano. Esa cuenta, en empresas con decenas de equipos, suele salir más cara de lo que parece en el PDF de la guía de retiro. Para más detalles técnicos, mirá el reciente ataque con malware Miasma.

Errores comunes al planificar la migración

Vi (y en este caso, leí en las fuentes) algunos errores que se repiten en este tipo de retiros de servicios cloud:

• Borrar dev centers compartidos antes de confirmar dependencias de Dev Box: la propia guía de Microsoft advierte contra esto explícitamente, porque ADE y Dev Box comparten esos recursos.
• Asumir que Windows 365 es “lo mismo pero con otro nombre”: Microsoft aclaró que licenciamiento, redes y self-service pueden diferir. Tratarlo como reemplazo 1 a 1 sin validar cada carga de trabajo es el error más caro.
• Dejar la migración para el segundo semestre de 2026 o 2027: sin migration tool, reconstruir catálogos, roles y pipelines a mano lleva más tiempo del que la mayoría de los equipos de plataforma estima al principio.
• No revisar qué recursos quedan fuera del resource group gestionado: según la guía oficial, borrar metadatos de ADE no borra necesariamente todos los recursos de Azure que el entorno desplegó, y eso sigue generando cargos.

Preguntas Frecuentes

¿Qué es Azure Deployment Environments y por qué lo discontinúa Microsoft?

Azure Deployment Environments es un servicio de Azure lanzado en mayo de 2023 que daba self-service de entornos de desarrollo desde un catálogo gobernado de plantillas. Microsoft no explicó públicamente el motivo del retiro; la guía oficial solo lista alternativas sin producto sucesor.

¿Cuándo se retira Microsoft Dev Box?

Microsoft Dev Box se retira por completo a las 17:00 UTC del 18 de septiembre de 2028. Su período de cierre (“closing-down”) ya empezó, a las 16:00 UTC del 14 de septiembre de 2026.

¿Qué alternativas hay a Azure Deployment Environments?

Microsoft propone infraestructura como código directa con ARM o Bicep, Azure Verified Modules para building blocks gobernados, o workflows de CI/CD integrados en repos y pipelines. Ninguna de las tres es un producto equivalente, y ningún partner externo cubre el ciclo de vida completo de Bicep o ARM según la guía oficial.

¿Windows 365 reemplaza a Microsoft Dev Box?

No de forma equivalente. Microsoft aclara en su propio FAQ que arquitectura, licenciamiento, redes, entrega de imágenes y self-service para desarrolladores pueden diferir entre ambos productos, y pide validar cada carga de trabajo sin asumir paridad completa de funciones.

¿Qué pasa si no migro antes de la fecha de retiro?

En ADE, las operaciones de creación y despliegue se bloquean el 22 de febrero de 2027, con un período limitado de solo lectura y borrado. En Dev Box, Microsoft advierte directamente que debe esperarse la eliminación de las cargas de trabajo que queden sin migrar tras el 18 de septiembre de 2028.

Conclusión

Microsoft se retira de la categoría de environment-as-a-service y no deja un producto atrás, solo una lista de piezas sueltas para armar. Si tu equipo usa Azure Deployment Environments, el reloj corre desde ahora: quedan menos de dieciséis meses hasta febrero de 2027, y no hay herramienta de migración que haga el trabajo por vos.

Si además tenés Dev Box, el margen es mayor (hasta septiembre de 2028) pero el salto a Windows 365 implica cambiar de modelo comercial y de gestión, no solo de nombre. Lo más sensato es empezar el inventario ya, probar Bicep o una plataforma tipo Backstage con un proyecto chico, y recién después decidir si vale la pena reconstruir el self-service completo o resignarse a que los desarrolladores pidan accesos a mano otra vez.

Fuentes

• Guía oficial de retiro de Azure Deployment Environments – Microsoft Learn
• Qué es Microsoft Dev Box – Microsoft Learn
• Microsoft Retires Azure Deployment Environments with No Replacement Product – InfoQ
• Guía de retiro de Azure Deployment Environments en español – Microsoft Learn