Migração para AWS

Migrar aplicação .NET para AWS

Por Audizio Nunes · 2 de outubro de 2026

Migrar um sistema .NET para a AWS não exige, necessariamente, reescrevê-lo. O caminho depende da versão do .NET, das dependências do Windows e do banco de dados.

Uma aplicação ASP.NET em .NET Framework, hospedada no IIS, tem restrições diferentes de uma API em .NET atual. Começo separando duas decisões: onde o sistema vai rodar agora e se vale atualizar o código. Juntar as duas mudanças pode aumentar esforço e risco sem trazer benefício imediato.

Primeiro: qual .NET e quais dependências?

.NET Framework roda em Windows. Manter o IIS em uma instância Amazon EC2 Windows tende a exigir menos alterações no código, mas a equipe continua responsável pelo sistema operacional, patches, IIS, publicação e monitoramento. Já uma aplicação em .NET atual pode rodar em Linux ou Windows, desde que suas bibliotecas e integrações também sejam compatíveis.

Ao examinar o projeto, procure referências a System.Web, componentes COM, bibliotecas nativas, autenticação integrada do Windows, caminhos de arquivos locais e tarefas agendadas. Elas ajudam a estimar o trabalho de uma futura atualização de runtime. O AWS Transform for .NET pode apoiar a avaliação de compatibilidade; o resultado ainda precisa de revisão e testes da equipe.

Onde hospedar a aplicação?

• EC2 Windows com IIS: opção direta para muitos sistemas em .NET Framework que precisam manter o ambiente. Controle alto, com responsabilidade operacional correspondente.
• EC2 Linux ou Windows: opção para .NET atual quando a equipe quer controlar a máquina e a implantação sem adotar contêineres de imediato.
• AWS Elastic Beanstalk: gerencia parte do provisionamento e da implantação, mas a plataforma, o runtime e as dependências precisam ser conferidos antes de escolhê-lo.
• Amazon ECS com AWS Fargate: executa a aplicação em contêiner sem administrar as instâncias EC2 subjacentes. Faz mais sentido quando o empacotamento, a publicação e a operação em contêineres já foram planejados.

A escolha não é uma escala em que o serviço mais sofisticado é sempre melhor. Ela depende da necessidade de controle, do trabalho de adaptação, da equipe disponível e dos requisitos de disponibilidade. Uma única instância também não se torna altamente disponível apenas por estar na AWS.

Banco, arquivos e integrações podem decidir o projeto

Se o sistema usa SQL Server, avalie tamanho e versão do banco, edição, jobs, autenticação e recursos específicos antes de separar o banco da aplicação. Amazon RDS for SQL Server administra parte da infraestrutura, mas não substitui todas as possibilidades de um SQL Server instalado em EC2. O guia sobre migração de SQL Server para o Amazon RDS detalha as verificações de fuso, collation e compatibilidade.

Revise também uploads gravados no disco do servidor, sessões mantidas em memória, envio de e-mails, certificados, filas e serviços em segundo plano. Em um sistema que emite documentos fiscais, certificado A1, fuso horário, formato das datas e comunicação com serviços externos merecem testes de ponta a ponta. Mudar a infraestrutura sem mapear essas dependências pode deixar o site no ar e uma função importante sem operar.

Armazene segredos e credenciais de forma apropriada, com permissões restritas. Planeje logs, métricas e alertas para descobrir falhas no novo ambiente. Se o sistema depende de IP fixo para parceiros, valide essas liberações antes da virada.

Migrar agora ou modernizar o código junto?

Quando a prioridade é sair de um servidor local ou VPS com prazo curto, hospedar o sistema com poucas alterações pode reduzir o número de variáveis na primeira etapa. Modernizar .NET Framework para .NET atual pode abrir caminho para Linux e reduzir componentes licenciados, mas exige avaliar APIs, bibliotecas, comportamento e esforço de teste. O ganho potencial precisa compensar esse projeto adicional.

O custo também vai além da instância: Windows e SQL Server, armazenamento, backups, tráfego, observabilidade e operação entram na conta. Compare as alternativas com o guia de custos de migração para AWS, sem assumir que Linux, contêiner ou RDS serão mais baratos em qualquer caso.

Como validar a entrada em produção

1. Levantar fluxos essenciais, integrações e horários críticos; definir quais mudanças entram nesta etapa.
2. Implantar em ambiente de teste e verificar login, processamento, arquivos, emissão de documentos quando aplicável, desempenho e restauração de backup.
3. Definir sincronização final dos dados, janela de virada, mudança de DNS e critérios claros para seguir ou retornar. Se houver novas gravações após a virada, o plano de volta precisa tratar esses dados.
4. Acompanhar erros, tempo de resposta e custos no início da operação antes de desligar o ambiente anterior.

Se a aplicação hoje roda em uma VPS, veja também o roteiro para migrar de VPS para AWS.

Perguntas frequentes

É preciso reescrever a aplicação .NET Framework?

Não para toda migração. Uma aplicação compatível pode continuar em IIS no Windows sobre EC2. Atualizar para .NET atual é outra decisão, que exige análise de código e testes.

Posso levar a aplicação para Linux?

Aplicações em .NET atual podem rodar em Linux, desde que bibliotecas, componentes nativos e integrações sejam compatíveis. .NET Framework requer Windows; para sair dele, é preciso portar e validar a aplicação.

É possível migrar sem parar o sistema?

Depende de como o banco, os arquivos e as integrações serão sincronizados. Uma janela pequena pode ser viável, mas não há promessa séria de parada zero sem examinar o sistema e ensaiar a virada.