Sistema legado é o sistema antigo que ainda sustenta a operação, mas ficou difícil de mudar e de integrar com o resto. O significado está na herança: é o software que a empresa herdou de outra fase dela, e que continua no centro do trabalho porque funciona.
Legado não quer dizer ruim. Muitos sistemas legados fazem bem o que sempre fizeram, e trocá-los por impulso destrói valor. O problema aparece quando ele vira limite: cobra um pedágio em cada mudança, não conversa com as ferramentas novas e empurra o trabalho para planilhas. Este texto mostra como reconhecer esse ponto, os riscos de manter o sistema como está e como integrá-lo aos sistemas novos sem reescrever tudo nem parar a operação.
O que faz um sistema virar legado
Legado não é sinônimo de antigo. Sistema de doze anos bem cuidado, com testes e documentação, é um ativo. Sistema de três anos escrito às pressas, sem ninguém que entenda as regras que ele executa, já é legado. A idade é coincidência; o que define é a dificuldade de mudar.
Na prática, quatro condições costumam aparecer juntas.
- Ninguém sabe explicar as regras. O conhecimento do negócio está dentro do código, e o código é a única documentação.
- Mudar dá medo. Alterar uma tela quebra outra, e por isso a equipe evita mexer.
- O sistema não conversa com nada. Sem integração possível, todo dado sai e entra por planilha e digitação.
- A dependência é de uma pessoa. Existe um fornecedor único ou um funcionário sem o qual nada anda.
Repare que nenhuma delas é técnica no sentido estrito. São todas condições de risco de negócio, e é por isso que a decisão sobre um legado não deveria ser delegada inteiramente à área técnica.
Os riscos de manter um sistema legado
O sistema legado costuma ser barato na linha do orçamento e caro em todo o resto. A conta que importa tem cinco componentes, e quatro deles nunca são somados.
| Componente | Onde ele aparece |
|---|---|
| Manutenção | A única linha que a empresa enxerga: contrato, licença, horas do fornecedor |
| Retrabalho manual | Horas da equipe digitando de um sistema para o outro, todo mês |
| Prazo de mudança | A oportunidade que passou porque o sistema levaria seis meses para acompanhar |
| Risco concentrado | O que acontece se o fornecedor único sumir ou a pessoa que entende sair |
| Teto de crescimento | O volume que a empresa não consegue atender sem contratar mais gente |
O componente mais subestimado é o retrabalho. Ele é diluído em muitas pessoas e poucos minutos, o que o torna invisível, e cresce junto com o faturamento. Vale medir uma vez: quantas horas por mês a equipe gasta transportando dado de um lugar para outro. A conta desse desperdício tem um recorte próprio em o custo dos processos manuais.
Os sinais de que passou da hora
Existem sinais que separam o sistema que ainda vale manter do que já está cobrando mais do que entrega.
- Toda mudança pequena vira projeto. Alterar um campo entra em fila de semanas.
- A empresa mudou e o sistema não. O processo real já não é o que está lá dentro, e a equipe usa contornos.
- Não dá para integrar. A conversa com qualquer ferramenta nova termina em exportação manual.
- O fornecedor é único e insubstituível. Trocar significa recomeçar, e ele sabe disso.
- A tecnologia saiu de suporte. Versão sem atualização de segurança é risco que não pode ser adiado.
- Ninguém quer trabalhar nele. Contratar para manter aquele sistema virou problema por si só.
Um sinal isolado não decide nada. Três ou mais ao mesmo tempo indicam que o sistema deixou de ser ferramenta e virou restrição do negócio.
Integração de sistemas legados: como conectar sem reescrever
Na maior parte dos casos, o miolo do sistema legado funciona e o problema é o isolamento: ele não troca dados com o ERP novo, com o e-commerce, com o BI. Antes de pensar em reescrever, vale olhar as quatro formas de conectá-lo, da mais robusta para a de último recurso.
| Forma | Como funciona | Quando usar |
|---|---|---|
| Uma API em volta do legado | Uma camada fina expõe, de forma controlada, as operações que os outros sistemas precisam: consultar pedido, gravar cliente, ler saldo. | Quando dá para acessar o banco ou as rotinas do sistema e alguém entende as regras dele. É a forma mais limpa e a que melhor envelhece. |
| Uma camada de integração | Uma ferramenta no meio (middleware ou plataforma de integração) recebe, transforma e distribui os dados entre o legado e os demais sistemas. | Quando são vários sistemas conversando e a empresa quer um lugar só para ver e tratar as falhas. |
| Uma cópia do banco para leitura | Os dados do legado são copiados com frequência para outro banco, de onde relatórios, painéis e sistemas novos leem sem tocar no original. | Quando o objetivo é consultar e analisar, não gravar. Resolve o BI e o relatório sem risco para a operação. |
| Automação de tela (RPA) | Um robô usa o sistema como uma pessoa usaria, clicando e digitando nas telas. | Por último, quando não há acesso ao banco nem às rotinas. Funciona, mas quebra quando a tela muda e precisa de vigilância. |
A escolha depende de duas perguntas: o outro sistema precisa só ler ou também gravar no legado, e quanto acesso existe ao que está por baixo das telas. O panorama completo dos modelos e de onde cada um quebra está em integração de sistemas, e o caso do robô, em RPA e automação de processos.
Um exemplo na indústria
Imagine uma indústria de médio porte com um ERP antigo, usado hoje só para o fiscal: nota, estoque contábil, apuração de impostos. A formação de preço não está nele. Está numa planilha mantida pelo comercial, com custo de matéria-prima, frete, impostos por estado e margem por cliente, e só duas pessoas sabem atualizá-la.
O primeiro impulso é trocar o ERP. É o caminho mais caro e mais arriscado, e não resolve o problema, porque nenhum ERP pronto traz a regra de preço daquela empresa. O caminho que funciona é outro: tirar a regra de preço da planilha e transformá-la em sistema, um motor de preço que lê custo e estoque do ERP antigo e devolve a ele o pedido com o preço já calculado. O ERP continua fazendo o fiscal, que faz bem; a regra que decide a margem ganha um lugar próprio, testado e com histórico. É o tipo de trabalho da frente de Operação e margem da Northern, operações e tecnologia sob medida, e quando a regra pede um sistema próprio, o assunto é software sob medida.
Manter, integrar ou trocar
Existem quatro saídas para um sistema legado: manter e conter, quando ele é estável e o processo não vai mudar; integrar por fora, quando o miolo funciona e o problema é isolamento; substituir por um produto pronto, quando o processo é comum ao mercado; e reescrever por partes, quando a regra é do negócio e é vantagem competitiva. A opção que mais aparece em conversa, reescrever tudo e trocar num único dia, é a que mais fracassa.
Duas perguntas orientam a escolha, e nenhuma é técnica: o processo que o sistema executa é diferencial da empresa ou é igual ao de todo mundo, e o que muda no negócio nos próximos dois anos. “A tecnologia é antiga”, sozinho, não decide nada. A decisão completa de trocar ou não, com os sinais, a conta e o plano de migração, está em quando trocar o sistema legado.
Se a conclusão for reescrever, o que vem antes é o escopo, e não o orçamento: o método está em como definir o escopo de um produto digital. Se for contratar quem faça, os modelos estão em desenvolvimento de software. E quando o processo que o legado executa tem cara de produto, vale quando a ferramenta interna tem potencial de produto.
Perguntas frequentes
O que é um sistema legado?
É o sistema antigo que ainda sustenta a operação, mas ficou difícil de mudar e de integrar com o resto. A idade não define: um sistema de doze anos bem documentado é um ativo, e um de três anos que ninguém entende já é legado. O que caracteriza é a combinação de regras não documentadas, medo de alterar, isolamento das outras ferramentas e dependência de um fornecedor ou de uma pessoa só. Legado não quer dizer ruim: muitos fazem bem o que sempre fizeram.
Qual o significado de sistema legado?
“Legado” vem de herança: é o software que a empresa herdou de uma fase anterior dela e que continua no centro do trabalho porque funciona. O termo não é técnico nem pejorativo. Ele descreve um sistema que foi feito para outra realidade da empresa e que hoje cobra caro para acompanhar a atual. O nome pega quando cada mudança vira projeto e cada integração vira planilha.
Quais são exemplos de sistema legado?
ERP antigo instalado em servidor próprio, que só a empresa que o vendeu sabe alterar. Sistema de gestão feito sob encomenda há muitos anos, em uma linguagem que pouca gente ainda usa. Banco de dados em Access ou planilha mestra que virou o coração de um processo. Sistema de mainframe em bancos e seguradoras. Em comum, todos funcionam, sustentam a operação e são difíceis de mudar e de integrar.
Quais os riscos de manter um sistema legado?
A manutenção é a única linha que costuma aparecer no orçamento. Os riscos estão nas outras: o retrabalho manual da equipe transportando dados, o prazo de mudança que faz a empresa perder oportunidades, a dependência de um fornecedor ou de uma pessoa que entende o sistema e o teto de crescimento que obriga a contratar mais gente para atender mais volume. Tecnologia sem atualização de segurança é o único risco que não admite adiamento.
Como integrar um sistema legado aos sistemas novos?
Há quatro formas, da mais robusta para a de último recurso: criar uma API em volta do legado, usar uma camada de integração entre os sistemas, manter uma cópia do banco para leitura e, por último, automação de tela com robôs (RPA). A escolha depende de o outro sistema precisar só ler ou também gravar no legado, e de quanto acesso existe ao banco e às rotinas por baixo das telas. Na maioria dos casos dá para integrar sem reescrever o sistema.
Quanto custa integrar um sistema legado?
Depende do acesso que se tem ao sistema e de quantas integrações são necessárias, por isso não há um número de referência honesto. Uma cópia do banco para leitura costuma ser o caminho mais barato; uma API em volta do legado custa mais, mas envelhece melhor; RPA parece barato no começo e cobra na manutenção. Integrar quase sempre custa uma fração de reescrever ou trocar o sistema. O orçamento confiável só sai depois de mapear o que cada sistema precisa ler e gravar.
Vale a pena migrar um sistema legado para a nuvem?
Depende do motivo. Levar o mesmo sistema para um servidor na nuvem resolve problemas de infraestrutura, como servidor velho, backup e acesso remoto, mas não resolve a dificuldade de mudar nem o isolamento. Se o problema é a regra presa no sistema ou a falta de integração, mudar de lugar não muda nada. A nuvem é uma decisão de infraestrutura, e o legado costuma ser um problema de negócio.
Dá para usar IA com um sistema legado?
Dá, desde que a IA não precise mexer direto no sistema. O caminho seguro é dar a ela acesso de leitura, por uma API ou por uma cópia do banco, e deixar que ela leia documentos, resuma dados ou prepare lançamentos. A gravação no legado continua passando por uma regra validada pelo sistema, nunca direto pela IA. A IA lê e sugere; o sistema calcula e valida.
Precisa trocar o ERP antigo para resolver o problema?
Quase nunca. Muitas vezes o ERP antigo faz bem a parte fiscal e contábil, e o problema está numa regra que ele nunca comportou, como a formação de preço ou o cálculo de margem, que acabou numa planilha. O caminho mais curto é transformar essa regra em sistema próprio e integrá-lo ao ERP que já existe. Trocar o ERP é um projeto muito maior e raramente resolve a regra presa na planilha.
Quando é hora de trocar o sistema legado?
Quando ele impede uma decisão de negócio, quando não há mais quem o mantenha, quando não dá para integrar de forma nenhuma ou quando cada mudança pequena leva semanas. Um sinal isolado não decide; três ou mais ao mesmo tempo indicam que o sistema virou restrição. Mesmo assim, a troca costuma ser por partes, com o sistema novo convivendo com o antigo. A decisão completa está no guia sobre quando trocar o sistema legado.
