# Modernização de sistema legado: por partes ou reescrever?

> Como decidir entre modernizar por partes ou reescrever um sistema legado sem parar a operação, com matriz de decisão e roteiro de migração por módulos.

Autor: José Carlos Maciel, Fundador e desenvolvedor. Publicado em 2026-10-28, atualizado em 2026-10-28.
Fonte: https://boosting.tech/blog/modernizacao-de-sistema-legado/

**Resposta rápida:** Na maioria dos casos, modernizar um sistema legado por partes é mais seguro do que reescrever do zero. A operação segue no sistema atual enquanto cada módulo é reconstruído e migrado com caminho de volta. Reescrever compensa quando o sistema é pequeno, quando não há código aproveitável ou quando o processo mudou demais.

Segunda-feira, sete da manhã. O sistema da base demora para abrir, o relatório de embarques do fim de semana saiu com a coluna de horários vazia e a única pessoa que entende aquela parte do código saiu da empresa no ano passado. A operação já abriu duas planilhas paralelas para não parar. Na reunião, alguém diz que o certo é jogar tudo fora e fazer um sistema novo. Outra pessoa lembra que da última vez o projeto novo levou um ano e nunca entrou em produção.

Este artigo ajuda a tomar essa decisão com critério. Você vai encontrar o que caracteriza um sistema legado, por que a reescrita completa costuma dar errado, uma comparação entre os dois caminhos, uma matriz de decisão para usar na reunião e um roteiro para modernizar por partes sem parar o trabalho. Se a dúvida ainda é anterior, entre ter um sistema próprio e comprar um pronto, comece pelo artigo [sistema sob medida ou software pronto](/blog/sistema-sob-medida-ou-software-pronto/).

## O que é um sistema legado?

Um sistema legado é um sistema que ainda sustenta a operação, mas ficou difícil de mudar: cada ajuste demora, quebra outra coisa ou depende de uma pessoa específica. A idade conta menos do que isso. Um sistema de cinco anos sem testes, sem documentação e com versões fora de suporte já se comporta como legado.

O [Microsoft Azure Architecture Center](https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig) descreve o quadro assim: com o tempo, as ferramentas, a hospedagem e a arquitetura em que o sistema foi construído ficam obsoletas, e cada função nova o deixa mais complexo e mais difícil de manter. Nas empresas de operação que atendemos, o legado costuma aparecer em três formatos: um sistema web feito por um fornecedor que não existe mais, um programa instalado nas máquinas do escritório e uma planilha com macros que virou sistema sem ninguém decidir.

O sinal mais claro de legado é o comportamento da equipe. Quando a operação passa a criar controles paralelos em planilha porque o sistema não acompanha, o problema já saiu da TI e chegou ao campo.

## Por que reescrever do zero costuma dar errado?

Reescrever do zero costuma dar errado porque o sistema antigo guarda anos de regras e correções que ninguém documentou, e o projeto novo leva muito mais tempo do que o previsto para alcançar o que o antigo já faz. Enquanto isso, a operação continua presa ao sistema velho, sem melhorias.

Martin Fowler, autor de referência em arquitetura de software, escreveu no texto sobre o padrão [Strangler Fig](https://martinfowler.com/bliki/StranglerFigApplication.html) que o plano de construir um sistema novo que faça exatamente o mesmo, só que em tecnologia melhor, deu errado na maior parte das vezes que ele acompanhou. Os motivos que ele aponta são três: a troca leva muito tempo, os usuários não podem esperar por funções novas e é difícil descobrir os detalhes do comportamento atual. Boa parte desse comportamento, acrescenta, nem é mais desejada, e reconstruí-la é desperdício.

Joel Spolsky, cofundador do Stack Overflow, chamou a reescrita completa de [o pior erro estratégico](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/) que uma empresa de software pode cometer. O argumento dele vale para sistemas internos: aquela função feia de duas páginas carrega correções de problemas que só apareceram depois de semanas de uso real. Jogar o código fora joga junto esse conhecimento.

Nos sistemas que mantemos, vemos o mesmo padrão em escala menor. A regra de quem pode aprovar uma hora extra, o arredondamento de um cálculo de faturamento, o motivo de um campo obrigatório na portaria: nada disso está num documento. Está no código, e só aparece quando alguém tenta reconstruir a tela e o usuário reclama que "antes funcionava".

## O que muda entre modernizar por partes e reescrever?

Modernizar por partes troca o sistema módulo a módulo, com a operação usando o sistema o tempo todo. Reescrever constrói um sistema inteiro em paralelo e faz a troca de uma vez. A tabela compara os dois caminhos nos pontos que mais pesam para quem opera.

| Aspecto | Modernizar por partes | Reescrever do zero |
| --- | --- | --- |
| Quando a operação vê resultado | No primeiro módulo trocado | Quando o sistema novo fica completo |
| Risco na virada | Pequeno, um módulo por vez, com caminho de volta | Concentrado num único dia de troca |
| Regras de negócio escondidas | Aparecem aos poucos, módulo a módulo | Aparecem depois da virada, em produção |
| Melhorias durante o projeto | Continuam no sistema em uso | Ficam congeladas ou são feitas duas vezes |
| Custo de transição | Código provisório para os dois conviverem | Dois sistemas mantidos até a virada |
| Dados | Migrados por domínio, com conferência | Migrados todos de uma vez |
| Quando faz mais sentido | Sistema grande, crítico e ainda útil | Sistema pequeno, sem código ou sem conserto |

A linha do custo de transição merece atenção. Fowler reconhece que a abordagem gradual exige uma arquitetura provisória, que existe só para os dois sistemas conviverem e some no fim. Parece desperdício, mas, para ele, o risco menor e o valor entregue mais cedo compensam esse custo.

## Como decidir entre modernizar e reescrever?

A decisão sai de um levantamento do que existe hoje e de uma conversa honesta sobre quais sinais pesam mais na sua operação. A matriz abaixo reúne as perguntas que fazemos quando assumimos um sistema que outra empresa construiu.

### Matriz de decisão: modernizar por partes ou reescrever

Responda com quem usa o sistema todo dia e com quem mantém o código. Cada item marcado em um grupo pesa para aquele caminho. A matriz organiza a conversa e não substitui a avaliação técnica do código, da infraestrutura e dos dados, que é o que confirma a decisão.


**Levantamento antes de decidir**

- [ ] Existe acesso ao código-fonte atual e ao banco de dados, com as credenciais em nome da empresa
- [ ] Os processos que o sistema atende estão listados, com quem usa cada tela e com que frequência
- [ ] As integrações estão mapeadas (ERP, WMS, planilhas importadas, relatórios enviados por e-mail)
- [ ] Há backup recente do banco testado com uma restauração de verdade
- [ ] As versões da linguagem, do framework, do banco e do servidor estão anotadas, com a data de fim de suporte de cada uma

**Sinais a favor de modernizar por partes**

- [ ] O sistema atende a maior parte da operação, e as queixas se concentram em alguns módulos
- [ ] As regras de negócio estão no código e ninguém tem tudo documentado em outro lugar
- [ ] A operação não pode ficar meses sem novidades enquanto um sistema novo é construído
- [ ] Dá para separar um módulo (portaria, agendamento, relatórios) e trocá-lo sem mexer nos outros
- [ ] O banco de dados é aproveitável, mesmo que precise de ajustes de estrutura

**Sinais a favor de reescrever**

- [ ] O sistema é pequeno e reconstruí-lo inteiro cabe em poucas semanas
- [ ] Não há código-fonte acessível nem banco que possa ser lido por outro sistema
- [ ] O processo mudou tanto que a maior parte das telas e regras deixou de fazer sentido
- [ ] A tecnologia não recebe mais correções de segurança e não existe caminho de atualização
- [ ] O modelo de dados não suporta o que a operação precisa agora (vários clientes, várias unidades, vários idiomas)

Use a matriz em uma reunião curta, com alguém da operação, alguém de TI e quem aprova o investimento. O primeiro grupo vem antes de tudo: sem acesso ao código e ao banco, nenhuma das duas opções pode ser avaliada a sério, e conseguir esse acesso costuma ser a primeira tarefa.

Se a maior parte das marcas cair no segundo grupo, o caminho é modernizar por partes. Se cair no terceiro, vale estimar a reescrita, de preferência ainda em etapas. Quando as marcas se dividem, o mais comum é modernizar a base e reconstruir só o módulo que não tem conserto.

A matriz organiza a conversa, e a avaliação técnica confirma a escolha. Na nossa [sustentação e modernização](/servicos/sustentacao-e-modernizacao/), essa avaliação lê o código, confere a infraestrutura e lista os riscos por prioridade. Com a lista em mãos, a empresa decide o que corrigir primeiro.

## Como modernizar por partes sem parar a operação?

Modernizar por partes significa colocar um ponto de corte entre os usuários e o sistema antigo e, a partir dele, passar um módulo de cada vez para o código novo, até que o antigo possa ser desligado. A Microsoft descreve esse caminho no [padrão Strangler Fig](https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig): uma fachada recebe as requisições e decide se cada uma vai para o sistema antigo ou para o novo, e o novo assume mais funções a cada etapa.

Na prática, o roteiro que seguimos tem sete passos:

1. Garanta acesso e backup. Código, banco, servidor e domínio ficam em nome da empresa, e um backup é restaurado num ambiente de teste para provar que funciona.
2. Coloque o sistema em observação. Monitoramento de erros e de disponibilidade mostra o que quebra de verdade, antes de qualquer mudança.
3. Atualize a base. Versões da linguagem, do framework e do banco que estão fora de suporte sobem primeiro, em passos pequenos e testados.
4. Escolha o primeiro módulo. Prefira um que dói na operação e que tenha fronteira clara, como agendamento, portaria ou relatórios.
5. Reconstrua o módulo ao lado do antigo. O módulo novo lê e grava nos mesmos dados, ou numa base própria sincronizada, enquanto a equipe confere os resultados.
6. Vire o módulo com caminho de volta. Os usuários passam para o módulo novo, e o antigo fica disponível por um período combinado.
7. Desligue o antigo e siga para o próximo. Só remova tabelas e telas antigas depois que o módulo novo foi validado em uso real.

Quando o sistema novo precisa conversar com partes do antigo que ainda não foram trocadas, entra uma camada de tradução. A Microsoft chama isso de [camada anticorrupção](https://learn.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer): um adaptador que traduz os dados e as chamadas entre os dois sistemas, para que o código novo não herde os vícios do modelo antigo.

O caso de [transporte marítimo de passageiros](/casos/transporte-maritimo-de-passageiros/) mostra um exemplo desse tipo de evolução. O sistema de agendamento de embarques começou atendendo um único operador de lanchas. Com a operação consolidada, começamos a redesenhá-lo como plataforma para vários operadores, com dados isolados por operador, bilhete com QR code e trilha de auditoria. O conceito central do sistema mudou: deixou de ser o usuário que cadastrou e passou a ser o operador, o fornecedor e a viagem.

## E se ninguém tem o código, a documentação ou quem fez o sistema?

Sem código nem documentação, a modernização começa pelos dados e pelo uso real: o que está no banco, quais telas a equipe usa e quais relatórios saem do sistema. É mais lento, mas é o caso mais comum quando o fornecedor original saiu de cena.

Algumas situações mudam o roteiro:

1. O código existe, mas ninguém sabe onde está. Procure no servidor de hospedagem, nos contratos antigos e com o antigo fornecedor. Muitas vezes o código está no próprio servidor em produção.
2. Só existe o banco de dados. O banco revela as entidades e boa parte das regras. Com ele lido e documentado, o sistema novo pode ser construído por módulos, consumindo os mesmos dados.
3. O sistema é um programa fechado de terceiros. A Microsoft aponta que o padrão de fachada não serve quando não há acesso ao código nem outro ponto de integração. Nesse caso, a saída costuma ser construir em volta, lendo os dados que o programa exporta, e trocar por etapas de processo.
4. O sistema é uma planilha com macros. Trate cada aba como um módulo. As fórmulas são as regras de negócio e precisam ser escritas em linguagem comum antes de qualquer código.
5. A equipe resiste à troca. Comece pelo módulo de que ela mais reclama. Quando a primeira troca resolve um incômodo real, a resistência às próximas cai.

Uma revisão de segurança ajuda nessas situações, porque obriga a ler o sistema rota por rota. Na [plataforma de operação portuária](/casos/operacao-portuaria/) que mantemos, montamos uma matriz de rota, ação e perfil e corrigimos ações que a tela escondia mas o servidor aceitava. Esse tipo de leitura também mostra onde estão as regras que ninguém documentou.

## Quando reescrever é a melhor saída?

Reescrever é a melhor saída quando o sistema é pequeno, quando não há código nem dados aproveitáveis ou quando a operação mudou tanto que o sistema atual responde a perguntas que ninguém faz mais. Nesses casos, modernizar por partes gasta esforço preservando o que vai ser descartado.

Mesmo assim, a reescrita pode ser feita em etapas. Em vez de construir tudo e virar num dia, o sistema novo entra em produção com um processo completo, e os outros processos migram depois. A [plataforma de operação portuária](/casos/operacao-portuaria/) cresceu assim: começou pelos processos de segurança e foi ganhando módulos conforme a operação pedia, todos usando o mesmo cadastro de pessoas, empresas e locais. Hoje o banco tem mais de 160 tabelas, e o sistema segue em evolução contínua desde 2019.

Há também o que nenhuma das duas opções resolve sozinha. Se o processo é confuso no papel, ele vai continuar confuso no sistema novo. Fowler lembra que, sem mudança na forma de trabalhar, o sistema novo tende a acabar na mesma bagunça do antigo. Por isso, antes de discutir tecnologia, vale escrever o processo como ele deveria funcionar.

Se você quer entender como é um projeto desse tipo do começo ao fim, o artigo sobre [projeto de software sob medida](/blog/projeto-de-software-sob-medida/) descreve cada etapa e o que o cliente decide em cada uma.

## Quando isso não basta?

Este artigo ajuda a escolher o caminho, mas não substitui a leitura do código, dos dados e da infraestrutura. Duas empresas com o mesmo sintoma podem precisar de respostas opostas. Envolva alguém de fora quando a equipe interna não tem tempo para a avaliação, quando ninguém na empresa conhece a tecnologia do sistema ou quando o sistema guarda dados pessoais e a troca precisa respeitar a LGPD.

A boosting.tech é uma empresa de software customizado que assume sistemas existentes, inclusive os feitos por outras empresas, e moderniza por etapas sem parar a operação. Podemos olhar o seu sistema numa conversa de diagnóstico, sem custo, pela página de [contato](/contato/) ou pelo e-mail jcm@boosting.tech. Os detalhes estão em [sustentação e modernização](/servicos/sustentacao-e-modernizacao/), e, quando a saída é reconstruir, o trabalho segue como um projeto de [sistema web sob medida](/servicos/sistemas-web-sob-medida/).

## Perguntas frequentes sobre modernização de sistema legado

### Quanto tempo leva para modernizar um sistema legado?

Depende do tamanho do sistema, da qualidade do código e de quantos módulos precisam ser trocados. A vantagem de modernizar por partes é que a pergunta muda: em vez de esperar o fim do projeto, a operação recebe o primeiro módulo trocado cedo, e o prazo de cada etapa pode ser estimado separadamente depois da avaliação técnica.

### Dá para modernizar sem parar a operação?

Dá, e esse é o principal motivo para escolher o caminho por partes. As mudanças entram em etapas pequenas, testadas antes e com caminho de volta. Quando uma migração de dados exige uma janela com o sistema fora do ar, ela é combinada com antecedência e feita no horário de menor uso.

### Vale a pena trocar a tecnologia do sistema?

Só quando a tecnologia atual impede a operação de evoluir, por exemplo quando não recebe mais correções de segurança ou não há mais quem a mantenha. Trocar a linguagem por preferência da equipe raramente compensa. O ganho para a operação vem de módulos que funcionam melhor, e a tecnologia nova é um meio para isso.

### O que acontece com os dados antigos?

Os dados são migrados por domínio, junto com o módulo que os usa, e conferidos antes da virada. Durante a transição, o sistema novo pode ler a base antiga ou uma cópia sincronizada. As tabelas antigas só são removidas depois que o módulo novo foi validado em uso real, para que a volta continue possível.

### Vocês assumem um sistema feito por outra empresa?

Assumimos, depois de uma avaliação. Lemos o código, conferimos a infraestrutura e listamos os riscos por prioridade. A avaliação diz se faz sentido assumir a sustentação, modernizar por partes, integrar com um sistema novo ou reconstruir. A sustentação começa pelo que ameaça a operação.

## Referências

- [Martin Fowler: Strangler Fig (2024)](https://martinfowler.com/bliki/StranglerFigApplication.html)
- [Microsoft Azure Architecture Center: Strangler Fig pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig)
- [Microsoft Azure Architecture Center: Anti-corruption Layer pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer)
- [Joel Spolsky: Things You Should Never Do, Part I (2000)](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/)