Em muitas empresas com vinte ou trinta anos de atividade há um computador que ninguém se atreve a desligar. Fica numa secretária ao canto, ou num pequeno servidor na sala do arquivo, corre uma versão do Windows que já ninguém instala e tem lá dentro a aplicação onde se registam as encomendas, se calculam os preços por cliente ou se planeia a produção da semana. Foi feita em Access, em Visual Basic 6, em Delphi ou em FoxPro, por alguém que conhecia o negócio como poucos e que, entretanto, se reformou ou mudou de empresa. Funciona, e toda a gente sabe que funciona. Toda a gente sabe também que, no dia em que deixar de funcionar, ninguém sabe muito bem o que fazer.
Noutras empresas é um livro de Excel com macros VBA que cresceu durante uma década, ou um ERP feito à medida há quinze anos por uma software house que já fechou, com suporte reduzido ao telemóvel de alguém que ainda atende por simpatia.
Este artigo é sobre como substituir esse sistema sem que a operação dê por isso. Mantê-lo e acrescentar-lhe IA por cima é outra conversa, que tratámos no artigo sobre integrar IA no software que a empresa já usa.
Resposta curta
Um sistema antigo moderniza-se sem parar a operação substituindo-o por módulos. Constrói-se uma área nova de cada vez, ligada à mesma informação, que corre duas a quatro semanas em paralelo com a antiga, e a parte antiga só é desligada quando os números batem certo. Antes de construir, extraem-se as regras de negócio que ficaram escondidas no código. Um primeiro módulo custa tipicamente entre 7.500€ e 15.000€ quando é um processo automatizado, ou entre 15.000€ e 25.000€ quando é um portal de âmbito único, e entra em produção em 6 a 12 semanas.
Troca-se aos bocados, com o antigo ligado
Um sistema crítico substitui-se por partes: escolhe-se uma área bem delimitada, constrói-se a versão nova dessa área, põe-se a correr ao lado da antiga até os resultados baterem certo e só então se desliga a parte antiga. Depois passa-se à seguinte. Em cada momento a empresa tem um sistema que funciona, e cada passo é pequeno o suficiente para ser revertido.
As modernizações que correm mal costumam ter tentado o contrário.
Sinais de que o sistema antigo já passou a ser um risco
Nenhum destes sinais, sozinho, obriga a mudar. Três ou quatro juntos, sim:
- só uma ou duas pessoas sabem o que fazer quando aparece uma mensagem de erro;
- o computador onde a aplicação corre não pode ser atualizado, porque da última vez que se tentou a aplicação deixou de abrir;
- um campo novo ou um relatório diferente demora semanas, ou simplesmente não se consegue;
- ninguém sabe onde está o código-fonte, ou sabe, mas já não há quem o consiga alterar e voltar a compilar;
- já se tentou ligar o sistema à loja online, ao banco ou ao programa de faturação e a resposta foi "não dá".
O custo de não fazer nada
O primeiro custo é a dependência de pessoas. Um sistema que só uma pessoa percebe tem um ponto único de falha que tira férias, adoece e, um dia, se reforma.
O segundo é a plataforma. O Windows 10 chegou ao fim do suporte a 14 de outubro de 2025 e, nas empresas, só continua a receber atualizações de segurança através do programa de atualizações alargadas da Microsoft, pago por equipamento e limitado a três anos. O Office 2016 e o Office 2019, incluindo o Access dessas versões, terminaram o suporte na mesma data. Os programas continuam a abrir, mas deixaram de receber correções de segurança. E muitas aplicações antigas não correm bem em versões recentes, o que leva empresas a manter de propósito um computador desatualizado ligado à rede, porque é o único onde o programa abre.
O terceiro é a segurança. É comum encontrar a base de dados numa pasta partilhada com acesso total para todos, palavras-passe em texto simples numa tabela e nenhum registo de quem alterou o quê.
O quarto, e o que mais pesa no dia a dia, é a impossibilidade de integrar. Um cliente grande que quer enviar encomendas por via eletrónica, um portal para os comerciais, um processo que podia ser automatizado: cada exigência nova vira um remendo ou um "não". E o pior momento para decidir tudo isto é durante uma avaria, com a operação parada.
Três formas habituais de correr mal
A grande substituição de uma só vez. Meses a construir em isolamento, migração de tudo num fim de semana e, na segunda-feira, os números não batem certo e faltam funções que ninguém tinha mencionado. É frequente a empresa voltar ao sistema antigo "só por uns dias", que se tornam definitivos.
Copiar o sistema antigo ecrã a ecrã. Parece eliminar o risco de esquecer alguma coisa, mas quinze anos de uso deixam atalhos e contornos: o campo "Obs2" que passou a guardar a referência do transportador, o botão que ninguém carrega, o relatório que existe porque um cliente o pediu em 2012. Reproduzir os ecrãs é herdar os vícios. Replica-se o processo, não a interface.
Migrar os dados e esquecer as regras. Os dados passam todos, mas a regra que dava 3% de desconto a determinado grupo de clientes acima de um certo volume, ou a que bloqueava expedições para clientes com faturas vencidas há mais de sessenta dias, vivia no código. Ninguém sabia que estava lá, e descobre-se quando as primeiras faturas saem erradas.
Como se substitui por módulos
O padrão que usamos tem um nome curioso em engenharia, strangler, inspirado nas figueiras estranguladoras que crescem à volta de uma árvore até a substituírem por completo. Em linguagem simples, funciona assim.
Constrói-se uma camada nova ao lado do sistema antigo, ligada à mesma informação. O primeiro módulo costuma ser algo na periferia, que doa e esteja pouco emaranhado com o resto: a consulta de encomendas e de stock pelos comerciais, um portal onde os clientes acompanham os pedidos, o cálculo de preços ou o planeamento da produção que hoje vive numa folha à parte. Esse módulo lê os dados do sistema antigo, mais tarde passa a ser ele a criá-los e, quando isso acontece, a parte equivalente do sistema antigo é congelada. Repete-se área a área, e o antigo vai encolhendo até não ter nada para fazer.
Há um detalhe técnico que decide se isto corre bem ou mal: cada tipo de informação tem de ter, em cada momento, um único dono. Se os clientes passam a ser criados no sistema novo, deixam de poder ser criados no antigo, e a sincronização faz-se num só sentido. Dois sistemas a escrever no mesmo registo é a receita mais rápida para dados que ninguém consegue explicar. Durante a transição, uma camada de integração mantém os dois alinhados, por exemplo copiando para o antigo os clientes criados no novo, porque a faturação ainda lá está.
A ordem dos módulos não é técnica, é de negócio. Começa-se pelo que tem mais impacto e menos dependências, e deixa-se o núcleo, normalmente faturação e stocks, para o fim. Muitas vezes, aliás, o núcleo nem deve ser construído à medida.
As regras que só existem no código
O verdadeiro valor de um sistema antigo não está no código, está nas regras de negócio que lá ficaram ao longo dos anos e que ninguém documentou. Estão em consultas do Access, módulos VBA, eventos de formulários Delphi e procedimentos na base de dados: arredondamentos, descontos em cascata, exceções por cliente, datas de corte.
Para as extrair usamos três fontes: o código, as pessoas que usam o sistema todos os dias e que sabem o que se faz à mão porque o sistema faz mal, e a comparação de resultados, em que se pega num mês de dados reais, se passa pelas regras novas e se compara com o que o sistema antigo produziu. Cada diferença é um erro no novo, uma regra esquecida ou, com alguma frequência, um erro antigo que as pessoas corrigem à mão há anos.
Onde a inteligência artificial ajuda, e onde não chega
A leitura de código antigo é uma das áreas em que a IA mudou de facto o trabalho. Um modelo de linguagem consegue percorrer milhares de linhas de Visual Basic, VBA, Delphi ou SQL, explicar em português o que cada rotina faz, identificar que tabelas cada ecrã lê e escreve, apontar código que já não é chamado em lado nenhum e produzir um primeiro catálogo de regras de negócio. Uma leitura que levava semanas pode passar a levar dias.
Tem, no entanto, limites claros. Não sabe se uma regra escrita em 2011 ainda se aplica, nem se aquele cliente com tratamento especial ainda é cliente: isso valida-se com quem conhece a operação. Pode descrever com confiança uma regra que não está bem no código, por isso cada regra extraída é confirmada no código e nos dados. E não deve traduzir o código antigo linha a linha, porque o resultado é o mesmo sistema com sintaxe nova. Quanto à confidencialidade, o código e os dados são analisados em ambientes cujos contratos excluem o treino de modelos.
Dados: migra-se uma vez, ensaia-se muitas
Os dados de um sistema com quinze anos nunca estão limpos: clientes duplicados, NIF em falta, códigos de artigo reutilizados para produtos diferentes, datas guardadas como texto. Parte corrige-se na migração, parte exige uma decisão da empresa, e convém saber cedo qual é qual.
A migração faz-se com um processo automático e repetível, ensaiado várias vezes com cópias reais dos dados. No dia definitivo, repete-se algo que já correu bem quatro ou cinco vezes.
Depois vem o período em paralelo. Durante duas a quatro semanas, ou um fecho de mês completo quando o módulo mexe em valores, os dois sistemas trabalham ao mesmo tempo e comparam-se os números que importam: o total faturado do dia, o stock no fim do dia, o saldo das contas correntes. O sistema antigo só é desligado quando os números batem certo, e o plano para voltar atrás fica definido antes de começar, não durante um problema.
Como trabalhamos
1. Diagnóstico
Uma conversa de 30 minutos, gratuita e sem compromisso de avançar, de preferência com o sistema aberto no ecrã. Olhamos para a tecnologia, para os dados, para quem o usa e para o que dói mais, e a empresa fica com uma primeira leitura dos riscos e da ordem pela qual faria sentido substituir.
2. Levantamento de regras e de dados
Leitura do código com apoio de IA, entrevistas e análise dos dados. Daqui sai um catálogo de regras validado pela empresa, que fica como documentação própria aconteça o que acontecer.
Cada vez mais empresas chegam a esta fase com um protótipo do módulo novo feito no ChatGPT, no Claude, no Gemini ou em ferramentas como Lovable ou Cursor. Isso encurta o levantamento e baixa o preço, porque os ecrãs e as regras principais já estão à vista. O protótipo não traz contas de acesso, dados reais migrados, ligação ao ERP e ao sistema antigo, cópias de segurança nem testes, que são precisamente o que este artigo descreve. Explicamos a diferença no artigo sobre levar um protótipo feito com IA a produção e na página sobre aplicações feitas com IA em produção.
3. Primeiro módulo em produção
Construção, integração com o sistema antigo, migração ensaiada e período em paralelo, com uso real.
4. Módulos seguintes
Um de cada vez, com a ordem revista depois de cada entrega, porque o primeiro módulo revela sempre coisas que o diagnóstico não podia ver.
5. Desligar o antigo
O histórico fica arquivado num formato consultável sem a aplicação antiga, e o computador que ninguém se atrevia a desligar é finalmente desligado. O código, a documentação e o sistema ficam propriedade da empresa.
Investimento e prazo, módulo a módulo
Depende do módulo, e as gamas publicadas nas nossas páginas de solução aplicam-se diretamente.
| Tipo de módulo | Exemplo típico | Investimento |
|---|---|---|
| Um processo automatizado | Substituir as macros que geram as encomendas aos fornecedores | 7.500€ a 15.000€ |
| Vários processos ligados | Encomendas, aprovações e conferência de faturas | 15.000€ a 35.000€ |
| Portal de âmbito único | Consulta de encomendas e stock pelos comerciais | 15.000€ a 25.000€ |
| Plataforma multi-perfil | Clientes, comerciais e armazém, com permissões distintas | 25.000€ a 45.000€ |
| Plataforma central da operação | O sistema novo passa a ser onde a operação vive, com migração completa | a partir de 45.000€ |
Um primeiro módulo entra em produção, tipicamente, em 6 a 12 semanas: mais perto das seis quando é um processo automatizado, mais perto das doze quando é um portal. Seguem-se as duas a quatro semanas em paralelo antes de a parte antiga ser desligada. A substituição completa distribui-se por vários meses, e isso é uma vantagem: o investimento acompanha os resultados e cada fase é avaliada antes de se decidir a seguinte. O que faz variar estes prazos está no artigo sobre quanto tempo demora um projeto de software à medida, e o que deve vir discriminado em cada proposta, no artigo sobre o que deve incluir um orçamento de software à medida.
O que mais mexe no valor é a quantidade de regras escondidas, a qualidade dos dados e a forma de chegar a eles. Uma base de dados Access ou SQL Server lê-se sem grande dificuldade. Ficheiros em formatos antigos e pouco documentados, comuns em aplicações Delphi ou FoxPro, dão mais trabalho antes de se escrever uma linha do sistema novo.
Quando o que está em causa é substituir um ERP completo, contabilidade e faturação incluídas, a conversa começa no diagnóstico, e a resposta mais frequente é que essa parte não deve ser construída à medida. Explicamos porquê no artigo sobre ERP à medida ou Primavera, PHC, ARTSOFT e SAP.
Quando não compensa
Se o sistema é estável, tem poucos utilizadores, não precisa de falar com mais nada e a pessoa que o mantém continua na empresa e está disponível para documentar o que sabe, o mais sensato é um investimento pequeno: isolar a máquina onde corre, garantir cópias de segurança já testadas e escrever as regras principais. Compra-se tempo para decidir com calma.
Se o que a aplicação antiga faz é genérico, como faturação, contabilidade ou processamento de salários, a substituição certa é um produto de mercado. O software de faturação em Portugal tem de ser certificado pela Autoridade Tributária, e os produtos certificados já mantêm essas exigências atualizadas.
E se a empresa vai passar por uma fusão, uma venda ou uma reorganização nos próximos meses, vale a pena esperar.
Perguntas a responder antes de avançar
- Se o sistema não abrir amanhã de manhã, quanto tempo aguenta a operação sem ele?
- Quem são as pessoas que sabem como funciona, e quanto do seu tempo podem dedicar a explicá-lo?
- Alguém consegue abrir a base de dados fora da aplicação, ou os dados só são acessíveis através dela?
- Que partes do sistema doem mais hoje, e quais funcionam bem e podem esperar?
- Há prazos externos a pressionar, como uma mudança de servidor, uma exigência de um cliente ou o fim de suporte de uma peça da plataforma?
Construímos portais e plataformas internas que vão ocupando o lugar do sistema antigo módulo a módulo, e automação de processos para as macros e folhas que hoje seguram partes da operação. Se tem um sistema destes a suportar o negócio, pode pedir um diagnóstico gratuito. Olhamos para o que existe, sem compromisso, e devolvemos uma proposta com âmbito, prazo e investimento definidos, incluindo a ordem pela qual substituir cada parte. Respondemos aos pedidos de contacto em 24 horas úteis.
