# AWS Transform 1 Ano: Modernização Agêntica de Legados em Produção

AWS Transform chegou prometendo modernização de legados com agentes de IA — após um ano, vale examinar o que realmente entrega, onde falha e qual o custo real de adoção em sistemas críticos. Esta análise parte de evidências técnicas concretas, não de marketing.

- URL: https://fernando.moretes.com/blog/aws-transform-modernizacao-agentic-legacy

- Markdown: https://fernando.moretes.com/blog/aws-transform-modernizacao-agentic-legacy/article.md?lang=pt

- Published: 2026-06-15T15:40:00.000Z

- Category: Arquitetura de Soluções

- Tags: aws-transform, modernization, agentic-ai, legacy, migration, governance, bedrock, financial-grade

- Reading time: 10 min

- Source: [AWS Transform at 1 year and custom transformations](https://aws.amazon.com/blogs/aws/)

---

Depois de dezesseis anos ajudando organizações financeiras a migrar sistemas que ninguém mais quer tocar — COBOL em mainframe, Java EE 5 em servidores bare-metal, PL/SQL com lógica de negócio enterrada em triggers — eu aprendi que a parte mais difícil da modernização não é a tecnologia de destino: é entender o que o código legado realmente faz. O AWS Transform chegou em 2024 com uma proposta audaciosa: usar agentes de IA para automatizar exatamente essa etapa de análise e transformação. Um ano depois, com o serviço ganhando suporte a transformações customizadas, é hora de uma avaliação honesta — o que funciona, o que não funciona, e o que um arquiteto sênior precisa saber antes de colocar isso em um pipeline de produção financeiro.

## Números que importam após um ano

- **~60%** — Redução de esforço manual reportada em migrações Java → Java 17. Para projetos Maven/Gradle com cobertura de testes acima de 70%; cai significativamente abaixo disso
- **3-5x** — Multiplicador de custo de revisão humana em código gerado sem guardrails. Transformações sem validação automatizada criam débito técnico oculto que custa mais do que a migração manual
- **< 6 meses** — Maturidade real do suporte a transformações customizadas. O recurso de custom transformations ainda está em early adoption; documentação de edge cases é esparsa

## O que o AWS Transform realmente é — e o que não é

AWS Transform não é um botão mágico de modernização. É uma plataforma de orquestração agêntica que coordena análise estática de código, geração de transformações via modelos de linguagem (principalmente via Amazon Bedrock), execução de testes automatizados e um loop de feedback para refinamento iterativo. A arquitetura interna se assemelha a um workflow de Step Functions com agentes especializados: um agente de análise que constrói um grafo de dependências do código-fonte, um agente de transformação que gera código-alvo, e um agente de validação que executa suítes de teste e interpreta falhas.

O caso de uso primário no lançamento era migração de Java 8/11 para Java 17/21, com suporte a Maven e Gradle. Isso é deliberadamente estreito — e essa estreiteza é uma virtude de engenharia, não uma limitação de marketing. Sistemas com escopo bem definido, toolchain conhecida e cobertura de testes razoável são exatamente onde automação agêntica entrega valor real. O problema começa quando organizações tentam extrapolar isso para cenários mais complexos: COBOL para Java, PL/SQL para Aurora, ou monolitos com dependências circulares e zero testes.

O suporte a transformações customizadas, adicionado no primeiro aniversário, muda o jogo de forma interessante: agora é possível definir receitas de transformação próprias — regras de refatoração, padrões de substituição de API, políticas de nomenclatura — que o agente aplica como restrições durante a geração. Isso aproxima o Transform de um framework de governança de modernização, não apenas de uma ferramenta de migração.

## Pipeline Agêntico do AWS Transform — Fluxo de Modernização

Fluxo interno do AWS Transform desde o código legado até o artefato modernizado, mostrando os agentes especializados, os loops de validação e os pontos de integração com serviços AWS subjacentes.

### 📦 Source — Legacy Codebase

- Legacy Repo Git / S3 upload (storage)
- Build Manifest pom.xml / build.gradle (external)

### 🔍 AWS Transform — Analysis Phase

- Analysis Agent dependency graph + AST (ai)
- Custom Transform Rules recipes / guardrails (security)

### 🤖 AWS Transform — Generation Phase

- Amazon Bedrock Claude / Titan (ai)
- Transform Agent code generation + patch (ai)

### ✅ AWS Transform — Validation Phase

- Build Runner Maven / Gradle exec (compute)
- Validation Agent test suite + failure triage (ai)
- Feedback Loop max N iterations (compute)

### 🏦 Governance & Audit

- Diff Report human review gate (security)
- CloudWatch Logs agent reasoning traces (data)

### 📤 Output

- Modernized Repo PR / branch (storage)

### Fluxos

- legacy-repo -> analysis-agent: ingere código-fonte
- build-manifest -> analysis-agent: resolve dependências
- custom-rules -> transform-agent: aplica receitas
- analysis-agent -> transform-agent: grafo + contexto
- transform-agent -> bedrock-llm: prompt + AST
- bedrock-llm -> transform-agent: código gerado
- transform-agent -> build-runner: patch aplicado
- build-runner -> test-agent: resultado de build/teste
- test-agent -> feedback-loop: falha detectada
- feedback-loop -> transform-agent: retentar com contexto de erro
- test-agent -> diff-report: validação aprovada
- transform-agent -> cloudwatch-logs: reasoning trace
- diff-report -> modernized-repo: aprovação humana → merge

## Onde o Transform brilha: o caso Java e a lógica de automação agêntica

A migração de Java 8/11 para Java 17/21 é um problema estruturalmente bem-adequado para automação agêntica por três razões: o espaço de transformações é finito e bem documentado (APIs removidas, mudanças de módulo do JPMS, novos padrões de linguagem), o toolchain de build é determinístico (Maven/Gradle produz resultados reprodutíveis), e a validação é objetiva (o código compila ou não, os testes passam ou não). Esse triângulo — espaço finito, build determinístico, validação objetiva — é o perfil ideal para um agente de transformação.

Em projetos com cobertura de testes acima de 70% e dependências bem gerenciadas (sem JARs proprietários de terceiros sem equivalente moderno), o Transform consegue processar a migração com intervenção humana mínima. O loop de feedback interno — onde o agente de validação interpreta falhas de compilação e repassa contexto ao agente de transformação — é genuinamente útil para erros de migração comuns como uso de `sun.misc.Unsafe`, APIs de reflexão removidas e incompatibilidades de serialização.

O suporte a custom transformations adiciona uma camada de governança que faz diferença em ambientes financeiros: é possível codificar políticas como 'nunca use `java.util.Date`, substitua sempre por `java.time.LocalDate`' ou 'toda chamada a biblioteca X deve ser substituída por biblioteca Y com esse mapeamento de API específico'. Isso transforma o Transform em um veículo de enforcement de padrões arquiteturais durante a migração — algo que normalmente exige revisão manual extensiva em code reviews.

## Pontos fortes reais do AWS Transform

- Loop de feedback agêntico com rastreamento de reasoning via CloudWatch Logs — auditável e reprodutível, o que importa em compliance financeiro
- Custom transformation recipes permitem codificar padrões arquiteturais como restrições de geração, não apenas como guidelines de documentação
- Integração nativa com CodeCatalyst e repositórios Git reduz o atrito de onboarding para equipes que já vivem no ecossistema AWS
- O modelo de pricing baseado em LOC transformadas (não em tempo de execução) é previsível para projetos com escopo definido
- Isolamento de dados: o código-fonte não é usado para treinar modelos — ponto crítico para propriedade intelectual em fintechs e bancos

## Limites reais: onde o Transform falha em ambientes financeiros

O problema fundamental do Transform em sistemas financeiros de missão crítica não é técnico — é epistêmico. O agente não tem como saber o que o código legado *deveria* fazer quando a intenção original foi perdida. Em sistemas de core banking com 15 anos de patches acumulados, há frequentemente lógica de negócio crítica — cálculos de juros compostos, regras de elegibilidade de crédito, tratamento de exceções regulatórias — que está correta não porque segue um padrão reconhecível, mas porque foi corrigida manualmente após incidentes de produção e nunca documentada adequadamente.

Nesse cenário, o Transform pode produzir código que compila, passa nos testes existentes e ainda assim está errado — porque os testes existentes não cobrem os edge cases que foram descobertos em produção. Isso não é uma falha do Transform especificamente; é uma falha do processo de modernização sem cobertura de testes adequada. Mas é uma falha que o marketing do serviço tende a suavizar.

Outro limite crítico é o tratamento de dependências proprietárias. Em ambientes bancários, é comum ter SDKs de HSM (Hardware Security Module), bibliotecas de conectividade com sistemas de clearing (SWIFT, SPB, CIP), e adaptadores para sistemas de mainframe que não têm equivalente moderno documentado. O agente não consegue transformar o que não conhece — e não tem mecanismo para sinalizar claramente 'esta dependência não tem mapeamento conhecido' de forma que integre com um workflow de revisão humana estruturado. A documentação de custom transformations para esse caso ainda é insuficiente.

Finalmente, o modelo de iteração do agente tem um limite configurável de tentativas. Em projetos com alta complexidade ciclomática e dependências cruzadas, o agente pode esgotar o orçamento de iterações sem convergir — e o estado intermediário deixado não é facilmente retomável por um engenheiro humano.

> **Armadilha crítica: testes passando ≠ comportamento correto:** Em sistemas financeiros, nunca use a taxa de sucesso de testes automatizados como único critério de aceitação para código gerado pelo Transform. Testes existentes refletem o comportamento *conhecido* do sistema, não o comportamento *correto*. Antes de qualquer migração com Transform, invista em mutation testing (PIT para Java) e em testes de contrato baseados em dados históricos de produção. Sem isso, você está validando que o agente reproduziu fielmente bugs históricos — o que não é modernização.

## Custom Transformations: governança como código de modernização

O recurso de custom transformations é, na minha avaliação, a adição mais arquiteturalmente significativa do primeiro ano. A ideia central é que você pode definir um conjunto de regras de transformação — em formato que o Transform interpreta como restrições de geração — e o agente as aplica consistentemente em toda a base de código. Isso resolve um problema real que qualquer arquiteto de modernização conhece: a deriva de padrões ao longo de uma migração longa.

Em uma migração de 18 meses com 50 desenvolvedores, é praticamente impossível garantir que todos apliquem as mesmas decisões de refatoração de forma consistente. Custom transformations permitem codificar essas decisões uma vez e aplicá-las automaticamente. Exemplos concretos de uso em ambientes financeiros: substituição sistemática de `java.util.logging` por SLF4J com MDC configurado para correlation IDs (obrigatório para rastreabilidade em sistemas de pagamento), migração de padrões de tratamento de exceções checked para unchecked com wrappers padronizados, e substituição de chamadas diretas a APIs de criptografia por chamadas ao SDK do AWS KMS com configuração de key policy específica.

O mecanismo de aplicação das regras ainda tem limitações: não há suporte nativo para regras condicionais complexas (se a classe implementa interface X, então aplique transformação Y, senão aplique Z), e a documentação de como as regras interagem com o grafo de dependências do agente de análise é insuficiente. Para casos de uso avançados, você vai precisar de um engenheiro dedicado a iterar nas receitas de transformação — o que é um custo operacional que deve entrar no planejamento.

## Como adotar o AWS Transform em ambientes financeiros: sequência defensiva

1. **1. Qualifique o portfólio antes de qualquer execução** — Execute análise estática (SonarQube, Checkstyle, Dependency-Check) no código-fonte para mapear: cobertura de testes atual, dependências proprietárias sem equivalente moderno, complexidade ciclomática por módulo e uso de APIs removidas na versão alvo. Projetos com cobertura < 40% ou dependências sem mapeamento devem ser excluídos do escopo inicial do Transform.

2. **2. Construa a suíte de testes de contrato antes da migração** — Use dados históricos de produção (anonimizados conforme LGPD/GDPR) para criar testes de contrato que capturam o comportamento real do sistema. Ferramentas como Pact ou testes parametrizados com JUnit 5 são adequadas. Esses testes são o seu critério de aceitação real — não os testes unitários existentes.

3. **3. Configure custom transformation rules antes da primeira execução** — Codifique as decisões arquiteturais da migração como receitas de transformação: padrões de logging, políticas de criptografia (KMS key ARNs, algoritmos aprovados), substituições de bibliotecas de terceiros, e padrões de tratamento de exceções. Isso garante que o agente aplique suas decisões de design, não as suas próprias inferências.

4. **4. Execute em módulos isolados, não no monolito inteiro** — Comece pelos módulos com maior cobertura de testes e menor número de dependências externas. Use feature flags para ativar o código migrado em produção gradualmente (canary release com 1% → 10% → 100% de tráfego). Monitore métricas de negócio (taxa de erro de transação, latência de processamento) além das métricas técnicas.

5. **5. Ative reasoning traces e integre ao seu SIEM** — Configure o Transform para emitir reasoning traces completos para CloudWatch Logs. Crie log groups dedicados com retenção de 90 dias (mínimo para auditoria em ambientes regulados). Integre com seu SIEM (Splunk, Datadog, Security Hub) para detectar padrões anômalos de geração — por exemplo, o agente tentando contornar uma custom rule repetidamente.

6. **6. Estabeleça um human-in-the-loop gate obrigatório** — Nunca configure o Transform para fazer merge automático de código gerado em branches de produção. O diff report gerado pelo Transform deve passar por revisão de um arquiteto sênior antes do merge — especialmente para módulos que tocam lógica de cálculo financeiro, autenticação ou integração com sistemas externos regulados.

## Observabilidade do processo agêntico: o que você precisa monitorar

Um dos aspectos menos discutidos do AWS Transform é a observabilidade do próprio processo de modernização. Em ambientes financeiros regulados, você não pode simplesmente executar uma transformação e confiar no resultado — você precisa ser capaz de demonstrar, para auditores internos e externos, exatamente quais decisões o agente tomou, por quê, e como foram validadas.

O Transform emite reasoning traces para CloudWatch Logs quando configurado adequadamente. Esses traces incluem: o grafo de dependências construído pelo agente de análise, as transformações candidatas consideradas pelo agente de geração, os resultados de cada iteração do loop de validação, e as custom rules aplicadas (ou que falharam em ser aplicadas). Isso é material de auditoria valioso — mas só se você configurar retenção adequada e estruturar os logs para consulta.

Minha recomendação é criar um CloudWatch Log Group dedicado para Transform com retenção de 90 dias, exportar para S3 com S3 Object Lock (WORM) para compliance, e criar CloudWatch Insights queries para detectar: iterações que esgotaram o budget sem convergir (sinal de complexidade não gerenciável), custom rules que foram violadas pelo agente (sinal de receita mal definida), e módulos que tiveram taxa de falha de testes acima de 20% após transformação (sinal de cobertura insuficiente).

Para integração com OpenTelemetry — que uso em todos os meus projetos de plataforma — o Transform ainda não emite traces OTLP nativamente. A solução atual é parsear os CloudWatch Logs e criar spans sintéticos via um Lambda de processamento. Não é elegante, mas funciona para criar visibilidade end-to-end no Datadog ou Grafana junto com o restante do pipeline de CI/CD.

## AWS Transform vs. abordagens alternativas de modernização
| Critério | Critério | AWS Transform | Migração manual assistida por LLM (Copilot/Cursor) | Ferramentas especializadas (OpenRewrite, Moderne) |
| --- | --- | --- | --- | --- |
| Escopo suportado | Java 8→17/21; expansão em curso | Qualquer linguagem/plataforma | Java, Kotlin, Groovy, XML configs | — |
| Consistência de padrões | Alta com custom rules bem definidas | Baixa — depende do engenheiro | Muito alta — baseada em receitas determinísticas | — |
| Auditabilidade | Média — traces disponíveis mas não estruturados para SIEM | Baixa — decisões implícitas no contexto do desenvolvedor | Alta — transformações declarativas e versionáveis | — |
| Custo para 500k LOC | ~$15k–$30k estimado (pricing por LOC + Bedrock) | $80k–$200k em horas de engenheiro sênior | $5k–$20k (licença Moderne) + esforço de receita | — |
| Adequação para ambientes financeiros | Média — requer guardrails adicionais | Alta — controle total, mas escala limitada | Alta — determinístico e auditável por design | — |

> **OpenRewrite como complemento, não como concorrente:** A combinação que encontrei mais eficaz em projetos reais é usar OpenRewrite (via Moderne ou diretamente) para as transformações determinísticas e bem-documentadas — atualizações de Spring Boot, migrações de JUnit 4→5, substituições de imports — e o AWS Transform para as transformações que requerem raciocínio contextual sobre o código: refatorações de lógica complexa, consolidação de padrões inconsistentes, e modernização de tratamento de exceções. As duas ferramentas se complementam melhor do que competem.

## Lente Well-Architected aplicada ao AWS Transform

- **security**: O código-fonte não é usado para treinar modelos (confirmado pela AWS), mas você ainda precisa garantir que o IAM role do Transform tenha permissões mínimas sobre o repositório de código. Use uma IAM policy com condição `aws:ResourceTag` para restringir acesso apenas aos repositórios qualificados para migração. Configure KMS CMK para criptografia dos artefatos intermediários gerados pelo agente.
- **reliability**: O limite de iterações do agente é um risco de confiabilidade: projetos complexos podem não convergir. Mitigue com decomposição prévia do monolito em módulos menores antes de submeter ao Transform. Defina critérios de saída claros: se após N iterações a taxa de falha de testes não caiu abaixo de X%, escale para revisão humana em vez de continuar iterando.
- **performance**: O tempo de processamento do Transform é dominado pelo tamanho do grafo de dependências e pelo número de iterações do loop de validação. Para bases de código grandes (>200k LOC), espere horas de execução. Planeje janelas de transformação fora do horário de pico de CI/CD para evitar contenção de recursos de build.
- **cost**: O pricing do Transform é composto: há um custo por LOC transformada mais os custos de inferência do Bedrock (que variam por modelo e número de tokens). Para projetos grandes, o custo de Bedrock pode superar o custo do Transform em si. Monitore via Cost Explorer com tags de projeto e defina budgets com alertas em 80% do orçamento planejado.

> **Minha nota de curadoria:** Depois de avaliar o Transform em contexto de projetos financeiros reais, minha posição é esta: use-o como acelerador de modernização para o subconjunto do portfólio onde as pré-condições estão satisfeitas — cobertura de testes adequada, dependências mapeáveis, toolchain determinístico. Não o use como substituto para a análise arquitetural humana que precede qualquer migração séria. A lição mais dura que aprendi em modernizações é que a automação amplifica tanto a competência quanto a incompetência: se você não entende o que está migrando, o Transform vai modernizar seus problemas mais rapidamente do que você consegue perceber. O investimento em custom transformation rules é onde o ROI real está — não na execução automática, mas na codificação das suas decisões arquiteturais como restrições de geração, o que cria um ativo reutilizável para todo o portfólio.

## Veredicto: promissor, mas ainda em maturação para ambientes críticos

O AWS Transform após um ano é uma ferramenta genuinamente útil para o problema específico que se propõe a resolver: modernização de Java em projetos com boa cobertura de testes e toolchain bem definida. O suporte a custom transformations é a adição mais importante e transforma o serviço de uma ferramenta de migração em um framework de governança de modernização — o que é uma proposta de valor muito mais interessante para organizações com portfólios grandes. As limitações são reais e não devem ser minimizadas: a dependência de cobertura de testes existente, a dificuldade com dependências proprietárias, e a observabilidade ainda imatura para ambientes regulados. Para ambientes financeiros de missão crítica, minha recomendação é adoção seletiva e defensiva: qualifique rigorosamente o portfólio, invista em custom rules antes de executar, e nunca abra mão do human-in-the-loop gate. O Transform não substitui arquitetos — ele os libera para trabalhar nos problemas que realmente exigem julgamento humano. Isso, por si só, já justifica a avaliação.

**Rating:** 7/10 — Adoção Seletiva / Selective Adopt

## Referências e leituras complementares

- [AWS Transform – Official Documentation](https://docs.aws.amazon.com/transform/latest/userguide/what-is-transform.html)
- [AWS News Blog – AWS Transform at 1 year and custom transformations](https://aws.amazon.com/blogs/aws/)
- [Amazon Bedrock – Model invocation logging and audit](https://docs.aws.amazon.com/bedrock/latest/userguide/model-invocation-logging.html)
- [OpenRewrite – Automated source code refactoring](https://docs.openrewrite.org/)
- [Moderne – Enterprise OpenRewrite platform](https://docs.moderne.io/)
- [AWS Well-Architected Framework – Migration Lens](https://docs.aws.amazon.com/wellarchitected/latest/migration-lens/migration-lens.html)
- [PIT Mutation Testing for Java](https://pitest.org/)
- [Accelerate: The Science of Lean Software and DevOps – Forsgren, Humble, Kim](https://itrevolution.com/product/accelerate/)