# Sistema em Delphi: modernizar, trocar ou reconstruir?

> Sistema em Delphi, VB6 ou Clipper: modernizar por partes, trocar por produto de mercado ou reconstruir? Veja o critério que decide: o que se perde ao desligar.

Fonte: https://pervian.tech/blog/sistema-em-delphi-modernizar-ou-trocar · Pervian Tech · publicado em 2026-10-01

Muita empresa brasileira roda a operação inteira em um sistema em Delphi feito há quinze, vinte anos. Ele emite pedido, controla estoque, calcula comissão, imprime etiqueta e conversa com a balança. Funciona. Mas cada vez que o Windows atualiza, que o servidor dá sinal de cansaço ou que o programador que conhece o código tira férias, alguém na diretoria pergunta: não está na hora de trocar isso?

A pergunta é legítima, e a resposta automática costuma ser ruim nos dois sentidos. "Joga fora e compra um sistema moderno" ignora que aquele código guarda anos de regras que ninguém mais lembra de cabeça. "Se está funcionando, não mexe" ignora que o risco cresce em silêncio até o dia em que para de funcionar.

Este texto compara três caminhos para um sistema em Delphi (e vale igualmente para VB6, Clipper e outros sistemas antigos feitos para a rede local): modernizar por partes, trocar por um produto de mercado ou reconstruir sob medida. E mostra o critério que usamos para escolher entre eles.

**Resposta curta:** decida pelo que se perde ao desligar o sistema. Se ele concentra regras de negócio únicas que funcionam, o caminho mais seguro é modernizar por partes, preservando o banco de dados e expondo APIs. Se ele só reproduz o que um produto de mercado já faz e a base de código está degradada, trocar por um produto pronto, ou reconstruir, tende a ser a escolha mais segura.

## Por que tantas empresas ainda rodam Delphi e VB6

Não é atraso nem descuido. Durante muito tempo, Delphi e VB6 foram o jeito mais produtivo de fazer sistema de gestão para empresa pequena e média: tela rápida, acesso direto ao banco, relatório impresso, tudo rodando na rede local. Muitas software houses regionais e muitos programadores autônomos construíram carreiras inteiras nessas ferramentas.

O resultado é que esses sistemas cresceram junto com a empresa. Cada exceção comercial, cada regra de desconto, cada ajuste pedido pelo contador virou uma linha de código. Por isso eles costumam ser muito aderentes ao jeito como a empresa trabalha, mais do que qualquer produto genérico conseguiria ser no primeiro dia.

Também é comum que funcionem bem. O usuário digita rápido, conhece os atalhos de teclado de memória e não vê motivo para mudar. Esse ponto pesa na decisão e merece respeito: o problema raramente é o sistema fazer a coisa errada. O problema é o que está em volta dele.

## Os riscos reais: banco, sistema operacional, terminal e pessoas

Quando avaliamos um sistema legado, olhamos quatro frentes de risco. Elas raramente estouram juntas, mas cada uma pode parar a operação sozinha.

### Banco de dados

Muitos sistemas antigos usam bancos de arquivo, como Paradox ou DBF, ou versões antigas de bancos relacionais. Bancos de arquivo corrompem com queda de energia ou de rede, não têm controle de acesso decente e dificultam backup consistente com o sistema em uso. Versões antigas de bancos relacionais podem estar fora de suporte do fornecedor. O lado bom: o banco quase sempre é o ativo mais valioso e mais aproveitável do sistema. Os dados estão lá, organizados de algum jeito, e podem ser lidos por outras tecnologias.

### Sistema operacional e componentes

O executável depende de componentes de terceiros, drivers de impressora, bibliotecas de relatório e, às vezes, de uma versão específica do Windows. Cada atualização do sistema operacional vira uma aposta. Componentes comprados há anos podem não ter mais fornecedor nem código-fonte disponível. Tratamos esse problema com mais detalhe em [sistema em versão sem suporte](https://pervian.tech/blog/sistema-em-versao-sem-suporte).

### Terminal e acesso

O sistema foi pensado para rodar dentro da rede do escritório. Para o vendedor externo, o gestor em casa ou a filial, a solução costuma ser acesso remoto à área de trabalho, compartilhamento de pasta pela VPN ou o famoso computador ligado na sala do servidor. Funciona, mas é lento, frágil e difícil de proteger.

### Pessoas

Este costuma ser o maior risco e o menos falado. Vale separar as coisas: o Delphi continua existindo e recebendo versões novas, enquanto o VB6 parou no tempo. Nos dois casos, porém, o difícil é achar quem queira mexer em código escrito numa versão antiga, cheio de componentes descontinuados e sem testes, e o conhecimento tende a ficar com uma única pessoa, às vezes externa à empresa. Se esse é o seu caso, vale ler [como sair da dependência de um único programador](https://pervian.tech/blog/sistema-dependente-de-um-programador) antes de qualquer outra decisão: garantir acesso ao código-fonte e ao banco vem antes de modernizar ou trocar.

## Modernizar: API sobre o banco existente e telas novas na web

Modernizar não é reescrever tudo em outra linguagem de uma vez. É trocar o sistema por partes, mantendo o antigo funcionando enquanto o novo assume módulo por módulo.

Antes de desenhar qualquer coisa, vale checar uma alternativa mais modesta: se o código compila, os componentes têm equivalente atual e a dor é só compatibilidade com o Windows, atualizar o projeto para uma versão recente do próprio Delphi pode resolver por alguns anos. Não resolve acesso externo nem dependência de pessoas, mas é uma opção legítima quando o problema é estritamente técnico.

Quando a dor vai além disso, o desenho costuma ser este:

1. **Estabilizar o banco.** Se ele for de arquivo, migrar para um banco relacional atual, mantendo a estrutura compatível com o sistema antigo. Backup automático e testado entra aqui.
2. **Criar uma API sobre o banco.** Uma camada de serviços que lê e grava os mesmos dados, com as regras de negócio extraídas do código antigo e cobertas por testes. A partir daí, qualquer tela nova, aplicativo ou integração passa pela API, nunca direto pelas tabelas.
3. **Levar módulos para a web, um de cada vez.** Começa pelo que mais dói: o acesso externo do vendedor, o painel do gestor, a integração com o e-commerce. O desktop continua rodando o resto.
4. **Desligar o módulo antigo só quando o novo provar que funciona.** Cada parte tem critério de desligamento definido antes de começar.

Esse é o padrão que descrevemos em [modernização gradual de sistemas](https://pervian.tech/blog/modernizacao-gradual-de-sistemas), e os cuidados específicos de quem sai do desktop, como periféricos, impressão e atalhos de teclado, estão em [como migrar um sistema desktop para a web](https://pervian.tech/blog/migrar-sistema-desktop-para-web).

**Vantagens:** a operação não para, o risco fica dividido em etapas pequenas, as regras que funcionam são preservadas e a empresa pode pausar o projeto entre uma fase e outra sem ficar com nada pela metade.

**Desvantagens:** durante um período, convivem dois sistemas, o que exige disciplina sobre quem grava cada dado. E se o modelo de dados antigo for muito ruim, carregar ele adiante pode limitar o sistema novo.

## Trocar por produto de mercado: o que se perde de regra

Existem bons ERPs, sistemas de gestão por segmento e plataformas SaaS para varejo, distribuição, indústria, serviços e quase qualquer nicho. Muitos oferecem API e marketplace de integrações, recebem atualizações fiscais do fornecedor e têm uma base de profissionais que conhece a ferramenta. Para muitas empresas, trocar o sistema antigo por um desses é a decisão certa.

O cuidado é com o que fica para trás. Um sistema em Delphi de vinte anos tem regras que não estão escritas em lugar nenhum além do código: a tabela de preço especial de um cliente grande, o cálculo de comissão com três exceções, a reserva de estoque que considera o pedido ainda não faturado. Ao trocar por um produto, cada uma dessas regras vai ter um destino:

- **O produto já faz, por configuração.** Ótimo, a regra migra sem custo.
- **O produto faz de outro jeito.** A empresa muda o processo. Às vezes é melhoria; às vezes é perda de diferencial.
- **O produto não faz.** A regra vai para customização, planilha paralela ou some.

Antes de assinar, vale levantar as regras do sistema atual e testar cada uma contra o produto candidato, com os dados reais da empresa, não com a demonstração do fornecedor. Os recursos de cada produto mudam com frequência, então confirme diretamente com o fornecedor o que existe hoje e o que depende de customização. A comparação mais ampla entre produto pronto e sistema próprio está em [ERP sob medida ou ERP de mercado](https://pervian.tech/blog/erp-sob-medida-ou-erp-de-mercado).

A migração de dados também entra na conta. Histórico de clientes, saldos, títulos em aberto e cadastros precisam ser convertidos para o formato do produto, e os dados antigos raramente estão tão limpos quanto parecem.

## Reconstruir sob medida: quando faz sentido

A terceira opção é escrever um sistema novo, do zero, em tecnologia atual. É a que mais seduz e a que mais exige cautela. Reescrita completa tem um histórico conhecido de atrasos: o sistema antigo continua mudando enquanto o novo é construído, e regras escondidas aparecem só no dia da virada. Detalhamos esse risco em [reescrever ou refatorar um sistema legado](https://pervian.tech/blog/reescrever-ou-refatorar-sistema-legado).

Ainda assim, há situações em que reconstruir é o caminho certo:

- O código-fonte se perdeu, está incompleto ou não compila mais.
- O modelo de dados é tão confuso que qualquer camada nova em cima dele herdaria os mesmos problemas.
- O sistema é pequeno o suficiente para ser refeito em pouco tempo, com as regras levantadas e validadas antes.
- O negócio mudou tanto que boa parte do que o sistema antigo faz não serve mais.

Mesmo nesses casos, a reconstrução funciona melhor quando é entregue por módulos, com o sistema antigo ainda de pé, e não numa virada única de fim de semana.

## Tabela comparativa: modernizar x trocar por produto x reconstruir

| Critério | Modernizar por partes | Trocar por produto de mercado | Reconstruir sob medida |
|---|---|---|---|
| Regras de negócio atuais | Preservadas e extraídas para a API | Só as que o produto cobre | Precisam ser levantadas e reescritas |
| Banco de dados | Mantido, estabilizado e evoluído | Migrado para o formato do produto | Migrado para um modelo novo |
| Risco de parar a operação | Baixo, troca módulo a módulo | Concentrado na virada | Alto se for virada única; menor se for por módulos |
| Tempo até o primeiro ganho | Curto, começa pelo módulo que mais dói | Depende da implantação inteira | Longo, salvo se entregue em fases |
| Atualização fiscal e legal | Responsabilidade de quem mantém o sistema | Em geral feita pelo fornecedor, conforme contrato | Responsabilidade de quem mantém o sistema |
| Dependência de pessoas | Reduz ao documentar e testar as regras | Passa para o fornecedor e o ecossistema | Depende da equipe que construir |
| Aderência ao processo | Mantém a atual | A empresa se adapta ao produto | Total, se as regras forem bem levantadas |
| Melhor quando | Regras únicas e base aproveitável | Processos padrão e sistema que só replica o mercado | Base irrecuperável e regras que ainda importam |

## Quando escolher cada caminho

### Sinais de que modernizar é o melhor caminho

- O sistema faz coisas que nenhum produto de mercado que você avaliou faz do mesmo jeito, e isso pesa para o cliente.
- O código-fonte está disponível e compila.
- O banco tem estrutura razoável, mesmo que antiga.
- A dor principal é acesso externo, integração ou risco de infraestrutura, e não o funcionamento das regras.
- A operação não pode parar nem por poucos dias.

### Sinais de que trocar por um produto de mercado é o melhor caminho

- Ao listar o que o sistema faz, quase tudo é cadastro, pedido, nota fiscal, estoque e financeiro no formato padrão do segmento.
- A empresa já usa planilhas paralelas porque o sistema antigo não acompanha mais o processo.
- Ninguém sabe explicar por que certas regras existem, e ninguém sentiria falta delas.
- O esforço para manter a parte fiscal atualizada no sistema próprio já é grande e não diferencia a empresa.
- Existem produtos consolidados no seu segmento, com API para integrar o que for específico.

Nesse cenário, insistir em modernizar seria gastar engenharia para preservar o que o mercado entrega pronto. Trocar é a escolha honesta.

### Sinais de que reconstruir sob medida é o melhor caminho

- As regras são únicas e importantes, mas o código está perdido, não compila ou é impossível de testar.
- O modelo de dados impede a evolução e não há como estabilizá-lo sem refazê-lo.
- O escopo é delimitado e as regras podem ser levantadas e validadas com quem opera antes de escrever o novo sistema.

### Um teste rápido: o que se perde ao desligar

Faça o exercício com a equipe que opera o sistema: se ele fosse desligado amanhã e substituído pelo melhor produto de mercado do seu segmento, o que deixaria de acontecer? Liste cada item. Se a lista for curta e composta de hábitos, troque. Se a lista for longa e cheia de regras que o cliente percebe, modernize. Se a lista for longa, mas o código não permitir aproveitar nada, reconstrua por partes.

## Perguntas frequentes

### O Delphi ainda recebe atualizações?

Sim. O Delphi continua existindo e recebendo versões novas, ao contrário do VB6, que parou no tempo. O problema de um sistema em Delphi antigo raramente é a linguagem em si, e sim o código escrito numa versão antiga, com componentes descontinuados, sem testes e com o conhecimento concentrado numa única pessoa.

### Atualizar para uma versão nova do Delphi resolve o problema?

Às vezes. Se o código compila, os componentes têm equivalente atual e a dor é só compatibilidade com o Windows, atualizar o projeto para uma versão recente do Delphi pode resolver por alguns anos. A atualização não resolve acesso externo pela web nem dependência de pessoas, que costumam pedir modernização por partes.

### É possível aproveitar os dados de um banco Paradox ou DBF?

Sim. Mesmo bancos de arquivo, como Paradox e DBF, guardam os dados de forma organizada e podem ser lidos por outras tecnologias. O usual é migrar esses dados para um banco relacional atual, mantendo a estrutura compatível com o sistema antigo, e aproveitar a migração para configurar backup automático e testado.

### Quanto tempo leva para modernizar um sistema em Delphi?

Depende do tamanho do sistema, do estado do código e do banco de dados e de quantos módulos precisam mudar. Na modernização por partes, o primeiro ganho costuma vir cedo, porque o projeto começa pelo módulo que mais dói. O prazo total só pode ser estimado com segurança depois de um diagnóstico do sistema em Delphi.

## Como a Pervian Tech ajuda a decidir sobre o futuro do sistema

Nosso ponto de partida é um diagnóstico inicial gratuito: olhamos código-fonte, banco de dados, infraestrutura e dependência de pessoas, e conversamos com quem usa o sistema todos os dias para entender quais regras realmente sustentam a operação. Com isso, a recomendação fica clara, inclusive quando ela é trocar por um produto pronto, porque ele atende e mantém menos coisa nas suas mãos.

Quando as regras justificam preservar o sistema, desenhamos a modernização dentro do trabalho de [arquitetura de software](https://pervian.tech/servicos/arquitetura-de-software): estabilização do banco, API sobre os dados existentes e migração por módulos, como descrito na nossa solução de [modernização de sistemas legados](https://pervian.tech/solucoes/modernizacao-de-sistemas-legados). Quando a melhor saída é reconstruir, fazemos isso em fases, com o sistema antigo ainda funcionando. O investimento é definido sob consulta, depois de entender o tamanho e o estado do sistema.

Para mais conteúdo sobre o tema, veja os textos da categoria [modernização](https://pervian.tech/blog/categoria/modernizacao). Se o sistema em Delphi da sua empresa está nessa encruzilhada, [conte como ele funciona hoje](https://pervian.tech/#contato).