Modernizar ou substituir sistema legado: 4 perguntas

Decidir entre modernizar ou substituir sistema legado raramente é uma questão de tecnologia. É uma decisão de negócio: quanto o processo sustentado por esse sistema vale para a empresa, quanto ele ainda aguenta mudar e quanto risco a operação está disposta a correr enquanto nada é feito.

Na prática, essa escolha costuma chegar à diretoria já embrulhada em uma proposta. Um fornecedor recomenda reescrever tudo, outro sugere um produto de mercado, um terceiro propõe apenas integrar. Cada um tende a indicar a resposta que sabe entregar, e o gestor fica sem um critério próprio para comparar.

Este guia propõe uma régua simples, com quatro perguntas de negócio, para organizar essa conversa. Ela não substitui uma análise técnica, mas ajuda a chegar a ela sabendo o que perguntar e por qual caminho vale começar.

O que significa modernizar ou substituir um sistema legado?

Sistema legado é aquele que continua sustentando processos importantes, mas foi construído com tecnologias, arquitetura ou práticas que dificultam sua evolução. Ele pode ser antigo ou relativamente recente; o que o define é o esforço crescente para mantê-lo e alterá-lo.

Entre manter tudo como está e trocar o sistema inteiro existe uma escada de opções. O material do Gartner sobre 7 opções para modernizar sistemas legados, publicado em 2019, ordena essas alternativas da mais simples, com menor risco e impacto no negócio, para a mais difícil: encapsular (expor dados e funções por meio de API, a interface que permite a outros sistemas conversar com ele), rehospedar, replataformar, refatorar, rearquitetar, reconstruir e substituir.

A AWS organiza a mesma decisão em sete estratégias, os chamados 7 Rs, no guia de estratégias de migração da AWS Prescriptive Guidance. O documento classifica a refatoração como a opção "mais complexa e cara" e recomenda usá-la em grandes migrações apenas quando as demais não forem aceitáveis.

Para a diretoria, essas listas cabem em três caminhos:

• Integrar: manter o sistema e conectá-lo aos demais por APIs, sem mexer no seu núcleo;
• Modernizar por etapas: evoluir ou reconstruir partes do sistema, módulo a módulo, preservando as regras que funcionam;
• Substituir: trocar o sistema por um produto de mercado ou por uma nova solução, migrando dados e processos.

Por que a escolha costuma começar pelo fornecedor

A vontade de mexer no legado já existe. Uma pesquisa da TQI com a Fundação Dom Cabral e a Integratum, divulgada pela TI Inside em setembro de 2026, ouviu 51 empresas brasileiras de 19 setores: 88% dizem estar planejando, iniciando ou avançando na atualização do legado, mas apenas 16% classificam o preparo das equipes como alto ou muito alto.

Esse descompasso ajuda a explicar por que a decisão é terceirizada. Quando o time interno não tem fôlego para avaliar as opções, a proposta mais bem apresentada vira a estratégia. O risco é escolher o caminho pela ferramenta disponível, e não pelo problema que precisa ser resolvido.

O próprio Gartner recomenda partir dos direcionadores de negócio e de TI antes de escolher a opção. As quatro perguntas a seguir traduzem essa recomendação para a linguagem de quem responde pela operação.

Modernizar ou substituir o sistema legado: 4 perguntas para decidir

1. O processo que o sistema sustenta ainda é diferencial?

Alguns sistemas carregam a forma particular como a empresa atende, precifica, produz ou controla sua operação. Outros executam rotinas que são praticamente iguais em qualquer empresa do setor, como folha de pagamento ou contabilidade padrão.

Se o processo é diferencial, trocar o sistema por um produto genérico pode significar abrir mão justamente do que diferencia a empresa. Se não é, dificilmente vale a pena manter e evoluir um software próprio para fazer o que o mercado já oferece pronto.

2. O sistema aguenta as mudanças que o negócio pede?

A pergunta não é se o sistema funciona hoje, mas se ele acompanha o que a empresa precisa fazer nos próximos anos: novos canais, novas regras fiscais, novas integrações, maior volume.

Quando as mudanças pedidas pelo negócio cabem no sistema com esforço razoável, integrar tende a resolver. Quando cada ajuste vira projeto de meses e ninguém garante que não vai quebrar outra parte, o núcleo precisa evoluir, e a conversa passa a ser sobre modernizar por etapas.

3. Existe código, documentação e gente para manter?

Um sistema pode ser tecnicamente sólido e, ainda assim, frágil do ponto de vista da operação. Se o código-fonte não está disponível, se não há documentação e se apenas uma ou duas pessoas sabem mexer nele, qualquer caminho fica mais arriscado.

O guia da AWS cita justamente a falta de código-fonte, a baixa cobertura de testes e a ausência de quem saiba manter entre os motivos para refatorar ou rearquitetar uma aplicação. Nesses casos, o primeiro passo costuma ser reduzir a dependência, documentando regras e criando sustentação, antes de qualquer decisão maior.

4. O risco de segurança e suporte é aceitável?

Banco de dados, sistema operacional ou linguagem sem suporte do fabricante e vulnerabilidades conhecidas mudam a urgência da decisão. Um sistema estável, mas exposto, não pode esperar indefinidamente.

A AWS indica aposentar aplicações quando há risco de segurança causado por componentes sem suporte. Mesmo quando a troca não é imediata, uma resposta "não" a esta pergunta exige prazo definido e medidas de contenção, como isolar o acesso e monitorar o uso.

Da resposta ao caminho: por onde começar

As respostas não formam uma fórmula, mas apontam uma direção. A leitura mais comum é esta:

• Processo diferencial e sistema que ainda aguenta mudanças: integrar e manter, com sustentação e monitoramento. É a opção de menor risco na escala do Gartner, e os cuidados para planejá-la estão no guia de integração entre ERP, CRM e e-commerce;
• Processo diferencial e sistema que não acompanha mais o negócio: modernizar por etapas, extraindo módulos e reconstruindo só o que não tem conserto, como detalhamos em modernização de sistemas legados;
• Processo comum ao mercado e sistema difícil de manter: substituir por um produto pronto tende a fazer sentido, desde que a migração de dados e as integrações com o restante da operação sejam planejadas;
• Risco de segurança ou suporte inaceitável: qualquer que seja o caminho, ele ganha prazo e prioridade.

Reescrever o sistema inteiro do zero aparece no topo da escada de risco. Não é proibido, mas deve ser a resposta a perguntas que as opções anteriores não conseguem atender, e não o ponto de partida.

Exemplo prático: uma indústria com o sistema de pedidos no limite

Considere uma indústria de embalagens com um sistema de pedidos desenvolvido internamente há muitos anos. Ele calcula preços com regras comerciais próprias, negociadas cliente a cliente, e só dois analistas conhecem o código. O setor comercial pede um portal para clientes e a integração com o novo CRM; a auditoria apontou que o banco de dados está sem suporte.

Aplicando a régua:

• Processo diferencial: sim, a precificação é parte da estratégia comercial;
• Aguenta mudanças: parcialmente, pois cada alteração de regra leva semanas;
• Código, documentação e gente: o código existe, mas a documentação é mínima e o conhecimento está em duas pessoas;
• Segurança e suporte: não, o banco precisa ser atualizado ou migrado.

A empresa descarta trocar o sistema por um produto de mercado, que exigiria abandonar a lógica de preços. O plano começa pela contenção do risco do banco de dados e pela documentação das regras. Em seguida, uma camada de APIs viabiliza o portal e a integração com o CRM. Por fim, o módulo de precificação é reconstruído como sistema sob medida, enquanto o restante continua em operação.

Adiar também é uma decisão, e ela tem custo

Manter tudo como está parece neutro, mas não é. Na mesma pesquisa da TQI e da Fundação Dom Cabral, 76% das empresas consultadas destinam 70% ou mais do orçamento de TI à manutenção de sistemas legados. É dinheiro que deixa de financiar o que a diretoria pede.

Há também o efeito dos juros. Em uma pesquisa da McKinsey sobre dívida técnica, feita em 2020 com 50 CIOs de grandes empresas financeiras e de tecnologia, os executivos estimaram que 10% a 20% do orçamento destinado a produtos novos é desviado para resolver problemas ligados a ela.

O risco cresce com o tempo. O relatório GAO-25-107795 do órgão de auditoria do governo dos Estados Unidos, de julho de 2025, analisou 11 sistemas legados críticos: 7 operavam com vulnerabilidades de segurança conhecidas e 8 usavam linguagens com escassez de profissionais. É um retrato do setor público americano, mas o padrão é reconhecível em qualquer empresa que adia a decisão.

Use a régua como ponto de partida, não como diagnóstico

Cada sistema tem particularidades, e quatro perguntas não substituem a análise de arquitetura, dados, integrações e contratos. O papel da régua é outro: dar à diretoria um critério próprio para conduzir a conversa com fornecedores e com a TI.

Alguns cuidados aumentam o valor desse exercício:

• Responder às perguntas com as áreas que usam o sistema, e não apenas com a TI;
• Separar o sistema em módulos, pois as respostas podem ser diferentes para cada parte;
• Registrar as respostas e revisitá-las quando o negócio mudar;
• Desconfiar de propostas que chegam à solução antes de fazer as perguntas.

Conclusão

Modernizar ou substituir sistema legado é uma escolha que define por anos quanto a operação consegue mudar e quanto risco ela carrega. Quando a decisão parte do negócio, e não da ferramenta que o fornecedor tem para vender, a empresa tende a começar pelo caminho de menor risco e a reservar as opções mais caras para o que realmente não tem conserto.

As quatro perguntas, sobre diferencial do processo, capacidade de mudança, dependência de pessoas e risco de segurança, não encerram a análise, mas dão a ela uma ordem. Com as respostas em mãos, a conversa técnica fica mais objetiva e o primeiro passo fica mais claro.

A Clickfy pode ajudar sua empresa a aplicar essa régua ao seu cenário e a executar o caminho escolhido, seja com integração de sistemas, seja com a modernização gradual por meio de sistemas sob medida.

Agende um diagnóstico de 30 minutos para responder às quatro perguntas sobre o seu sistema e definir por onde começar.