Os 7Rs da Modernização: Guia Completo e Atualizado7Rs da modernização
Você já deve ter visto pelo menos duas listas diferentes dos “7Rs da modernização” — e reparou que elas não batem. Uma cita Rearchitect. Outra cita Relocate. Uma tem Repurchase, a outra não. Isso não é erro de digitação de quem escreveu. É porque o framework tem uma história de 15 anos, com pelo menos três versões diferentes ao longo do caminho.
Esse artigo esclarece de onde vêm os 7Rs, qual versão é a oficial hoje, por que existe uma variante focada em decisão de negócio (que é a que usamos no guia completo de modernização de legado) — e, principalmente, onde a IA realmente muda o resultado de cada estratégia.
O que são os 7Rs da modernização
Os 7Rs são um framework de decisão. Cada “R” representa uma estratégia diferente para tratar um sistema legado — da mais simples (manter como está) até a mais profunda (reconstruir do zero).
O framework existe porque nem todo sistema merece o mesmo nível de investimento. Aplicar a estratégia errada — seja de menos, seja de mais — é uma das formas mais caras de desperdiçar orçamento de modernização.
A origem do framework — e por que existem versões diferentes
A confusão que você provavelmente já viu por aí tem uma explicação histórica simples: o framework foi criado, ampliado e reinterpretado por atores diferentes, em momentos diferentes.
2010 — a Gartner cria as 5 estratégias originais
A Gartner publicou o primeiro modelo com cinco caminhos possíveis: Rehost, Refactor, Revise, Rebuild e Replace. Esse era o vocabulário original — e já não é mais o vocabulário mais usado hoje.
2016 — a AWS expande para 6, com foco em migração para nuvem
A AWS publicou seu próprio modelo de referência, reorganizando os termos e adicionando Retire como sexta estratégia — reconhecendo que parte do portfólio simplesmente não deveria ser migrado, e sim desligado.
2017 — nasce o sétimo R, motivado por um lançamento técnico específico
Aqui está o ponto que quase nenhum conteúdo em português explica: segundo o blog oficial de estratégia empresarial da AWS, o modelo de 6 R’s evoluiu para 7 especificamente com o lançamento do VMware Cloud on AWS, no fim de 2017. O sétimo R adicionado foi o Relocate — migração em nível de hypervisor, sem reescrever nada.
Isso significa que a versão “oficial” mais citada hoje, segundo a documentação técnica da AWS, é: Rehost, Relocate, Replatform, Repurchase, Refactor, Retire e Retain.
“Existem sete estratégias de migração para mover aplicações para a nuvem, conhecidas como os 7 Rs: rehost, relocate, replatform, repurchase, refactor, retain e retire.”
— AWS Prescriptive Guidance
Linha do tempo da evolução dos 7Rs: Gartner 2010 até AWS 2017
Por que este conteúdo usa uma variante diferente da AWS
Repare que a versão oficial da AWS é orientada a infraestrutura — Relocate, por exemplo, é sobre mover máquinas virtuais, não sobre transformar código. Faz todo sentido para migração de cloud pura. Faz menos sentido quando o problema é modernizar a lógica de negócio de um sistema legado.
Por isso, boa parte do conteúdo especializado em modernização de aplicações — inclusive o nosso — usa uma variante orientada a decisão de negócio, substituindo Relocate por dois níveis de transformação de código: Rearchitect (redesenho da arquitetura) e Rebuild (reconstrução completa). Nenhuma das duas está “errada”. São lentes diferentes para problemas diferentes.
| Versão | Foco | As 7 estratégias |
|---|---|---|
| AWS (oficial, 2017) | Migração de infraestrutura para nuvem | Rehost, Relocate, Replatform, Repurchase, Refactor, Retire, Retain |
| Decisão de negócio (usada neste hub) | Transformação de aplicações legadas | Retain, Retire, Rehost, Replatform, Refactor, Rearchitect, Rebuild |
Os 7Rs explicados um a um
A partir daqui, seguimos a variante de decisão de negócio — a mesma usada no guia completo de modernização de legado — por ser a mais aplicável a quem está decidindo o que fazer com um sistema legado, não só onde hospedá-lo.
Retain — manter como está
Não investir agora. Faz sentido para sistemas de baixo risco e baixo valor estratégico, ou quando outras prioridades competem pelo mesmo orçamento. O erro comum é tratar “retain” como omissão — na prática, é uma decisão ativa, revisitada periodicamente.
Retire — desativar
Descontinuar um sistema redundante ou substituído por outro. É a estratégia mais barata e mais subutilizada: projetos de modernização raramente começam perguntando “o que dá pra simplesmente desligar?”
Rehost — mover sem alterar
Também chamado de “lift and shift”. Move a aplicação para um novo ambiente sem tocar no código. Rápido, de baixo risco, mas não resolve dívida técnica — só muda onde ela mora.
Replatform — ajustar sem redesenhar
Troca peças específicas (um banco de dados, um servidor de aplicação) sem mexer na arquitetura geral. Ganho de performance rápido, esforço moderado.
Refactor — reestruturar o código
Reorganiza o código internamente, mantendo o comportamento da aplicação. Reduz dívida técnica sem mudar o que o sistema faz — apenas como ele faz.
Rearchitect — redesenhar a arquitetura
Vai além do refactor: muda o desenho estrutural, por exemplo de monólito para microsserviços. Reservado para sistemas críticos que precisam escalar e não escalam mais do jeito atual.
Rebuild — reconstruir do zero
Reconstrói a aplicação inteira, preservando o valor de negócio acumulado. A estratégia de maior esforço — e também a mais mal aplicada quando escolhida sem necessidade real.
Onde a IA realmente acelera cada R
Nem todo R se beneficia igualmente de IA. Isso raramente aparece nos conteúdos sobre o tema — e é decisivo na hora de estimar prazo e orçamento.
| Estratégia | Impacto da IA | Por quê |
|---|---|---|
| Retain / Retire | Baixo | São decisões de portfólio, não de código — IA ajuda no discovery, não na execução |
| Rehost | Baixo | Já é altamente automatizável com ferramentas tradicionais, sem precisar de IA generativa |
| Replatform | Médio | IA ajuda a mapear dependências e prever pontos de quebra na troca de componentes |
| Refactor | Alto | Engenharia reversa com IA reduz drasticamente o tempo de entender código não documentado antes de reestruturar |
| Rearchitect | Alto | Agentes de IA aceleram geração de testes e validação em cada etapa de decomposição da arquitetura |
| Rebuild | Alto | Geração de código assistida reduz esforço de reconstrução, mas exige revisão humana constante |
Segundo a McKinsey, agentes de IA aplicados a projetos de modernização podem reduzir prazos de execução em até 50% — mas esse ganho se concentra nas estratégias de transformação de código (Refactor, Rearchitect, Rebuild), não nas de infraestrutura.
Como escolher o R certo para cada sistema
Os 7Rs respondem “como fazer”. Mas antes vem “o quê fazer” — e essa decisão é sobre valor de negócio e risco técnico, não sobre tecnologia.
No guia de modernização de legado, detalhamos a matriz completa de priorização. O resumo prático:
- Alto valor, alto risco → normalmente pede Rearchitect ou Rebuild
- Alto valor, baixo risco → geralmente Replatform ou Refactor são suficientes
- Baixo valor, alto risco → avaliar Retire antes de investir em qualquer R mais profundo
- Baixo valor, baixo risco → Retain quase sempre é a resposta certa
Os 7 Rs da modernização organizados por nível de esforço
Erros comuns ao aplicar os 7Rs
O erro mais citado por especialistas em portfólio de aplicações — inclusive em análises da própria Gartner — é o “portfolio overreach”: aplicar Rearchitect ou Rebuild em sistemas que só precisavam de Rehost ou Retain, porque a estratégia mais ambiciosa “parece” a decisão certa.
- Escolher o R pela ambição, não pelo sistema: Rearchitect soa mais estratégico, mas nem todo sistema justifica esse esforço.
- Tratar Retain como omissão: manter é uma decisão válida — não é “não decidir”.
- Aplicar o mesmo R para todo o portfólio: a maioria dos projetos bem-sucedidos combina 3 a 5 estratégias diferentes, não uma única receita.
- Ignorar Retire: sistemas sem uso real raramente entram na lista de prioridade — mas são a forma mais barata de reduzir escopo.
Como a Framework aplica os 7Rs na prática
No projeto com a Unimed-BH, o sistema CIH (Controle de Internação Hospitalar) chegou sem documentação, sem suporte do fornecedor original e sem cobertura de testes — cenário clássico onde Rehost ou Replatform não resolveriam o problema de fundo.
A Framework aplicou uma combinação de Refactor guiado por engenharia reversa com IA e agentes autônomos para reestruturar o sistema, resultando em ganho operacional de 67,4% e redução de 60% no custo de modernização frente à abordagem tradicional. Os detalhes completos do case estão no guia de modernização de legado.
Perguntas frequentes sobre os 7Rs da modernização
Qual é a diferença entre os 7Rs da AWS e os 7Rs usados em modernização de aplicações?
A versão oficial da AWS (Rehost, Relocate, Replatform, Repurchase, Refactor, Retire, Retain) é voltada para migração de infraestrutura para nuvem. A variante usada em modernização de aplicações substitui Relocate por Rearchitect e Rebuild, porque o foco passa a ser transformação de código e arquitetura, não apenas onde o sistema roda.
Preciso usar só um R para todo o meu portfólio de sistemas?
Não. A maioria dos projetos de modernização bem-sucedidos combina de 3 a 5 estratégias diferentes dentro do mesmo portfólio, aplicando o R certo sistema por sistema — não uma única receita para tudo.
Qual R é mais barato?
Retain (manter como está) e Retire (desativar) são as estratégias de menor custo direto. Rehost costuma ser o R mais barato entre as que envolvem migração de fato.
Qual R exige mais tempo e investimento?
Rebuild, seguido de Rearchitect. Ambos envolvem transformação profunda e costumam levar meses, mesmo com apoio de IA.
A IA elimina a necessidade de escolher entre os 7Rs?
Não. A IA acelera a execução de algumas estratégias — principalmente Refactor, Rearchitect e Rebuild — mas a decisão de qual R aplicar continua sendo uma escolha de negócio, baseada em valor e risco de cada sistema.
O que é “portfolio overreach” na modernização?
É o erro de aplicar estratégias mais ambiciosas do que o necessário — como Rearchitect ou Rebuild em sistemas que só precisavam de Rehost ou Retain — inflando custo e prazo sem ganho proporcional.
A virada
Os 7Rs não são uma lista para decorar. São uma ferramenta para evitar o erro mais caro da modernização: tratar todo sistema legado como se merecesse o mesmo nível de esforço.
O sistema certo, com o R certo, custa uma fração do que custa aplicar a estratégia errada em escala.
Se você já sabe quais sistemas do seu portfólio precisam de decisão — e quer aplicar o R certo com quem já fez isso em produção, não em teoria —, a nossa AI Session é o próximo passo.
