{"id":5774,"date":"2026-11-11T11:14:32","date_gmt":"2026-11-11T14:14:32","guid":{"rendered":"https:\/\/nextage.com.br\/blog\/?p=5774"},"modified":"2026-11-11T11:14:32","modified_gmt":"2026-11-11T14:14:32","slug":"modernizacao-de-sistemas-legados-como-escolher-entre-rehost-refactor-rearchitect-e-rewrite","status":"publish","type":"post","link":"https:\/\/nextage.com.br\/blog\/modernizacao-de-sistemas-legados-como-escolher-entre-rehost-refactor-rearchitect-e-rewrite\/","title":{"rendered":"Moderniza\u00e7\u00e3o de sistemas legados: como escolher entre rehost, refactor, rearchitect e rewrite"},"content":{"rendered":"

Modernizar um sistema legado n\u00e3o \u00e9 uma decis\u00e3o \u00fanica: \u00e9 uma decis\u00e3o por sistema. Cada aplica\u00e7\u00e3o tem valor, estado t\u00e9cnico, risco e urg\u00eancia diferentes, e por isso pode pedir um caminho diferente: mover para outra infraestrutura (rehost), trocar parte da plataforma (replatform), reorganizar o c\u00f3digo (refactor), mudar a arquitetura (rearchitect) ou reconstruir do zero (rewrite).<\/p>\n

Este guia \u00e9 para CTOs, gerentes de TI e arquitetos de empresas m\u00e9dias e grandes que dependem de sistemas pr\u00f3prios ou customizados. Voc\u00ea vai encontrar uma tabela comparando as cinco rotas, um framework de cinco perguntas para decidir, o padr\u00e3o strangler fig para modernizar sem parar a opera\u00e7\u00e3o e um roteiro em quatro fases.<\/p>\n

\"M\u00e3os<\/p>\n

Quando modernizar e quando n\u00e3o modernizar<\/h2>\n

Modernizar vale quando o sistema ainda sustenta uma opera\u00e7\u00e3o importante e o custo de mant\u00ea-lo como est\u00e1 (em risco, em depend\u00eancia de poucas pessoas, em dificuldade de integra\u00e7\u00e3o) supera o custo de mud\u00e1-lo. Quando o sistema perdeu relev\u00e2ncia, a melhor decis\u00e3o pode ser desativ\u00e1-lo ou deix\u00e1-lo como est\u00e1.<\/p>\n

O Google Cloud<\/a> define a moderniza\u00e7\u00e3o de sistemas legados como o processo de atualizar ou substituir sistemas, arquiteturas e infraestruturas desatualizados para alinh\u00e1-los melhor aos objetivos atuais e futuros do neg\u00f3cio. A mesma p\u00e1gina destaca um ponto que orienta este guia: n\u00e3o existe abordagem \u00fanica; a estrat\u00e9gia certa depende da aplica\u00e7\u00e3o, das metas, do or\u00e7amento e da toler\u00e2ncia a riscos.<\/p>\n

Por isso, o ponto de partida n\u00e3o \u00e9 escolher uma tecnologia, e sim classificar o portf\u00f3lio. Os modelos mais completos, como os 7 Rs da AWS<\/a>, incluem duas op\u00e7\u00f5es que muitas listas esquecem: retire<\/strong> (desativar o sistema) e retain<\/strong> (mant\u00ea-lo como est\u00e1 por enquanto, com data para revisar). Elas liberam or\u00e7amento e aten\u00e7\u00e3o para os sistemas que realmente precisam de investimento.<\/p>\n

Se voc\u00ea ainda est\u00e1 avaliando se o seu sistema chegou a esse ponto, vale come\u00e7ar pelo conceito de d\u00edvida t\u00e9cnica e pelos sinais de que manter j\u00e1 custa mais do que modernizar. Aqui, partimos do princ\u00edpio de que a decis\u00e3o de modernizar j\u00e1 foi tomada e falta escolher o caminho.<\/p>\n

As cinco rotas: rehost, replatform, refactor, rearchitect e rewrite<\/h2>\n

As cinco rotas diferem no que muda e no quanto custa errar: do rehost (s\u00f3 a infraestrutura) ao rewrite (tudo), crescem o esfor\u00e7o, o benef\u00edcio potencial e o risco de perder conhecimento de neg\u00f3cio. O gloss\u00e1rio da itemis<\/a> descreve essa mesma progress\u00e3o: o rehost move o sistema sem alter\u00e1-lo, refactor e rearchitect o transformam gradualmente, e o rewrite o desenvolve do zero, com o maior risco de perder conhecimento de neg\u00f3cio.<\/p>\n

\n\n\n\n\n\n\n\n\n\n
Rota<\/th>\nO que muda<\/th>\nRisco<\/th>\nEsfor\u00e7o<\/th>\nServe quando<\/th>\n<\/tr>\n<\/thead>\n
Rehost<\/td>\nS\u00f3 a infraestrutura<\/td>\nBaixo<\/td>\nBaixo<\/td>\nO sistema funciona, mas a infraestrutura \u00e9 o problema<\/td>\n<\/tr>\n
Replatform<\/td>\nA plataforma (banco, runtime, servidor de aplica\u00e7\u00e3o)<\/td>\nBaixo a m\u00e9dio<\/td>\nM\u00e9dio<\/td>\nH\u00e1 ganho em trocar a plataforma sem mexer na l\u00f3gica<\/td>\n<\/tr>\n
Refactor<\/td>\nO c\u00f3digo, sem mudar o comportamento<\/td>\nM\u00e9dio<\/td>\nM\u00e9dio a alto<\/td>\nO problema est\u00e1 na qualidade interna do c\u00f3digo<\/td>\n<\/tr>\n
Rearchitect<\/td>\nA estrutura (monolito para m\u00f3dulos ou servi\u00e7os)<\/td>\nM\u00e9dio a alto<\/td>\nAlto<\/td>\nEscala e acoplamento exigem outra arquitetura<\/td>\n<\/tr>\n
Rewrite<\/td>\nTudo, do zero (ou troca por produto pronto)<\/td>\nAlto<\/td>\nMuito alto<\/td>\nA regra de neg\u00f3cio ser\u00e1 repensada ou o c\u00f3digo \u00e9 irrecuper\u00e1vel<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Os n\u00edveis de risco e esfor\u00e7o s\u00e3o uma leitura editorial, consistente com as fontes citadas; n\u00e3o s\u00e3o dados medidos e variam por projeto.<\/p>\n

Uma nota sobre terminologia: as fontes divergem. O modelo original da Gartner, de 2010 (segundo a IBM<\/a>), tinha cinco Rs: rehost, refactor, revise, rebuild e replace; a AWS depois ampliou a lista para sete. Nesse modelo original, \u201crefactor\u201d significava rodar a aplica\u00e7\u00e3o em uma plataforma como servi\u00e7o, sentido diferente do uso atual, que \u00e9 reorganizar o c\u00f3digo. Neste guia, usamos o sentido atual.<\/p>\n

Rehost (lift and shift)<\/h3>\n

Rehost \u00e9 mover o sistema para uma nova infraestrutura (em geral a nuvem) sem alterar c\u00f3digo nem arquitetura. A IBM<\/a> indica que funciona melhor quando a organiza\u00e7\u00e3o precisa migrar r\u00e1pido, tem poucos recursos para rearquitetar ou quer benef\u00edcios imediatos, como reduzir custos de data center. O limite \u00e9 claro: o sistema continua com os mesmos problemas, s\u00f3 em outro lugar. Para custos e riscos espec\u00edficos de nuvem, veja o guia de migra\u00e7\u00e3o de sistemas<\/a>.<\/p>\n

Replatform<\/h3>\n

Replatform troca parte da plataforma (um banco de dados, um servidor de aplica\u00e7\u00e3o, uma vers\u00e3o de runtime) para ganhar efici\u00eancia, sem reescrever a l\u00f3gica. \u00c9 um meio-termo entre o rehost e a reorganiza\u00e7\u00e3o do c\u00f3digo: custa mais que mover o sistema como est\u00e1, mas costuma evitar o risco de mexer em regras de neg\u00f3cio.<\/p>\n

Refactor<\/h3>\n

Refactor reorganiza o c\u00f3digo por dentro, sem mudar o que o sistema faz para o usu\u00e1rio. Resolve problemas como regras de neg\u00f3cio emaranhadas e depend\u00eancia de poucas pessoas que entendem o c\u00f3digo. Se voc\u00ea quer a defini\u00e7\u00e3o completa e a diferen\u00e7a em rela\u00e7\u00e3o \u00e0 migra\u00e7\u00e3o e \u00e0 reescrita, veja o que \u00e9 refatora\u00e7\u00e3o<\/a>. Aqui, o que importa \u00e9 quando escolher essa rota: quando o comportamento atual est\u00e1 bom e a estrutura interna \u00e9 que atrapalha.<\/p>\n

Rearchitect<\/h3>\n

Rearchitect muda a estrutura do sistema, por exemplo separando um monolito em m\u00f3dulos ou servi\u00e7os. 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\u00e7\u00e3o exigem outra arquitetura, e quando o sistema \u00e9 estrat\u00e9gico para os pr\u00f3ximos anos.<\/p>\n

Rewrite (rebuild ou replace)<\/h3>\n

Rewrite \u00e9 reconstruir o sistema do zero ou substitu\u00ed-lo por um produto pronto. \u00c9 a rota de maior risco, sobretudo pela perda de conhecimento de neg\u00f3cio embutido no sistema antigo. Costuma ser a escolha certa quando a regra de neg\u00f3cio ser\u00e1 repensada, quando o c\u00f3digo \u00e9 irrecuper\u00e1vel ou quando existe um produto de mercado que atende. Rewrite n\u00e3o \u00e9 um erro; \u00e9 uma op\u00e7\u00e3o cara que precisa de justificativa.<\/p>\n

Framework de decis\u00e3o em cinco perguntas<\/h2>\n

Este framework \u00e9 uma proposta da NextAge, constru\u00edda sobre os modelos de 5 e 7 Rs. A ideia \u00e9 responder cinco perguntas por sistema e deixar a rota emergir da combina\u00e7\u00e3o das respostas.<\/p>\n

    \n
  1. O sistema ainda gera valor estrat\u00e9gico?<\/strong> Se n\u00e3o, retire ou retenha, e invista em outro lugar. Se sim, siga para a pr\u00f3xima pergunta.<\/li>\n
  2. O problema est\u00e1 na infraestrutura, na plataforma ou no c\u00f3digo?<\/strong> Se for a infraestrutura, a rota \u00e9 rehost. Se for a plataforma, replatform. Se for o c\u00f3digo ou a estrutura, siga para a terceira pergunta.<\/li>\n
  3. Existem documenta\u00e7\u00e3o, testes e conhecimento das regras de neg\u00f3cio?<\/strong> Se n\u00e3o, o rewrite corre o risco de perder regras que ningu\u00e9m sabe que existem. Comece por uma etapa de descoberta e por testes que registrem o comportamento atual.<\/li>\n
  4. Quanto a opera\u00e7\u00e3o tolera de parada?<\/strong> Se a toler\u00e2ncia \u00e9 baixa, prefira uma rota incremental (strangler fig, tratada a seguir). Se h\u00e1 janelas de parada aceit\u00e1veis, um corte em bloco pode ser vi\u00e1vel.<\/li>\n
  5. Qual \u00e9 o horizonte e o or\u00e7amento?<\/strong> Com horizonte curto, rehost ou replatform resolvem o urgente, e refactor ou rearchitect ficam para uma segunda fase. Com horizonte longo e sistema estrat\u00e9gico, um rearchitect incremental costuma compensar.<\/li>\n<\/ol>\n

    O resultado pode ser registrado em uma tabela simples, com uma linha por sistema:<\/p>\n

    \n\n\n\n\n\n\n\n
    Sistema<\/th>\nValor estrat\u00e9gico<\/th>\nProblema principal<\/th>\nConhecimento documentado<\/th>\nToler\u00e2ncia a parada<\/th>\nRota recomendada<\/th>\n<\/tr>\n<\/thead>\n
    Exemplo A<\/td>\nAlto<\/td>\nEstrutura (acoplamento)<\/td>\nParcial<\/td>\nBaixa<\/td>\nRearchitect incremental<\/td>\n<\/tr>\n
    Exemplo B<\/td>\nM\u00e9dio<\/td>\nInfraestrutura<\/td>\nSim<\/td>\nM\u00e9dia<\/td>\nRehost<\/td>\n<\/tr>\n
    Exemplo C<\/td>\nBaixo<\/td>\nN\u00e3o se aplica<\/td>\nN\u00e3o se aplica<\/td>\nN\u00e3o se aplica<\/td>\nRetire<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

    Um detalhe que vale lembrar: a AWS, em seu guia de migra\u00e7\u00f5es em larga escala, n\u00e3o recomenda refactor nesse contexto<\/a>, porque ele moderniza a aplica\u00e7\u00e3o durante a migra\u00e7\u00e3o, o que soma risco e prazo. Em outras palavras, misturar mudan\u00e7a de lugar com mudan\u00e7a de c\u00f3digo na mesma etapa costuma ser mais arriscado do que fazer uma coisa de cada vez.<\/p>\n

    Strangler fig: como modernizar sem parar a opera\u00e7\u00e3o<\/h2>\n

    O padr\u00e3o strangler fig permite modernizar um sistema aos poucos, construindo o novo ao redor do antigo e migrando funcionalidades uma a uma, at\u00e9 o legado poder ser desligado. O nome foi dado por Martin Fowler em 2004, em refer\u00eancia \u00e0 figueira-estranguladora<\/a>, que cresce em torno da \u00e1rvore hospedeira at\u00e9 substitu\u00ed-la.<\/p>\n

    O Microsoft Learn<\/a> descreve o padr\u00e3o como uma abordagem faseada, que permite ao sistema atual continuar funcionando durante a moderniza\u00e7\u00e3o. A AWS<\/a> o resume em tr\u00eas etapas: transformar, coexistir e eliminar. Na pr\u00e1tica, uma camada de roteamento (uma fachada) decide, para cada requisi\u00e7\u00e3o, se ela vai para o sistema antigo ou para o novo, e a propor\u00e7\u00e3o muda conforme as funcionalidades s\u00e3o migradas.<\/p>\n

    As vantagens s\u00e3o concretas. O artigo de microservices.io<\/a> destaca que o padr\u00e3o reconhece que a moderniza\u00e7\u00e3o \u00e9 um processo de descoberta (nem sempre os requisitos reais s\u00e3o conhecidos no in\u00edcio) e que gera feedback cont\u00ednuo. A mesma fonte aponta a limita\u00e7\u00e3o: ao contr\u00e1rio de uma reescrita em bloco, o padr\u00e3o costuma exigir mudan\u00e7as no pr\u00f3prio sistema legado.<\/p>\n

    Um cuidado de gest\u00e3o: trate os \u00faltimos itens da migra\u00e7\u00e3o como uma fase com or\u00e7amento e crit\u00e9rio de conclus\u00e3o pr\u00f3prios. Sem isso, o legado n\u00e3o \u00e9 totalmente desligado e a empresa passa a manter dois sistemas.<\/p>\n

    Quatro cen\u00e1rios t\u00edpicos<\/h2>\n

    Os cen\u00e1rios abaixo s\u00e3o ilustrativos e n\u00e3o representam clientes espec\u00edficos.<\/p>\n