Português 
English
Modernizar um sistema legado não é uma decisão única: é uma decisão por sistema. Cada aplicação tem valor, estado técnico, risco e urgência diferentes, e por isso pode pedir um caminho diferente: mover para outra infraestrutura (rehost), trocar parte da plataforma (replatform), reorganizar o código (refactor), mudar a arquitetura (rearchitect) ou reconstruir do zero (rewrite).
Este guia é para CTOs, gerentes de TI e arquitetos de empresas médias e grandes que dependem de sistemas próprios ou customizados. Você vai encontrar uma tabela comparando as cinco rotas, um framework de cinco perguntas para decidir, o padrão strangler fig para modernizar sem parar a operação e um roteiro em quatro fases.
Quando modernizar e quando não modernizar
Modernizar vale quando o sistema ainda sustenta uma operação importante e o custo de mantê-lo como está (em risco, em dependência de poucas pessoas, em dificuldade de integração) supera o custo de mudá-lo. Quando o sistema perdeu relevância, a melhor decisão pode ser desativá-lo ou deixá-lo como está.
O Google Cloud define a modernização de sistemas legados como o processo de atualizar ou substituir sistemas, arquiteturas e infraestruturas desatualizados para alinhá-los melhor aos objetivos atuais e futuros do negócio. A mesma página destaca um ponto que orienta este guia: não existe abordagem única; a estratégia certa depende da aplicação, das metas, do orçamento e da tolerância a riscos.
Por isso, o ponto de partida não é escolher uma tecnologia, e sim classificar o portfólio. Os modelos mais completos, como os 7 Rs da AWS, incluem duas opções que muitas listas esquecem: retire (desativar o sistema) e retain (mantê-lo como está por enquanto, com data para revisar). Elas liberam orçamento e atenção para os sistemas que realmente precisam de investimento.
Se você ainda está avaliando se o seu sistema chegou a esse ponto, vale começar pelo conceito de dívida técnica e pelos sinais de que manter já custa mais do que modernizar. Aqui, partimos do princípio de que a decisão de modernizar já foi tomada e falta escolher o caminho.
As cinco rotas: rehost, replatform, refactor, rearchitect e rewrite
As cinco rotas diferem no que muda e no quanto custa errar: do rehost (só a infraestrutura) ao rewrite (tudo), crescem o esforço, o benefício potencial e o risco de perder conhecimento de negócio. O glossário da itemis descreve essa mesma progressão: o rehost move o sistema sem alterá-lo, refactor e rearchitect o transformam gradualmente, e o rewrite o desenvolve do zero, com o maior risco de perder conhecimento de negócio.
| Rota | O que muda | Risco | Esforço | Serve quando |
|---|---|---|---|---|
| Rehost | Só a infraestrutura | Baixo | Baixo | O sistema funciona, mas a infraestrutura é o problema |
| Replatform | A plataforma (banco, runtime, servidor de aplicação) | Baixo a médio | Médio | Há ganho em trocar a plataforma sem mexer na lógica |
| Refactor | O código, sem mudar o comportamento | Médio | Médio a alto | O problema está na qualidade interna do código |
| Rearchitect | A estrutura (monolito para módulos ou serviços) | Médio a alto | Alto | Escala e acoplamento exigem outra arquitetura |
| Rewrite | Tudo, do zero (ou troca por produto pronto) | Alto | Muito alto | A regra de negócio será repensada ou o código é irrecuperável |
Os níveis de risco e esforço são uma leitura editorial, consistente com as fontes citadas; não são dados medidos e variam por projeto.
Uma nota sobre terminologia: as fontes divergem. O modelo original da Gartner, de 2010 (segundo a IBM), tinha cinco Rs: rehost, refactor, revise, rebuild e replace; a AWS depois ampliou a lista para sete. Nesse modelo original, “refactor” significava rodar a aplicação em uma plataforma como serviço, sentido diferente do uso atual, que é reorganizar o código. Neste guia, usamos o sentido atual.
Rehost (lift and shift)
Rehost é mover o sistema para uma nova infraestrutura (em geral a nuvem) sem alterar código nem arquitetura. A IBM indica que funciona melhor quando a organização precisa migrar rápido, tem poucos recursos para rearquitetar ou quer benefícios imediatos, como reduzir custos de data center. O limite é claro: o sistema continua com os mesmos problemas, só em outro lugar. Para custos e riscos específicos de nuvem, veja o guia de migração de sistemas.
Replatform
Replatform troca parte da plataforma (um banco de dados, um servidor de aplicação, uma versão de runtime) para ganhar eficiência, sem reescrever a lógica. É um meio-termo entre o rehost e a reorganização do código: custa mais que mover o sistema como está, mas costuma evitar o risco de mexer em regras de negócio.
Refactor
Refactor reorganiza o código por dentro, sem mudar o que o sistema faz para o usuário. Resolve problemas como regras de negócio emaranhadas e dependência de poucas pessoas que entendem o código. Se você quer a definição completa e a diferença em relação à migração e à reescrita, veja o que é refatoração. Aqui, o que importa é quando escolher essa rota: quando o comportamento atual está bom e a estrutura interna é que atrapalha.
Rearchitect
Rearchitect muda a estrutura do sistema, por exemplo separando um monolito em módulos ou serviços. Custa mais e leva mais tempo que o refactor, porque altera a forma como os componentes se relacionam. Faz sentido quando escala, acoplamento ou necessidade de integração exigem outra arquitetura, e quando o sistema é estratégico para os próximos anos.
Rewrite (rebuild ou replace)
Rewrite é reconstruir o sistema do zero ou substituí-lo por um produto pronto. É a rota de maior risco, sobretudo pela perda de conhecimento de negócio embutido no sistema antigo. Costuma ser a escolha certa quando a regra de negócio será repensada, quando o código é irrecuperável ou quando existe um produto de mercado que atende. Rewrite não é um erro; é uma opção cara que precisa de justificativa.
Framework de decisão em cinco perguntas
Este framework é uma proposta da NextAge, construída sobre os modelos de 5 e 7 Rs. A ideia é responder cinco perguntas por sistema e deixar a rota emergir da combinação das respostas.
- O sistema ainda gera valor estratégico? Se não, retire ou retenha, e invista em outro lugar. Se sim, siga para a próxima pergunta.
- O problema está na infraestrutura, na plataforma ou no código? Se for a infraestrutura, a rota é rehost. Se for a plataforma, replatform. Se for o código ou a estrutura, siga para a terceira pergunta.
- Existem documentação, testes e conhecimento das regras de negócio? Se não, o rewrite corre o risco de perder regras que ninguém sabe que existem. Comece por uma etapa de descoberta e por testes que registrem o comportamento atual.
- Quanto a operação tolera de parada? Se a tolerância é baixa, prefira uma rota incremental (strangler fig, tratada a seguir). Se há janelas de parada aceitáveis, um corte em bloco pode ser viável.
- Qual é o horizonte e o orçamento? Com horizonte curto, rehost ou replatform resolvem o urgente, e refactor ou rearchitect ficam para uma segunda fase. Com horizonte longo e sistema estratégico, um rearchitect incremental costuma compensar.
O resultado pode ser registrado em uma tabela simples, com uma linha por sistema:
| Sistema | Valor estratégico | Problema principal | Conhecimento documentado | Tolerância a parada | Rota recomendada |
|---|---|---|---|---|---|
| Exemplo A | Alto | Estrutura (acoplamento) | Parcial | Baixa | Rearchitect incremental |
| Exemplo B | Médio | Infraestrutura | Sim | Média | Rehost |
| Exemplo C | Baixo | Não se aplica | Não se aplica | Não se aplica | Retire |
Um detalhe que vale lembrar: a AWS, em seu guia de migrações em larga escala, não recomenda refactor nesse contexto, porque ele moderniza a aplicação durante a migração, o que soma risco e prazo. Em outras palavras, misturar mudança de lugar com mudança de código na mesma etapa costuma ser mais arriscado do que fazer uma coisa de cada vez.
Strangler fig: como modernizar sem parar a operação
O padrão strangler fig permite modernizar um sistema aos poucos, construindo o novo ao redor do antigo e migrando funcionalidades uma a uma, até o legado poder ser desligado. O nome foi dado por Martin Fowler em 2004, em referência à figueira-estranguladora, que cresce em torno da árvore hospedeira até substituí-la.
O Microsoft Learn descreve o padrão como uma abordagem faseada, que permite ao sistema atual continuar funcionando durante a modernização. A AWS o resume em três etapas: transformar, coexistir e eliminar. Na prática, uma camada de roteamento (uma fachada) decide, para cada requisição, se ela vai para o sistema antigo ou para o novo, e a proporção muda conforme as funcionalidades são migradas.
As vantagens são concretas. O artigo de microservices.io destaca que o padrão reconhece que a modernização é um processo de descoberta (nem sempre os requisitos reais são conhecidos no início) e que gera feedback contínuo. A mesma fonte aponta a limitação: ao contrário de uma reescrita em bloco, o padrão costuma exigir mudanças no próprio sistema legado.
Um cuidado de gestão: trate os últimos itens da migração como uma fase com orçamento e critério de conclusão próprios. Sem isso, o legado não é totalmente desligado e a empresa passa a manter dois sistemas.
Quatro cenários típicos
Os cenários abaixo são ilustrativos e não representam clientes específicos.
- Sistema estável em servidor antigo. A aplicação funciona bem, mas roda em infraestrutura sem suporte. Rota provável: rehost ou replatform, com revisão em 12 a 24 meses.
- Monolito crítico, difícil de evoluir. Cada mudança leva semanas, e poucas pessoas entendem o código. Rota provável: rearchitect incremental com strangler fig, começando pelos módulos que mais mudam.
- Código sem testes, com regras de negócio ocultas. O risco de reescrever é alto. Rota provável: descoberta e testes de caracterização primeiro, e depois refactor por partes.
- Funcionalidade padrão, com produto de mercado equivalente. Um módulo de uso geral (por exemplo, folha ou emissão de documentos) que não diferencia o negócio. Rota provável: replace, com integração ao restante do ambiente.
Depois da modernização: sustentação e governança
Modernizar não termina na entrega: sem sustentação e governança, o sistema novo volta a acumular dívida técnica e dependência de poucas pessoas. Um artigo do IT Forum resume o desafio: o problema das empresas não é só eliminar sistemas antigos, é evitar que a modernização produza um novo legado, mais fragmentado e difícil de governar.
Na prática, o pós-projeto precisa responder a quatro perguntas: quem corrige falhas e com que prazo; quem adapta o sistema às mudanças do ambiente; quem o evolui; e quem acompanha indicadores e riscos. É o que um modelo de sustentação contínua organiza. A Sustentação AMS da NextAge, por exemplo, se estrutura em quatro pilares (corretiva, adaptativa, evolutiva e governança), com foco na causa raiz das falhas, relatórios mensais e acesso a indicadores operacionais. A contratação é mensal, com pacote de horas, SLA definido e escopo claro desde o início, e a página do serviço indica que cerca de um terço do pacote é dedicado a monitoramento, governança técnica e indicadores.
A NextAge também atua na modernização de legados de forma incremental, validando cada etapa, sem reescrita total (quando a rota incremental faz sentido, como discutido acima). Para quem ainda não sabe por onde começar, a conversa inicial é um diagnóstico sem custo e sem compromisso, que resulta em um mapa de riscos e um plano de ação.
Roteiro em quatro fases
O caminho mais seguro é avançar em fases curtas, validando cada uma antes de ampliar o escopo.
- Descoberta. Faça o inventário dos sistemas, classifique cada um com as cinco perguntas e documente dependências e regras de negócio. Resultado: portfólio classificado e prioridades.
- Piloto. Escolha um sistema ou módulo de risco controlado e aplique a rota escolhida, com métricas de sucesso definidas antes de começar. Resultado: aprendizado real e uma estimativa mais confiável.
- Expansão. Replique o método nos demais sistemas, em ondas, mantendo o legado funcionando até cada etapa ser validada.
- Sustentação. Defina equipe, indicadores e governança para o sistema modernizado. Para sistemas novos ou reconstruídos, uma fábrica de software pode executar a construção, e a sustentação (AMS) assume depois da entrega.
Perguntas frequentes
O que é modernização de sistemas legados?
É o processo de atualizar ou substituir sistemas, arquiteturas e infraestrutura antigos para alinhá-los aos objetivos atuais do negócio, com mais agilidade, segurança e escalabilidade.
Quais são as estratégias de modernização de sistemas legados?
As principais são rehost, replatform, refactor, rearchitect e rewrite (também chamado de rebuild ou replace). Modelos mais amplos, como os 7 Rs da AWS, incluem ainda retire, retain e relocate.
Qual a diferença entre rehost e replatform?
O rehost move o sistema sem alterar código nem plataforma; o replatform troca partes da plataforma (como banco de dados ou runtime) para ganhar eficiência, sem reescrever a lógica.
Quando vale reescrever um sistema em vez de refatorar?
Quando a regra de negócio será repensada, quando o código é irrecuperável ou quando há um produto pronto que atende. A reescrita tem o maior risco de perder conhecimento de negócio.
O que é o padrão strangler fig?
É uma abordagem nomeada por Martin Fowler em 2004: o novo sistema é construído ao redor do antigo, e as funcionalidades são migradas aos poucos, até o legado poder ser desligado.
Quanto tempo e quanto custa modernizar um sistema legado?
Depende da rota e do estado do sistema. Um rehost tende a ser mais rápido, e um rearchitect de um sistema com anos de regras não documentadas tende a levar bem mais tempo. A estimativa confiável vem de uma etapa de descoberta, não de uma faixa genérica.
O que fazer depois de modernizar?
Definir sustentação, indicadores e governança, para que o sistema modernizado não vire um novo legado.
Próximo passo
Se a sua empresa precisa decidir o caminho para um sistema crítico, ou garantir que ele continue saudável depois da modernização, vale conversar com quem acompanha esse tipo de operação no dia a dia. Conheça a Sustentação AMS da NextAge ou fale com um especialista.
