# ADR: AWS Transform e Agentes de IA vs Fábrica Tradicional de Modernização Este ADR avalia a decisão de adotar AWS Transform (com agentes de IA para .NET, Mainframe, VMware e código customizado) versus uma fábrica tradicional de modernização com engenharia humana, ou uma abordagem híbrida. A análise considera risco de regressão, cobertura de testes, ownership de código, segurança, custo total e governança de mudanças em um programa de modernização de escala corporativa. - URL: https://fernando.moretes.com/studies/adr-aws-transform-ai-modernization-vs-traditional-modernization - Markdown: https://fernando.moretes.com/studies/adr-aws-transform-ai-modernization-vs-traditional-modernization/study.md?lang=pt - Type: Decisão (ADR) - Company: Modernization program (cenário) - Domain: Modernização / IA - Status: accepted - Date: 2026-06-08 - Tags: modernization, aws-transform, adr, ai-agents, mainframe, dotnet, migration, governance - Reading time: 8 min --- Modernizar um portfólio legado de escala corporativa — .NET Framework, cargas VMware, COBOL em mainframe e código customizado acumulado por décadas — é um dos problemas mais caros e arriscados em engenharia de software. AWS Transform chegou ao mercado prometendo agentes de IA que automatizam boa parte desse trabalho. A pergunta real não é 'IA ou humanos': é como distribuir responsabilidade, risco e custo entre máquinas e engenheiros de forma que o resultado seja auditável, seguro e sustentável. ## Ficha do Cenário - **Programa:** Modernização corporativa (cenário composto, representativo de grandes programas financeiros/industriais) - **Portfólio alvo:** .NET Framework 4.x (~800 projetos), VMware vSphere (~1.200 VMs), COBOL/mainframe (~4M LOC), scripts customizados (Python/Shell legados) - **AWS Transform — disponibilidade geral:** Anunciado com 1 ano de operação em 2025; suporte a .NET, VMware, Mainframe e código customizado via agentes de IA - **Critérios de decisão:** Risco de regressão, cobertura de testes, ownership, segurança, custo, velocidade, governança de mudanças - **Restrições regulatórias:** Auditabilidade de mudanças de código (SOX/PCI equivalente), rastreabilidade de decisões de migração, controle de dados sensíveis durante análise de código - **Orçamento estimado total (referência de mercado):** Fábrica tradicional: 3–5 anos, dezenas de milhões USD; abordagem com AWS Transform: potencial de redução de 40–60% no esforço humano (estimativa AWS, a validar por portfólio) - **Stack de destino:** .NET 8 em ECS/EKS, EC2 nativo (pós-VMware), microsserviços em AWS, dados em RDS/Aurora ## Contexto e Forças em Jogo Programas de modernização de larga escala falham com frequência previsível por razões bem documentadas: escopo que cresce silenciosamente, regressões descobertas tarde demais, perda de conhecimento tácito dos sistemas originais e fadiga de equipe em projetos de múltiplos anos. A fábrica tradicional — times de engenharia dedicados reescrevendo ou refatorando código manualmente — oferece controle granular e ownership claro, mas escala mal: o custo cresce linearmente com o volume de código, e a qualidade é fortemente dependente da senioridade e consistência dos times. AWS Transform representa uma aposta diferente. O serviço orquestra agentes de IA especializados por domínio: um agente para upgrade de .NET Framework para .NET 8, outro para análise e conversão de COBOL, outro para planejamento de migração de VMs VMware para EC2, e um agente de propósito geral para código customizado. Cada agente opera em um pipeline que inclui análise estática, geração de código transformado, geração de testes e produção de relatórios de mudança rastreáveis. O modelo não elimina o engenheiro — ele desloca o trabalho de *escrever* transformações para *revisar e validar* transformações. A força central que torna essa decisão não trivial é a assimetria de risco. Em sistemas financeiros ou industriais críticos, uma regressão não detectada em código transformado por IA pode ter consequências que superam em muito qualquer economia de custo. O time de arquitetura precisa responder honestamente: o agente de IA produz código que *passa nos testes existentes* ou código que é *genuinamente correto*? Essas são perguntas diferentes, e a resposta depende diretamente da qualidade da cobertura de testes do portfólio legado — que, na maioria dos casos reais, é baixa. ## O Problema de Ownership e Governança Um aspecto frequentemente subestimado em discussões sobre modernização assistida por IA é o que chamo de *problema de ownership difuso*. Quando um engenheiro sênior reescreve um módulo COBOL em Java ou C#, ele carrega a responsabilidade intelectual daquele código. Ele entende as decisões, pode explicá-las em uma revisão de segurança e pode ser responsabilizado. Quando um agente de IA gera o equivalente, quem é o owner? O time que executou o Transform? O arquiteto que aprovou o relatório? A AWS? Essa pergunta não é filosófica — ela tem consequências práticas em auditoria SOX, em revisões de penetração e em incidentes de produção. Um programa de modernização responsável precisa definir explicitamente que o código gerado por IA é de propriedade e responsabilidade do time de engenharia que o revisou e aprovou. Isso exige que o processo de revisão seja genuíno — não um rubber-stamp de relatórios de 500 páginas gerados automaticamente. AWS Transform produz relatórios de transformação detalhados e diffs de código rastreáveis. Isso é um ativo real de governança: cada mudança tem proveniência, cada decisão de transformação é documentada. O desafio operacional é construir um processo de revisão que seja proporcional ao risco de cada módulo transformado. Módulos de cálculo financeiro precisam de revisão humana profunda; utilitários de logging podem ser aprovados com revisão superficial e testes automatizados. Essa triagem de risco é trabalho de arquitetura, não de IA. ## Segurança, Dados Sensíveis e o Modelo de Confiança do Agente AWS Transform opera analisando código-fonte. Em sistemas financeiros e industriais, esse código frequentemente contém — ou referencia — segredos, strings de conexão hardcoded, lógica de negócio proprietária e, em casos patológicos, dados de produção embutidos em scripts de teste. Antes de executar qualquer agente de modernização, o programa precisa de uma fase de sanitização de código que identifique e remova ou substitua esses elementos. O modelo de segurança do AWS Transform usa isolamento por conta e por execução — o código do cliente não é usado para treinar modelos, e o processamento ocorre dentro do perímetro AWS do cliente. Isso é materialmente diferente de enviar código para uma API pública de LLM sem controles. Ainda assim, a equipe de segurança precisa revisar: quais dados são transmitidos durante a análise? Quais permissões IAM são necessárias? O Transform precisa de acesso a repositórios de código — esse acesso deve ser temporário, com escopo mínimo e auditado via CloudTrail. Um padrão que recomendo é executar o Transform em uma conta AWS isolada (uma 'sandbox de modernização') com conectividade controlada ao repositório de código, sem acesso a ambientes de produção. Os artefatos gerados — código transformado, relatórios, planos de migração — são exportados para revisão em um pipeline CI/CD separado antes de qualquer merge. Esse isolamento não é paranoia: é o mesmo princípio de least privilege que aplicamos a qualquer pipeline de CI/CD que toca código de produção. ## Opções Avaliadas ### Opção A — Fábrica Tradicional (100% Engenharia Humana) **Pros** - Ownership e responsabilidade claros em cada linha de código - Conhecimento tácito preservado e transferido ativamente - Controle total sobre decisões de arquitetura durante a migração - Sem dependência de serviço externo para a transformação central **Cons** - Custo linear com volume: escala mal para portfólios grandes - Velocidade limitada pela disponibilidade de engenheiros seniores - Inconsistência de padrões entre times em programas de múltiplos anos - Risco de fadiga e rotatividade em projetos longos **Verdict:** Adequada para módulos críticos de alto risco; inviável como estratégia única para portfólios grandes ### Opção B — AWS Transform (Agentes de IA como motor principal) **Pros** - Velocidade de transformação não linear: paralelização massiva de análise e geração - Consistência de padrões aplicada pelo agente em todo o portfólio - Relatórios de transformação rastreáveis como artefatos de governança - Geração automática de testes como parte do pipeline - Redução significativa de esforço humano em código de baixo risco **Cons** - Risco de regressão silenciosa em lógica de negócio complexa não coberta por testes - Problema de ownership difuso se o processo de revisão for superficial - Dependência de serviço AWS: continuidade e roadmap fora do controle do cliente - Requer sanitização de código antes da análise (segredos, dados sensíveis) - Qualidade do output fortemente correlacionada com qualidade dos testes existentes **Verdict:** Motor eficiente para código de baixo/médio risco; requer processo de revisão robusto para ser governável ### Opção C — Abordagem Híbrida (Transform + Engenharia Humana por camada de risco) **Pros** - Risco distribuído proporcionalmente: IA onde o custo de erro é baixo, humanos onde é alto - Velocidade não linear para o volume do portfólio, com controle nos módulos críticos - Ownership claro: engenheiros revisam e aprovam todo código, independente da origem - Governança auditável: Transform gera artefatos, humanos geram decisões documentadas - Flexibilidade para ajustar a proporção IA/humano conforme maturidade de testes evolui **Cons** - Complexidade operacional maior: dois processos paralelos com integração necessária - Requer framework de classificação de risco de módulos antes de iniciar - Custo de overhead de coordenação entre trilhas de IA e humana **Verdict:** Opção recomendada: maximiza velocidade e controla risco com governança auditável ## Decisão de Arquitetura **Status:** accepted **Contexto** O programa de modernização enfrenta um portfólio de ~800 projetos .NET Framework, ~1.200 VMs VMware, ~4M LOC COBOL e código customizado acumulado. A abordagem 100% humana é inviável no prazo e orçamento disponíveis. A abordagem 100% AWS Transform sem processo de revisão robusto cria risco de regressão inaceitável em sistemas financeiros e risco de ownership difuso em auditorias. A cobertura de testes do portfólio legado é heterogênea e em média baixa. **Decisão** Adotar a Opção C — Abordagem Híbrida — com AWS Transform como motor de transformação para código classificado como risco baixo e médio (estimativa: 65–75% do portfólio por volume de LOC), e engenharia humana dedicada para módulos de risco alto (lógica de cálculo financeiro, integrações críticas, código sem cobertura de testes). Todo código gerado por Transform — independente da classificação de risco — passa por revisão humana obrigatória antes de merge, com aprovação documentada no sistema de controle de versão. A classificação de risco de módulos é produzida em uma fase de discovery de 4–6 semanas antes do início das transformações, usando análise estática e mapeamento de dependências. **Consequências** - POSITIVO: Velocidade de transformação não linear para a maioria do portfólio, reduzindo o cronograma total estimado em 40–55% versus fábrica 100% humana - POSITIVO: Ownership explícito e auditável em todo código transformado, com rastreabilidade de decisão por módulo - POSITIVO: Consistência de padrões de upgrade (.NET 8, APIs modernas) aplicada pelo agente reduz debt técnico introduzido durante a migração - NEGATIVO: Overhead de 4–6 semanas de discovery e classificação de risco antes de iniciar transformações - NEGATIVO: Complexidade operacional de manter dois processos paralelos (Transform + fábrica humana) com integração de pipeline - NEGATIVO: Dependência de AWS Transform como serviço; mudanças de pricing ou descontinuação afetam o programa — mitigado por design modular que permite substituição da trilha de IA ## Arquitetura do Pipeline de Modernização Híbrida Fluxo completo desde o portfólio legado até o código modernizado em produção, mostrando a bifurcação por camada de risco e os pontos de controle de governança. ### 📦 Legacy Portfolio - Source Repos (Git/SVN/PVCS) (storage) - Mainframe COBOL Source (external) - VMware vSphere Inventory (external) ### 🔍 Discovery & Classification (Weeks 1–6) - Code Sanitizer (secrets, PII removal) (security) - Static Analysis (SonarQube + custom) (ci) - Risk Classifier (module risk matrix) (compute) - Risk Registry (S3 + DynamoDB) (data) ### 🤖 AWS Transform Track (Low/Medium Risk ~65–75%) - Modernization Sandbox Account (security) - Transform Agent .NET Framework→.NET 8 (ai) - Transform Agent COBOL→Java/C# (ai) - Transform Agent VMware→EC2 Plan (ai) - Transform Agent Custom Code (ai) - Transformation Reports + Code Diffs (S3) (storage) ### 👷 Human Engineering Track (High Risk ~25–35%) - Senior Engineering Squads (user) - Architecture Review Board (user) ### ✅ Governance Gate (Mandatory for ALL code) - Pull Request + Human Approval (ci) - Test Suite (existing + AI-generated) (ci) - Security Scan (SAST + SCA) (security) - Audit Log (CloudTrail + CodeGuru) (security) ### 🚀 Target Platform (AWS) - .NET 8 ECS/EKS (compute) - Native EC2 (post-VMware) (compute) - RDS/Aurora (modernized data) (data) - Target Repos (CodeCommit/GitHub) (storage) ### Fluxos - repo-legacy -> sanitizer: código bruto - mainframe-src -> sanitizer: COBOL - vmware-inv -> sanitizer: inventário - sanitizer -> static-analysis: código sanitizado - static-analysis -> risk-classifier - risk-classifier -> risk-registry: matriz de risco - risk-classifier -> transform-sandbox: baixo/médio risco - risk-classifier -> human-factory: alto risco - transform-sandbox -> transform-dotnet - transform-sandbox -> transform-mainframe - transform-sandbox -> transform-vmware - transform-sandbox -> transform-custom - transform-dotnet -> transform-reports - transform-mainframe -> transform-reports - transform-vmware -> transform-reports - transform-custom -> transform-reports - transform-reports -> pr-review: diffs + relatórios - human-factory -> arch-review - arch-review -> pr-review: código revisado - pr-review -> test-suite - test-suite -> sec-scan - sec-scan -> audit-log - sec-scan -> target-repo: aprovado - target-repo -> target-ecs - target-repo -> target-ec2 - target-repo -> target-data ## Comparação por Critério de Decisão | Critério | Critério | Fábrica Tradicional | AWS Transform (puro) | Híbrido (decisão) | | --- | --- | --- | --- | --- | | Risco de Regressão | Baixo (humano revisa tudo) | Médio-Alto (depende de cobertura de testes) | Baixo-Médio (IA em código testado, humano em crítico) | — | | Velocidade de Transformação | Linear / Lenta | Não-linear / Alta | Não-linear para maioria / Alta | — | | Ownership e Accountability | Claro e direto | Difuso sem processo de revisão | Claro com processo de revisão obrigatório | — | | Governança / Auditabilidade | Depende de disciplina de documentação | Alta (relatórios automáticos de transformação) | Alta (relatórios Transform + aprovações humanas documentadas) | — | | Custo Total (estimativa) | Alto (linear com LOC) | Médio (serviço + revisão enxuta) | Médio (serviço + revisão proporcional ao risco) | — | | Segurança (dados sensíveis) | Controlada (código não sai do perímetro) | Requer sanitização + sandbox isolada | Requer sanitização + sandbox isolada (mesmo controle) | — | | Consistência de Padrões | Depende de guidelines e senioridade do time | Alta (agente aplica padrões uniformes) | Alta para trilha IA; controlada para trilha humana | — | ## Fases de Execução do Programa 1. **Semanas 1–6: Discovery e Classificação** — Inventário completo do portfólio. Análise estática com SonarQube e ferramentas customizadas. Sanitização de código (remoção de segredos, PII, dados de produção). Produção da matriz de risco por módulo. Configuração da sandbox de modernização (conta AWS isolada, IAM mínimo, CloudTrail ativo). Definição dos critérios de aprovação por camada de risco. 2. **Semanas 7–14: Piloto Controlado** — Seleção de 20–30 projetos .NET de baixo risco para piloto com AWS Transform. Execução paralela: 5 projetos de médio risco com revisão humana profunda dos outputs do Transform. Medição de métricas reais: taxa de compilação sem modificação, cobertura de testes gerados, tempo de revisão por módulo, regressões encontradas. Calibração da matriz de risco com base nos resultados do piloto. 3. **Meses 4–18: Execução em Escala** — Transformação em escala do portfólio .NET (trilha Transform) e início da trilha de mainframe COBOL. Squads humanos dedicados a módulos de alto risco em paralelo. Revisões de arquitetura quinzenais para ajuste de classificação de risco conforme padrões emergem. Pipeline de CI/CD unificado com gates de segurança obrigatórios para ambas as trilhas. Relatórios de progresso mensais para stakeholders com métricas de qualidade. 4. **Meses 18–36: VMware e Finalização** — Execução do plano de migração VMware→EC2 gerado pelo Transform Agent. Validação de performance pós-migração. Descomissionamento progressivo de VMs. Finalização dos módulos COBOL de alto risco. Consolidação de documentação de arquitetura. Transferência de ownership para times de produto. ## Avaliação pelo AWS Well-Architected Framework - **security**: A sanitização de código antes da análise pelo Transform é controle obrigatório. A sandbox de modernização em conta isolada com IAM mínimo e CloudTrail é o padrão correto. Todo código gerado passa por SAST antes do merge. Segredos nunca devem estar no código analisado — usar AWS Secrets Manager ou Parameter Store como parte do código modernizado. - **reliability**: O pipeline híbrido tem dois caminhos de transformação independentes. Uma falha ou indisponibilidade do AWS Transform afeta apenas a trilha de baixo/médio risco — a trilha humana continua. O design modular permite substituir o motor de IA sem redesenhar o processo de governança. - **sustainability**: A migração VMware→EC2 nativo, habilitada pelo Transform Agent de VMware, elimina a camada de virtualização desnecessária e permite right-sizing de instâncias. Isso reduz consumo de recursos e custo operacional a longo prazo. > **Minha Perspectiva Sênior:** O debate 'IA vs humanos em modernização' é frequentemente mal formulado. A pergunta certa é: onde o custo de um erro é alto o suficiente para justificar o custo de um engenheiro sênior revisando cada linha? Em sistemas financeiros, essa linha existe e é clara — lógica de cálculo de juros, regras de compliance, integrações com sistemas de liquidação. Nesses módulos, eu não confiaria em nenhum agente de IA sem revisão humana profunda, independente do quão impressionante seja o relatório de transformação. O que me convence no AWS Transform não é a promessa de automação total — é a rastreabilidade. Um diff de código com proveniência documentada, gerado por um agente com comportamento determinístico para aquela versão do serviço, é um artefato de governança melhor do que o histórico de commits de muitas fábricas humanas que já auditei. O problema é que a maioria das organizações não constrói o processo de revisão proporcional ao risco — elas aprovam os relatórios do Transform em massa porque o volume é grande e o prazo é curto. Isso é onde os programas falham. Minha recomendação prática: antes de executar uma única transformação com AWS Transform, invista 4–6 semanas em discovery e classificação de risco. Não pule essa fase para ganhar velocidade — ela é o que torna o restante do programa defensável em uma auditoria ou em um post-mortem de incidente. E defina explicitamente, no início do programa, que todo código gerado por IA é de responsabilidade do engenheiro que aprovou o PR — sem exceções, sem ambiguidade. Ownership claro é o único antídoto para o risco de regressão silenciosa em escala. ## Veredicto AWS Transform é uma ferramenta genuinamente útil para programas de modernização de escala corporativa — não porque elimina o trabalho de engenharia, mas porque o redistribui de forma mais eficiente. O agente de .NET Framework para .NET 8 resolve um problema de escala real: centenas de projetos com padrões de upgrade repetitivos que não justificam engenheiro sênior em cada um. O agente de VMware resolve um problema de planejamento complexo que historicamente consome semanas de arquiteto. O agente de COBOL aborda um dos problemas mais difíceis da indústria — a escassez de engenheiros com conhecimento de COBOL e a complexidade de converter lógica de negócio de décadas. O risco real não está no agente de IA — está no processo que o envolve. Programas que tratam AWS Transform como uma caixa preta que produz código pronto para produção vão descobrir regressões em produção. Programas que constroem um processo de revisão proporcional ao risco, com ownership claro e governança auditável, vão colher os benefícios de velocidade sem sacrificar a confiabilidade. A decisão híbrida documentada aqui — Transform para baixo/médio risco, engenharia humana para alto risco, revisão obrigatória para tudo — não é a mais simples de executar, mas é a que eu defenderia em qualquer board de arquitetura ou comitê de auditoria. Em sistemas onde o custo de uma regressão é alto, a complexidade operacional de um processo de governança robusto é um investimento, não um overhead. ## Referências - [AWS Transform — Product Page](https://aws.amazon.com/transform/) - [AWS News Blog — AWS Transform at 1 year](https://aws.amazon.com/blogs/aws/) - [AWS Migration Hub — Modernization](https://aws.amazon.com/migration-hub/) - [AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/) - [NIST SP 800-218 — Secure Software Development Framework](https://csrc.nist.gov/publications/detail/sp/800-218/final) - [Michael Feathers — Working Effectively with Legacy Code](https://www.oreilly.com/library/view/working-effectively-with/0131177052/) - [AWS CodeGuru — Automated Code Reviews](https://aws.amazon.com/codeguru/) ## Fontes do caso - [AWS News Blog — AWS Transform at 1 year](https://aws.amazon.com/blogs/aws/) - [AWS Transform](https://aws.amazon.com/transform/)