AWS Transform: migração de Azure para AWS com agente de código

Em 16 de outubro de 2026, a AWS anunciou a disponibilidade geral da conversão de código do Azure SDK para o AWS SDK no AWS Transform, voltada a aplicações .NET cloud-native. Na prática, um agente lê o código, identifica onde a aplicação usa serviços do Azure e reescreve essas chamadas para os equivalentes na AWS. Para empresas com migração entre nuvens no roadmap, isso encurta uma das etapas mais trabalhosas do projeto. Mas não elimina as outras.

Este artigo explica o que a ferramenta faz, como funciona o fluxo e, principalmente, o que continua sendo responsabilidade do time para que a migração termine em produção, e não num branch convertido esperando revisão.

O que o AWS Transform converte

O agente de modernização .NET do AWS Transform identifica o código que usa serviços do Azure e o converte para os serviços correspondentes da AWS:

No anúncio, o recurso estava disponível em oito regiões: US East (N. Virginia), Ásia-Pacífico (Mumbai, Tóquio, Seul e Sydney), Canadá (Central) e Europa (Frankfurt e Londres). A região de São Paulo não aparece na lista; se o seu código-fonte tiver restrição de localização, confirme com o time de compliance antes de enviá-lo para conversão.

Como funciona o fluxo, em 5 passos

1. Descoberta: o AWS Transform identifica o uso do Azure SDK no código-fonte enviado.
2. Avaliação e plano: apresenta as opções de conversão num relatório de avaliação e num plano de modernização.
3. Decisão do time: o time aceita as opções sugeridas ou as ajusta.
4. Conversão: o código de serviços do Azure é reescrito em chamadas equivalentes do AWS SDK.
5. Validação: a ferramenta verifica se as mudanças foram incorporadas ao código transformado.

O terceiro passo é o que mais importa. A ferramenta propõe; quem decide é o time. E decidir bem exige conhecer as duas plataformas.

O que continua com o seu time

O agente acelera a reescrita de código, mas uma migração de nuvem envolve decisões que nenhuma conversão automática toma por você:

Arquitetura e plano

Ler o plano de modernização com olhar de negócio: quais aplicações migram primeiro, quais dependências precisam ir junto, onde vale aproveitar a migração para refatorar e onde é melhor apenas mover. O relatório da ferramenta é um insumo, não a estratégia.

Banco de dados

A conversão de Cosmos DB para DynamoDB estava em preview no anúncio. Mesmo quando estiver disponível, migrar banco envolve modelagem de dados (o padrão de acesso que funciona num pode não ser o ideal no outro), migração do volume existente, janela de corte e plano de rollback. É o ponto que merece um projeto à parte.

Infraestrutura, identidade e segurança

O código convertido precisa de onde rodar: contas, redes, papéis IAM, segredos e pipelines de entrega na AWS. Identidade e permissões costumam ser a parte mais subestimada de uma migração entre nuvens.

Testes e custo

Testar o comportamento real em ambiente equivalente ao de produção, comparar desempenho e acompanhar o custo nas primeiras semanas. Mudanças no modelo de cobrança podem fazer a conta sair diferente do esperado se ninguém estiver olhando.

Onde o agente mais ajuda

O ganho maior aparece em bases de código com muitas chamadas repetitivas a serviços do Azure: funções que leem e gravam arquivos no Blob Storage, workers que consomem filas do Queue Storage, gatilhos de Azure Functions espalhados por vários projetos. Reescrever esse tipo de código à mão é trabalho mecânico, sujeito a erro e pouco interessante para o time. Automatizar essa parte libera os engenheiros para o que exige julgamento.

Há também um benefício de planejamento. O relatório de avaliação gerado no segundo passo funciona como inventário técnico: mostra onde o Azure SDK aparece, quais serviços são usados e o que a ferramenta consegue converter. Mesmo que a migração ainda não esteja aprovada, esse diagnóstico ajuda a estimar esforço e a montar o caso de negócio com mais precisão do que uma estimativa feita só por entrevistas com o time.

O que fazer na segunda-feira

1. Inventarie as aplicações .NET que usam Azure Functions, Blob Storage, Queue Storage e Cosmos DB. São as candidatas diretas à conversão.
2. Escolha um piloto pequeno, sem Cosmos DB, para medir quanto do trabalho a ferramenta resolve no seu código real.
3. Prepare a fundação na AWS (contas, rede, IAM, pipeline) antes de converter. Código pronto sem ambiente para rodar não anda.
4. Trate o banco como trilha separada, com modelagem, migração de dados e plano de rollback próprios.
5. Defina critérios de pronto: testes passando, métricas de desempenho comparáveis e custo monitorado por pelo menos um ciclo de cobrança.

Se a decisão sobre qual nuvem adotar ainda não está fechada para todos os produtos, nosso comparativo AWS vs Azure vs GCP ajuda a organizar os critérios.

Fontes e Referências

• AWS Transform announces Azure-to-AWS cloud-native code conversion, AWS What's New, outubro/2026. aws.amazon.com