O Azure Cloud Services (Extended Support) é descontinuado a 31 de março de 2027: como migrar web roles e worker roles

A Microsoft declarou o Azure Cloud Services (extended support) obsoleto a 31 de março de 2025 e descontinua-o por completo a 31 de março de 2027. Se uma aplicação de negócio da sua empresa corre como web roles e worker roles, tem de estar a correr noutro serviço do Azure antes dessa data. As perguntas frequentes sobre a descontinuação respondem sem rodeios às duas perguntas que toda a gente faz primeiro: a Microsoft «não pode conceder pedidos de prorrogação» e «não existe nenhuma ferramenta de migração com um só clique».

A contar de hoje, 3 de outubro de 2026, restam seis meses.

A quem se destina

O caso típico: uma aplicação ASP.NET em .NET Framework, com um web role à frente e um ou dois worker roles atrás a processar filas, feita por uma agência há oito ou dez anos. Muitas vezes a agência já seguiu caminho, a aplicação continua a tratar do processamento de encomendas ou de um portal de clientes, e ninguém abriu o ficheiro .csdef desde a última migração.

Para saber se é afetado, abra o portal do Azure e liste os recursos do tipo «Cloud services (extended support)». O aviso de descontinuação da Microsoft tem uma ligação direta para essa vista. Se estiver vazia, não tem nada a fazer.

Este artigo não trata do Cloud Services (classic), descontinuado em 2024. Se for um fornecedor a alojar o produto, a migração é tarefa dele: peça-lhe a data por escrito. Tudo o que se segue é para equipas que são donas do código, ou que o são no papel e têm de encontrar alguém que o perceba.

Porque é que isto é mais difícil do que a mudança de 2024

Muitas empresas passaram para o extended support em 2024, quando o classic foi descontinuado. Essa mudança foi barata por desenho. A visão geral do extended support da Microsoft diz que os ficheiros .csdef, .cscfg e .cspkg «transitam e os formatos não mudam» e que «não são necessárias alterações ao código de runtime». Houve até uma migração no próprio local. A mesma página recomendava o extended support para aplicações que não estão a evoluir, porque «oferece um caminho de migração rápido».

Desta vez não há um destino equivalente. Nas palavras da Microsoft, o Cloud Services «consiste em implementar aplicações como VM. O código que escreve fica fortemente acoplado a uma instância de VM». O seu código sabe que corre dentro de um role. Lê a configuração a partir do role, encontra espaço em disco através do role, recebe os certificados instalados pelo role e corre scripts de configuração como administrador antes de o role arrancar. Tudo isso tem de ser substituído.

Mais uma coisa antes de ler a documentação oficial. O aviso de descontinuação e as perguntas frequentes da Microsoft indicam um único destino, o Service Fabric managed cluster. A página de visão geral enumera cinco, e a própria matriz de decisão de migração da Microsoft compara sete. O Service Fabric é uma predefinição, não uma obrigação, e para muitos web roles é a escolha errada.

Os destinos, e quando cada um se aplica

Os web roles e os worker roles não têm de ir parar ao mesmo sítio. Escolha um destino para cada role.

App Service (Windows). O mais parecido com um web role para uma aplicação ASP.NET. As instâncias Windows trazem instaladas as versões suportadas do .NET Framework, pelo que Web Forms e MVC 5 correm sem reescrita. Os worker roles podem ir atrás como WebJobs, que correm «na mesma instância que uma aplicação web» sem custo adicional. O limite é a própria máquina: a Microsoft encaminha para o Managed Instance as aplicações que precisam de componentes COM, de acesso ao registo do Windows ou de instaladores MSI, pelo que as startup tasks com privilégios elevados não têm para onde ir num plano normal.

App Service Managed Instance. Feito para aplicações web Windows antigas. Segundo a visão geral da Microsoft, está «disponível em geral para aplicações web Windows em determinadas regiões», limitado aos planos Pv4 e Pmv4, com o .NET Framework 3.5 e 4.8 pré-instalados e scripts de instalação em PowerShell que podem registar componentes COM, escrever chaves de registo, executar instaladores MSI e configurar o IIS. Isso cobre a maior parte do que as startup tasks com privilégios elevados faziam. Os limites: só aplicações web (sem WebJobs), sem contentores, apenas Entra ID e identidade gerida (sem adesão a domínio, NTLM ou Kerberos) e, à data em que escrevemos, a única região europeia indicada é North Europe.

Container Apps. Bom para worker roles depois de passarem para .NET moderno: escalamento comandado pelas filas, tarefas agendadas e acionadas por eventos, escalamento até zero. Mas os requisitos dos contentores dizem que «são obrigatórias imagens de contentor baseadas em Linux (linux/amd64)». Código em .NET Framework não corre lá enquanto não for portado.

Azure Kubernetes Service. Corre contentores Windows Server em node pools Windows, pelo que um role em .NET Framework pode ser colocado num contentor e transferido. A matriz de decisão classifica como elevadas tanto a complexidade da migração como a carga operacional. Serve se já usa Kubernetes, não como primeiro cluster para uma única aplicação antiga.

Virtual Machine Scale Sets. A matriz descreve-o como «mais próximo do modelo do Cloud Services, permitindo um lift-and-shift mais fácil». Recupera a VM e, com ela, as atualizações do sistema, a criação de imagens e a configuração do IIS que o role fazia por si.

Service Fabric managed cluster. O destino indicado pela Microsoft. Os worker roles encaixam nele sem dificuldade. Os web roles muitas vezes não: o Service Fabric «não suporta o IIS», e o guia de conversão indica o ASP.NET Web Forms como não suportado, sendo a conversão para ASP.NET Core MVC o caminho proposto. O guia de migração para o Service Fabric acrescenta que os managed clusters «atualmente não suportam contentores», pelo que uma aplicação dependente do IIS precisa de um cluster tradicional, com mais para operar.

Tabela de decisão

O que muda no código

Procure Microsoft.WindowsAzure.ServiceRuntime na solução. Todos os ficheiros que o importam entram na lista.

RoleEntryPoint

Um worker role é uma classe que herda de RoleEntryPoint e redefine OnStart, Run e OnStop. Se Run terminar, a instância é reciclada. O Service Fabric junta os três num único RunAsync, que deve parar «quando o CancellationToken do método RunAsync é sinalizado». No App Service ou num contentor, a mesma lógica passa a ser uma aplicação de consola ou um serviço em segundo plano alojado, com um ciclo e um token de cancelamento.

A parte que costuma escapar é o encerramento. O OnStop dava-lhe um momento para terminar a mensagem em curso. Garanta que o novo host transmite um sinal de cancelamento e que uma mensagem abandonada a meio do processamento pode ser processada duas vezes sem problema.

Os web roles costumam ter também um, normalmente WebRole.cs. Se o seu OnStart faz alguma coisa (ajustes ao IIS, aquecimento de cache), descubra o quê antes de o apagar.

RoleEnvironment

RoleEnvironment.GetConfigurationSettingValue("Key") lê definições do .cscfg. Fora do Cloud Services, nada o fornece. Antes de mudar o que quer que seja, envolva todas as chamadas numa pequena interface de configuração e depois aponte essa interface para app settings, variáveis de ambiente ou Key Vault no novo host. É a alteração mais barata do projeto e permite testar o resto num portátil.

Outras três utilizações a procurar:

• RoleEnvironment.Changed, que aplicava alterações de configuração sem reinício. O Service Fabric tem um evento equivalente. Nos restantes destinos, parta do princípio de que uma alteração de definição reinicia o processo e teste o que isso faz ao trabalho em curso.
• RoleEnvironment.CurrentRoleInstance, usado para eleger uma instância para o trabalho agendado. Os WebJobs acionados correm numa única instância; os contínuos correm em todas, salvo se forem restringidos. Decida de forma explícita.
• Ramificações com RoleEnvironment.IsAvailable e IsEmulated. Separam o caminho «cloud» do caminho «local», e um deles está prestes a tornar-se código morto.

.cscfg e .csdef

O .cscfg contém as definições de cada ambiente, o número de instâncias e as impressões digitais dos certificados. O .csdef contém os endpoints, o tamanho da VM, o armazenamento local, as startup tasks, os arquivos de certificados e, por vezes, vários sites IIS dentro de um só web role. Percorra os dois linha a linha e anote onde fica cada entrada depois da migração: uma app setting, uma referência ao Key Vault, código de infraestrutura ou em lado nenhum. Os endpoints internos que permitem aos roles chamarem-se diretamente precisam de substituto, seja um endereço de serviço seja uma fila.

Certificados

O extended support já obrigou a passar os certificados para o Key Vault, por isso essa parte do trabalho de 2024 dá agora frutos. O que muda é a forma como o código os encontra. Um .csdef instala certificados num arquivo com nome, muitas vezes LocalMachine. No App Service Windows, a definição WEBSITE_LOAD_CERTIFICATES disponibiliza-os em Current User\My. O código que abre o arquivo LocalMachine não encontra nada, e a primeira chamada que precisa do certificado falha. Em contentores Linux, carregue-o antes a partir do Key Vault no arranque.

Startup tasks

Abra o Startup.cmd. É aqui que estão as surpresas, normalmente executadas com executionContext="elevated": tipos de letra para gerar PDF, um componente COM, um módulo de reescrita do IIS, uma alteração ao registo para o TLS. Cada linha tem três destinos possíveis: já não é precisa, passa para um script de instalação no Managed Instance ou fica incorporada numa imagem de contentor ou de VM.

Armazenamento local

Um recurso LocalStorage no .csdef, lido através de RoleEnvironment.GetLocalResource, dava a cada instância um disco de trabalho. Use a pasta temporária da plataforma para ficheiros que são mesmo temporários. Tudo o que tem de sobreviver a um reinício, incluindo ficheiros que alguém julgou permanentes, vai para o Blob Storage.

Web Forms

É esta a decisão que condiciona todas as outras. O Web Forms assenta no System.Web e não tem versão ASP.NET Core, pelo que passar uma aplicação Web Forms para o Service Fabric ou para o Container Apps implica reescrever a interface. O App Service, o Managed Instance, um contentor Windows ou um scale set conseguem corrê-la sem alterações. Mude-a tal como está e faça da modernização um projeto separado, com orçamento próprio. Reescrever uma interface não cabe no caminho crítico de uma data de encerramento.

O resto

O VIP swap entre dois cloud services passa a ser feito com deployment slots no App Service ou com revisões no Container Apps. Os registos enviados pela extensão de diagnóstico (WAD) precisam de um novo destino, normalmente o Application Insights. O App Service normal e o Container Apps não oferecem ambiente de trabalho remoto; o Managed Instance permite-o através do Azure Bastion, só para diagnóstico.

Um plano de seis meses

Contando para trás a partir de 31 de março de 2027, com as férias de dezembro pelo meio.

Outubro: inventário e escolha do destino. Liste todas as implementações em extended support. Para cada role, registe a versão do .NET Framework, se é Web Forms ou MVC, todas as chamadas a RoleEnvironment, startup tasks, recursos de armazenamento local, certificados e endpoints. Depois verifique a parte desconfortável: consegue gerar o pacote implementado a partir do código-fonte que tem? Em sistemas feitos por agências, a resposta às vezes é não, e outubro é o mês para o descobrir. Escolha um destino para cada role.

Novembro: um role, de ponta a ponta. Acrescente a camada de configuração, descreva o ambiente de destino como código de infraestrutura e ponha um role (normalmente o worker mais simples) a correr num ambiente de testes, com registos, certificados e pipeline.

Dezembro e janeiro: portar o resto. Substitua os pontos de entrada, as startup tasks e o armazenamento local. Faça testes de carga num ambiente de staging com dados semelhantes aos de produção: um WebJob ou um contentor pode não igualar o débito de uma VM dedicada a um role.

Fevereiro: execução em paralelo. Ponha o novo ambiente a funcionar com tráfego real. Para workers que partilham uma fila com os roles antigos, torne primeiro o processamento idempotente ou pare os workers antigos antes de arrancar os novos.

Início de março: passagem. Mude o DNS com tempo de sobra. Mantenha a implementação antiga parada mas intacta durante uma ou duas semanas e depois apague-a. Não marque a passagem para a última semana de março: se falhar, não há segunda tentativa.

Se só começar em janeiro, esqueça a modernização. Escolha o destino que exige menos alterações ao código (App Service, Managed Instance ou scale sets), faça a mudança e refatore depois.

O que não está claro

A Microsoft diz que o serviço será «totalmente descontinuado» e que a migração é necessária «para evitar a interrupção do serviço». As páginas que lemos não dizem o que acontece a uma implementação que ainda esteja a correr a 1 de abril de 2027. Não conte com descobri-lo. As regiões e os planos do Managed Instance também deverão mudar nos próximos meses, por isso confirme-os quando decidir, não a partir deste artigo.

Onde obter ajuda

Assumimos aplicações feitas por outros, percebemos como funcionam e mudamo-las: o inventário, o destino de cada role, as alterações ao RoleEnvironment e às startup tasks, e a passagem final. O nosso trabalho de manutenção de sistemas legados abrange .NET Framework e Web Forms; se for a sua própria equipa a fazer a migração e precisar de reforços, veja o staff augmentation.

Se tem uma implementação em Cloud Services e uma data a seis meses de distância, escreva para office@c9group.dev.