Modernização de sistemas legados: o guia completo

O que é um sistema legado (e por que idade não é o critério)

Sistema legado é um sistema que o negócio ainda usa e do qual depende, mas que ficou difícil de mudar com segurança. A idade ajuda a explicar como ele chegou lá, mas não define nada: existem sistemas de dez anos em ótimo estado e sistemas de três anos que ninguém tem coragem de tocar.

O que caracteriza o legado é a combinação de três coisas: o conhecimento de como ele funciona está em poucas cabeças (ou em nenhuma), não há testes automáticos que digam se uma mudança quebrou algo, e a tecnologia por baixo perdeu suporte ou ficou difícil de contratar gente para mexer.

Por isso a pergunta útil não é “esse sistema é velho?”, e sim “eu consigo mudar este sistema com segurança, no ritmo que o negócio precisa?”. Se a resposta é não, você tem um legado, e a modernização passa a ser uma decisão de negócio, não só de TI.

Sinais de que a modernização de sistemas legados não pode mais esperar

Os sinais mais confiáveis não aparecem em ferramenta nenhuma. Aparecem no dia a dia da operação:

• Mudanças pequenas levam semanas, porque ninguém sabe o que mais vai quebrar.
• O sistema depende de uma ou duas pessoas. Quando uma delas sai ou tira férias, a empresa prende a respiração.
• O sistema cai, trava ou fica lento nos horários de pico, e a correção é sempre um remendo.
• Não dá para integrar com ferramentas novas (pagamentos, e-mail, mensageria, BI) sem gambiarra.
• O fornecedor da linguagem, do banco ou do servidor deixou de dar suporte, e as atualizações de segurança não chegam.
• Cada correção abre dois defeitos novos e ninguém consegue testar tudo antes de publicar.
• O custo de manutenção sobe todo ano e a lista de pedidos do negócio só cresce.

O custo de não fazer nada

Manter o legado como está parece a opção barata porque não tem proposta nem investimento visível. Só que o custo existe e aparece em outros lugares: no tempo do time gasto em remendo, em oportunidades que o sistema não deixa explorar, em risco de segurança e em dependência de pessoas-chave.

Um exercício simples: some as horas mensais gastas com correções e retrabalho, anote o que o negócio deixou de fazer porque o sistema não permite, e compare com o que um projeto incremental custaria. Não precisa ser exato, precisa ser honesto. Em muitos casos, o custo de esperar já é maior do que o de começar por uma parte.

Há ainda o risco de cauda: o dia em que o servidor, o banco ou a única pessoa que conhece o sistema falha. Esse custo não entra na planilha até acontecer, e aí costuma ser o mais caro.

Três ou mais itens da lista acima já justificam um diagnóstico. Um ou dois podem ser resolvidos com ajustes pontuais, e tudo bem: nem todo incômodo pede um projeto de modernização.

As cinco estratégias de modernização, da menos à mais invasiva

Modernizar não é sinônimo de reescrever. Existem cinco caminhos, e escolher o certo para cada parte do sistema é metade do trabalho:

• Manter e cercar de cuidado: não mexer no código, mas adicionar monitoramento, backup testado e documentação. Serve para sistemas estáveis e de baixo valor estratégico.
• Encapsular: colocar uma camada (uma API, por exemplo) na frente do legado para que sistemas novos conversem com ele sem depender do código interno.
• Refatorar: reorganizar o código por dentro, sem mudar o comportamento, para ele ficar legível, testável e atualizável.
• Migrar por etapas: construir a versão nova ao lado da antiga e passar uma funcionalidade de cada vez, até desligar o legado.
• Reescrever do zero: construir tudo de novo e trocar de uma vez. É a opção mais arriscada e a mais tentadora.

Refatorar ou reescrever: por que a gente prefere começar pela refatoração

A reescrita completa atrai porque promete um recomeço limpo. O problema é que o código antigo, por pior que pareça, carrega anos de regras de negócio e correções que ninguém documentou. Joel Spolsky descreveu isso em 2000, no texto que virou referência no assunto (“Things You Should Never Do”), ao argumentar que reescrever do zero costuma jogar fora conhecimento acumulado.

Isso não quer dizer que reescrever seja sempre errado. Faz sentido quando a tecnologia não tem mais saída, quando a arquitetura impede o negócio de crescer ou quando o sistema é pequeno o bastante para o risco ser baixo. O ponto é decidir com critério, e não por cansaço do código antigo. Detalhamos esses critérios em refatorar ou reescrever: como decidir sem se arrepender.

Se o que você precisa, na verdade, é um aplicativo novo (e não a modernização de algo que já existe), vale ver como funciona um protótipo navegável gratuito antes de decidir qualquer coisa.

Migração incremental: como modernizar sem parar a operação

A migração incremental é o jeito de modernizar sem parar o negócio. A ideia é simples: o sistema novo cresce ao lado do antigo, e o tráfego e as funcionalidades passam de um para o outro aos poucos. Esse padrão é conhecido como strangler fig (figueira-estranguladora), descrito por Martin Fowler: a aplicação nova “envolve” a antiga, parte por parte, até que o legado possa ser desligado.

O roteiro que a gente segue, em linhas gerais:

• Inventário: mapear módulos, banco de dados, integrações, rotinas agendadas e quem usa o quê.
• Testes de caracterização: antes de mudar qualquer coisa, registrar o comportamento atual (entradas e saídas), para saber depois se algo mudou sem querer.
• Camada de convivência: um ponto de entrada (proxy ou roteador) que decide, por rota ou funcionalidade, se a requisição vai para o sistema antigo ou para o novo.
• Dados: decidir se o banco é compartilhado durante a transição ou migrado antes das funções. Em geral, manter um único banco no começo evita ter duas fontes da verdade para sincronizar.
• Fatias pequenas: começar por um módulo de risco baixo e valor visível, publicar, medir e só então seguir para o próximo.
• Plano de volta: cada etapa precisa poder ser desfeita rapidamente (feature flag ou troca de rota).
• Desligar o antigo: só quando nada mais passa por ele, com backup e um período de observação.

O que a IA muda (e o que não muda) na modernização de código

A IA virou parte do nosso processo e acelera etapas específicas: ler e explicar código desconhecido, mapear dependências, gerar a primeira versão da documentação, sugerir testes de caracterização e traduzir trechos repetitivos de um framework para outro.

O que ela não faz: decidir arquitetura, descobrir regra de negócio que nunca foi escrita em lugar nenhum, garantir que o comportamento continua igual, nem assumir responsabilidade pelo resultado. Código gerado em lote, sem teste e sem revisão, só troca um legado por outro, mais novo e igualmente difícil de entender.

Por isso a regra que a gente usa é: passos pequenos, testes antes, revisão humana em cada entrega e comparação do comportamento antigo com o novo. A IA reduz o esforço; a responsabilidade continua com a engenharia. O que funciona e o que não funciona, na prática, está em IA na refatoração de código.

Quanto custa modernizar: o que pesa no orçamento

Não existe preço de prateleira, e vale desconfiar de quem dá um número sem olhar o sistema. O custo depende principalmente do tamanho e do estado do código, da existência de documentação e de testes, da quantidade de integrações, da complexidade do banco de dados, do número de perfis de usuário e de módulos, e do risco da operação (quanto custa para o negócio uma hora parado).

A abordagem incremental ajuda porque distribui o investimento: em vez de um projeto único e grande, são etapas com entrega e custo próprios, e dá para ajustar o rumo a cada uma. Antes de qualquer proposta, um diagnóstico do legado (código, banco, integrações e pontos críticos) transforma incerteza em um escopo que dá para orçar.

Os fatores em detalhe estão em quanto custa modernizar um sistema legado, e o raciocínio geral de orçamento em quanto custa um software sob medida.

Por onde começar: um critério simples

Se o sistema tem vinte módulos, não dá para atacar todos de uma vez. Priorize cruzando dois eixos: quanto dói (incidentes, lentidão, retrabalho) e quanto vale (receita, cliente, decisão que depende dele). O módulo que dói muito e vale muito é o primeiro. O que dói pouco e vale pouco pode esperar, ou nunca ser modernizado.

Funciona bem escolher uma fatia piloto: pequena o bastante para terminar rápido, importante o bastante para o resultado ser notado. Ela valida a abordagem, o time e a camada de convivência antes de investir no restante.

E defina de antemão como vai medir: tempo para publicar uma mudança, quantidade de incidentes, tempo de resposta, horas de manutenção. Sem métrica, ninguém sabe se a modernização funcionou.

Depois da migração: manutenção contínua

Modernizar sem manter só adia o problema. Um sistema novo envelhece igual: dependências desatualizadas, correções de segurança acumuladas, módulos que ninguém revisa. A manutenção contínua (atualizações, monitoramento, correções e evolução em pequenos passos) é o que impede que o sistema novo vire o legado de daqui a cinco anos.

Código organizado, com testes e um framework atual, também torna a manutenção mais leve e previsível. É um dos ganhos que mais aparecem depois da refatoração, e é o que um contrato de manutenção bem desenhado precisa refletir, como explicamos em manutenção de software: o que está incluso e como contratar.

Perguntas frequentes

Conclusão

Se você chegou até aqui com um sistema específico em mente, a recomendação é a mesma que daríamos numa primeira conversa: não comece pela tecnologia, comece pelo diagnóstico. Liste os módulos, marque onde dói e onde vale mais, escolha uma fatia pequena e planeje o caminho de volta. Modernizar é uma sequência de decisões pequenas e reversíveis, não um salto. Se quiser ajuda para fazer esse diagnóstico, a gente conversa sem compromisso sobre a modernização do seu sistema.

Fontes

• Martin Fowler: Strangler Fig
• Joel Spolsky: Things You Should Never Do, Part I