Sistemas legados: quando modernizar e quando substituir — um guia para decisores

Toda organização que chegou a um certo nível de maturidade carrega, em alguma camada do seu stack, um sistema que ninguém mais quer tocar. Ele pode ter 10, 20 ou até 30 anos. Roda em infraestrutura obsoleta, foi escrito em uma linguagem que a maioria dos desenvolvedores jovens nunca aprendeu, e sua documentação — quando existe — está desatualizada há anos. Mas ele funciona. E é exatamente isso que torna a decisão tão difícil.

A pergunta que CEOs, CTOs e fundadores me fazem com frequência é: modernizamos ou substituímos? Parece uma questão técnica. Não é. É uma decisão estratégica com implicações financeiras, operacionais e competitivas que podem definir os próximos cinco a dez anos de uma empresa. Neste artigo, vou compartilhar o framework que uso com meus clientes para tomar essa decisão com clareza — sem romantismo tecnológico e sem o alarmismo que costuma vir de quem tem interesse em vender um projeto grande.

O problema real com sistemas legados

Antes de falar sobre modernização ou substituição, é preciso entender o que torna um sistema verdadeiramente legado. Não é a idade. Não é a linguagem de programação. Um sistema legado é aquele que acumula dívida técnica a uma taxa maior do que a capacidade da organização de pagá-la. Ele começa a custar mais para manter do que entregaria se fosse reescrito. E, mais importante: ele começa a limitar o negócio.

Em mais de 20 anos atuando em projetos de arquitetura e modernização — passando pela IBM e pela AWS, e atendendo clientes como B3, BTG Pactual, Safra e XP —, identifiquei um padrão consistente: o problema raramente é o código. O problema é a inércia organizacional em torno desse código. Processos de negócio inteiros foram modelados para trabalhar com as limitações do sistema. Equipes inteiras foram formadas para compensar o que ele não faz automaticamente. E ninguém mais sabe exatamente o que acontece se ele parar.

Isso cria um paradoxo: o sistema mais crítico da empresa frequentemente é o menos compreendido. E é justamente esse o ponto de partida para qualquer decisão de modernização.

Os quatro sinais de que a decisão não pode mais esperar

Existe uma tendência natural de adiar essa conversa. Os argumentos são sempre razoáveis: o sistema funciona, a equipe conhece, o risco de mudança é alto, o momento não é propício. Mas há quatro sinais que, quando aparecem juntos, indicam que postergar tem um custo maior do que agir.

• Custo de manutenção acima de 60% do orçamento de TI: Quando a maior parte do orçamento vai para manter o que existe, sobra pouco para inovar. Empresas que chegam a esse patamar perdem competitividade de forma silenciosa e progressiva.
• Time-to-market acima de 3 meses para mudanças simples: Se uma alteração de regra de negócio leva trimestres para ir ao ar, o sistema está bloqueando o crescimento. Concorrentes mais ágeis ocupam esse espaço sem fazer barulho.
• Dependência de pessoas específicas: Quando duas ou três pessoas detêm o conhecimento crítico sobre como o sistema funciona, a empresa está refém. Aposentadoria, demissão ou doença de um desses profissionais pode ser catastrófico.
• Incapacidade de atender exigências regulatórias: No setor financeiro brasileiro, por exemplo, as exigências do Banco Central evoluem em uma velocidade que sistemas com arquitetura monolítica e rígida simplesmente não conseguem acompanhar.

Se dois ou mais desses sinais estão presentes, a decisão é urgente. A questão passa a ser: qual caminho seguir?

O framework de decisão: seis perguntas que definem o caminho

Não existe resposta universal para modernizar ou substituir. O que existe é um conjunto de perguntas que, respondidas com honestidade, apontam a direção correta. Uso esse framework com clientes de diferentes setores e tamanhos, e ele consistentemente entrega clareza onde havia paralisia.

1. O sistema ainda reflete a lógica de negócio atual? Se as regras de negócio embutidas no código ainda são válidas, modernizar a infraestrutura e a arquitetura pode ser suficiente. Se o modelo de negócio mudou e o sistema carrega lógicas obsoletas que precisam ser contornadas constantemente, a substituição tende a ser mais eficiente.

2. Existe documentação suficiente para uma migração segura? Modernizar exige entender o que o sistema faz. Substituir exige o mesmo. A diferença é que, sem documentação, uma substituição completa se transforma em um projeto de reverse engineering disfarçado — com todos os riscos e custos que isso implica.

3. Qual é o custo real de uma falha durante a transição? Para sistemas de missão crítica — processamento de pagamentos, gestão de riscos, controle de estoque em tempo real —, uma interrupção tem um custo mensurável por hora. Esse número precisa entrar no cálculo de risco de qualquer abordagem escolhida.

4. A equipe atual tem capacidade para executar? Projetos de modernização falham mais por capacidade de execução do que por escolhas técnicas erradas. Uma substituição completa com uma equipe inexperiente em sistemas distribuídos pode ser mais arriscada do que uma modernização incremental com a equipe existente.

5. O fornecedor do sistema ainda oferece suporte? Sistemas rodando em versões fora de suporte de fornecedores como Oracle, SAP ou IBM têm um risco de segurança crescente que precisa ser considerado independentemente de outros fatores.

6. Em quanto tempo o investimento precisa retornar? Substituições completas costumam ter horizonte de retorno mais longo. Modernizações incrementais permitem capturar valor mais cedo. O horizonte de retorno esperado pelo negócio deve calibrar a escolha da abordagem.

Modernização incremental: quando faz sentido e como executar

A modernização incremental — frequentemente chamada de abordagem strangler fig, em referência ao padrão arquitetural descrito por Martin Fowler — consiste em envolver progressivamente o sistema legado com novos componentes, transferindo funcionalidades uma a uma até que o núcleo antigo possa ser desligado com segurança.

Essa abordagem faz sentido quando: o sistema ainda reflete regras de negócio válidas; a equipe conhece profundamente o comportamento do sistema; o negócio não pode tolerar interrupções; e existe budget para um projeto de médio prazo (18 a 36 meses em sistemas de grande porte).

A execução exige disciplina arquitetural. Os erros mais comuns que vejo são: começar pela modernização das partes mais simples em vez das mais críticas, criando uma falsa sensação de progresso; não estabelecer fronteiras claras entre o sistema legado e os novos componentes, gerando acoplamento que anula os benefícios; e subestimar o esforço de testes de regressão, que em sistemas legados sem cobertura de testes automatizados pode consumir mais tempo do que o desenvolvimento.

Uma referência prática: em um projeto que conduzi para uma instituição financeira de médio porte, a modernização de um core bancário legado foi estruturada em sete módulos funcionais, com entregas a cada quatro meses. O projeto levou três anos, mas o negócio capturou valor desde o terceiro mês, quando o primeiro módulo — processamento de liquidações — foi migrado para a nova arquitetura em cloud AWS. A redução de custo operacional nesse módulo isolado já justificou o investimento do primeiro ano.

Substituição completa: quando é a escolha certa e como não errar

A substituição completa — reescrever ou implantar um novo sistema do zero — é a opção mais arriscada e, ao mesmo tempo, às vezes a única viável. Ela faz sentido quando: o sistema carrega lógica de negócio obsoleta que cria mais fricção do que valor; a arquitetura é tão rígida que qualquer mudança exige esforço desproporcional; o custo de manutenção do legado é tão alto que financia o novo sistema em poucos anos; ou quando existe uma solução de mercado madura que atende 80% ou mais dos requisitos.

O erro clássico em projetos de substituição completa é o que a indústria chama de big bang rewrite: parar tudo, reescrever do zero, e ligar o novo sistema em uma data definida. A história da tecnologia empresarial está cheia de projetos que morreram assim — alguns depois de anos de desenvolvimento e investimentos na casa dos R$ 50 milhões a R$ 200 milhões sem nada entregue em produção.

A abordagem correta, mesmo em substituições completas, é a execução em fases paralelas. O sistema legado continua operando enquanto o novo é desenvolvido e validado. A migração de dados e usuários acontece em ondas controladas, com possibilidade de rollback em cada etapa. E os critérios de sucesso para cada fase precisam ser definidos antes do início — não durante a execução, quando a pressão para continuar em frente costuma nublar o julgamento.

O fator humano que ninguém quer discutir

Toda decisão sobre sistemas legados tem uma dimensão política que os frameworks técnicos ignoram deliberadamente. O sistema legado tem donos. Existem pessoas que construíram suas carreiras em torno dele, que detêm o conhecimento crítico sobre seu funcionamento, e que têm razões — algumas conscientes, outras não — para resistir à mudança.

Isso não é crítica. É realidade organizacional. E ignorá-la é uma das principais causas de fracasso em projetos de modernização.

Em projetos bem-sucedidos que acompanhei, o padrão consistente foi o seguinte: os profissionais que mais conhecem o sistema legado foram colocados no centro do projeto de modernização, não na periferia. Eles se tornaram os guardiões do conhecimento de negócio — documentando regras, validando comportamentos, definindo casos de teste. Essa reposicionamento transforma potenciais resistentes em protagonistas, e captura um ativo que seria perdido em uma abordagem puramente técnica.

Decisão como vantagem competitiva

Empresas que tratam a modernização de sistemas como um projeto de TI perdem. Empresas que tratam como uma decisão estratégica de negócio ganham — não apenas em eficiência, mas em capacidade de mover mais rápido, de experimentar com menor custo e de responder a mudanças de mercado que seus concorrentes ainda estão tentando entender.

A pergunta não é modernizar ou substituir. A pergunta real é: que posição competitiva você quer ocupar nos próximos cinco anos, e qual decisão sobre seus sistemas legados te coloca mais perto ou mais longe disso?

Essa pergunta merece uma conversa séria — com dados, com critérios claros e sem a pressão de quem quer vender um projeto. Se você está diante dessa decisão agora, ou prevê que estará nos próximos meses, vale a pena estruturar essa análise antes que a urgência force uma escolha que poderia ter sido melhor com mais tempo e clareza.