Como um sistema em Clipper de 1996 ainda roda uma indústria inteira em 2026

O primeiro pedido saiu em 29 de abril de 1996. Naquele dia, o sistema era um programa em Clipper Summer'87, rodando em Windows, com arquivos DBF em rede local. Internet comercial mal existia no Brasil. Windows 95 tinha acabado de chegar.

Hoje, em 2026, esse mesmo sistema — reescrito, migrado, evoluído — ainda roda. Todo dia. Para mais de 130 pessoas. Em uma indústria do setor automotivo no interior de São Paulo que não para.

E até agora, processou 1.054.897 pedidos. Mais de 9,9 milhões de itens.

Trabalho nesse sistema há 21 anos. E ele me ensinou mais sobre software do que qualquer livro, framework ou metodologia.

Como começou

O sistema foi criado por um grande desenvolvedor que continua à frente do projeto até hoje, e que entendeu desde o início que um ERP genérico não seria suficiente para a complexidade da operação. A empresa tinha processos específicos — fabricação de componentes automotivos, controle de qualidade rigoroso, logística para representantes espalhados pelo Brasil inteiro — que nenhum software pronto cobria direito.

A escolha foi Clipper Summer'87: a linguagem padrão para sistemas comerciais da época no Brasil. Rápida, eficiente para o hardware disponível, com um ecossistema de bibliotecas razoável. Os dados ficavam em arquivos DBF, o padrão xBase que todo mundo conhecia.

O primeiro pedido processado foi em 29/04/1996. Nenhum ERP do mercado sobreviveu tanto tempo quanto esse sistema feito sob medida.

Entrei no projeto 9 anos depois, em 2005. O sistema já tinha anos de histórico, milhares de pedidos e dezenas de usuários. Minha função era — e ainda é — garantir que ele continuasse evoluindo sem parar a operação.

A linha do tempo: três vidas tecnológicas

O que esse sistema controla hoje

Quando descrevo o escopo para alguém de fora, a reação costuma ser incredulidade. Um sistema em xHarbour controlando tudo isso?

• Vendas: 10 vendedores internos, gestão de pedidos, tabelas de preço, condições comerciais
• Representantes: 17 representantes externos cobrindo o Brasil inteiro, comissões, carteiras de clientes
• Logística: expedição, controle de estoque, embalagem, recebimento de mercadorias
• Fábrica: PCP (Planejamento e Controle da Produção), Controle de Qualidade, freios, reparos, custos de produção
• Compras: cotações, pedidos de compra, recebimento de matéria-prima e improdutivos
• Financeiro: contas a pagar, contas a receber, fluxo de caixa
• Fiscal: emissão de NF-e integrada com SEFAZ

São mais de 1.019.811 linhas de código (sem contar bibliotecas externas). Desenvolvidas ao longo de 30 anos, por duas pessoas que conhecem cada linha desse sistema melhor do que qualquer ferramenta de análise estática jamais conhecerá.

Por que ele ainda funciona — e o que isso ensina

Essa é a pergunta que mais me fazem quando descrevo o sistema. "Por que não jogaram fora e compraram um SAP?"

A resposta é simples: porque funciona melhor do que qualquer alternativa disponível para essa operação específica.

A decisão de migrar para Linux foi transformadora. Antes, com DBF em rede Windows, a corrupção de índices era uma ameaça real — os dados trafegavam pela rede, e qualquer instabilidade podia corromper arquivos. Com terminal server em Linux, o paradigma mudou: os dados ficam no servidor. Só a tela trafega. É o mesmo princípio que faz o mainframe ser confiável há 60 anos.

A migração para MySQL foi outro salto. DBF é ótimo para simplicidade, mas não foi feito para 9,9 milhões de registros com integridade relacional. MySQL trouxe transações, foreign keys, índices B-tree eficientes e — crucialmente — a possibilidade de conectar o sistema com o mundo externo via queries e APIs.

O momento em que tudo poderia ter dado errado

A migração de DBF para MySQL foi feita em um final de semana. Do ponto de vista técnico, foi bem-executada. Mas qualquer um que já fez uma migração desse porte sabe: o risco real não é técnico — é humano. São 30 anos de dados, regras implícitas nos DBFs, campos com significados que só os desenvolvedores conhecem.

O que protegeu a migração foi o conhecimento acumulado. Não existe documentação completa de um sistema de 30 anos. O que existe são as pessoas que viveram cada decisão, cada exceção, cada gambiarra que virou regra de negócio. Esse conhecimento não está em nenhum manual.

O que acontece quando um sistema assim precisa evoluir

Esse sistema é o que o mercado chama de software legado — um termo que carrega certa conotação negativa, como se "legado" fosse sinônimo de "problema". Na minha experiência, é exatamente o oposto: software legado bem mantido é software que sobreviveu ao teste do tempo. É o que prova que funciona.

A pergunta que recebo com mais frequência de gestores de TI é: "Mas e quando precisar mudar? É difícil?"

Depende do que você chama de difícil. Não é difícil para quem conhece o sistema. É impossível para quem não conhece.

Esse é o risco real dos sistemas legados — não a tecnologia, mas o conhecimento concentrado. Quando os desenvolvedores originais se aposentam ou saem, o sistema vira uma caixa preta. Não porque o código é ruim, mas porque o contexto foi embora junto.

É por isso que modernizar um sistema legado não significa reescrever do zero. Significa documentar, transferir conhecimento, e criar uma camada moderna por cima de uma base que funciona. Jogar fora 30 anos de regras de negócio para reescrever em React + Node não é modernização — é apagar a memória institucional da empresa. A modernização de software legado feita corretamente preserva o que funciona e adiciona o que faltava.

O futuro do software legado

Enquanto escrevo isso, o sistema está rodando. Pedidos estão sendo processados. NF-es estão sendo emitidas. Representantes em todo o Brasil estão consultando clientes. A fábrica está acompanhando a produção.

E agora, pela primeira vez em 30 anos, existe uma camada de IA por cima desse sistema — dashboards gerados automaticamente, alertas enviados por WhatsApp, análises que antes levavam horas sendo geradas em segundos.

O sistema não vai ser substituído. Vai ser aumentado.

Essa, para mim, é a lição mais importante de 30 anos desenvolvendo software para indústria: o melhor sistema não é o mais moderno. É o que resolve o problema real da empresa — e continua resolvendo, ano após ano, independente de qual tecnologia está na moda.