Fim do Dev Box e do Deployment Environments: migre capacidades, não apenas máquinas

A Microsoft anunciou o encerramento do Azure Deployment Environments em 22/02/2027 e do Microsoft Dev Box em 18/09/2028.[7] Para o primeiro, não indicou sucessor; para o segundo, recomenda Windows 365, mas reconhece que não há equivalência funcional direta.[7] A decisão de migração, portanto, não deveria começar pela pergunta sobre qual VM escolher.

O que muda para quem desenvolve

O Deployment Environments oferecia um catálogo governado para os próprios desenvolvedores provisionarem ambientes aprovados.[7] A orientação de usar ARM ou Bicep, módulos verificados e pipelines não recompõe automaticamente catálogo, portal e regras de acesso.[7] O que precisa sobreviver é a capacidade operacional, não somente o template de infraestrutura.

No Dev Box, a reportagem não aponta ferramenta de migração anunciada: será necessário provisionar Cloud PCs, recriar políticas, reinstalar aplicações e transferir dados por processos aprovados.[7] Windows 365 pertence ao ecossistema Microsoft 365, é gerido por Intune e possui licenciamento separado.[7] Isso inclui uma mudança de responsabilidade e orçamento, além da mudança técnica.

Minha recomendação é decompor o serviço atual em contratos verificáveis: quem pode criar um ambiente, quais configurações são permitidas, quanto tempo ele pode existir e como será removido. Sem essa lista, uma migração pode preservar a máquina e perder a governança.

Como aplicar

Monte um inventário de ambientes, definições, catálogos, identidades, atribuições de papel e dependências. Para cada item, identifique proprietário, destino proposto e evidência necessária para considerar a transferência concluída.

Depois, execute uma prova de migração com um fluxo real de desenvolvimento em ambiente controlado: criar o ambiente, instalar ferramentas, acessar dependências, trabalhar com dados de teste e desativar os recursos. Compare permissões, tempo de preparação, suporte e custo recorrente. Não limite o aceite a conseguir entrar na máquina.

Mantenha a definição de infraestrutura e as políticas essenciais exportáveis. Para a nova plataforma, peça uma demonstração de criação e destruição reproduzíveis antes de ampliar a adoção. Se o autosserviço exigir intervenção manual frequente, contabilize esse esforço na comparação.

Cuidados e limites

Os dois serviços compartilham recursos de dev center e projeto; excluir essas estruturas durante uma migração pode afetar o Dev Box ainda em uso.[7] Planeje a retirada a partir das dependências, não de uma lista isolada de recursos.

A reportagem contém um prazo em meses incompatível com sua própria data e com o encerramento informado.[7] Use as datas explícitas como referência do relato e confirme o aviso oficial no planejamento executivo. Também não trate Backstage, Port ou Humanitec, citados na matéria, como substitutos integrais já validados.[7] A migração só estará bem dimensionada quando capacidades e responsabilidades tiverem destino definido.

Fonte

[7] Fonte: InfoQ