Migração de sistemas Delphi para web, .NET ou aplicativo.

Sinais de um sistema Delphi que chegou ao limite

O Delphi foi, por muitos anos, a ferramenta mais produtiva para fazer sistema de gestão no Brasil. Por isso há tanto ERP, sistema de farmácia, de transportadora e de indústria escrito nele, a maioria em Delphi 7 ou anterior. Eles não estão quebrados. Estão presos. Os sinais costumam ser estes:

• Delphi 7 com BDE. O Borland Database Engine foi descontinuado há muitos anos e não recebe correção. Ele ainda roda, mas cada Windows novo é uma aposta, e erros de travamento de tabela e de NetDir viram rotina do suporte.
• Componentes de terceiros parados no tempo. Relatórios em versões antigas do QuickReport, telas montadas com a RX Library, grids e máscaras de fornecedores que sumiram. Sem o fonte do componente, o projeto nem compila numa versão nova do Delphi.
• Regra de negócio no evento OnClick. O cálculo do preço, a baixa do estoque e o SQL que grava o pedido moram no clique do botão, misturados com a tela. Não existe uma camada que outro sistema possa chamar.
• Bancos de arquivo ou servidor antigo. Tabelas Paradox numa pasta compartilhada, ou um Firebird/InterBase de versão antiga que ninguém se atreve a atualizar.
• Instalação máquina a máquina. Instalar o BDE, configurar o alias, mapear a unidade de rede, copiar o executável. Trabalho remoto e acesso pelo celular ficam fora de alcance.
• Conhecimento concentrado. Um ou dois programadores entendem o fonte, e contratar quem saiba Delphi 7 e queira mexer nele fica mais difícil a cada ano.

Se você reconheceu três ou mais itens, a pergunta já não é se vai migrar, mas como fazer isso sem colocar a operação em risco. É o mesmo problema de qualquer migração de sistemas legados, com as particularidades do Delphi.

Por que um conversor de Delphi para C# não resolve

Existem ferramentas que prometem traduzir o fonte Delphi para C#, Java ou outra linguagem automaticamente. A conta parece boa: o sistema inteiro convertido em pouco tempo. Na prática, o resultado é um legado novo numa linguagem nova.

O conversor traduz linha a linha, então leva junto tudo o que fazia o sistema ser difícil de manter: a regra dentro do evento da tela, o SQL espalhado pelos formulários, o acesso direto ao banco de cada tela. Os componentes de terceiros não têm equivalente, e o que sai no lugar deles é um emulador ou um buraco. E ninguém na equipe nova entende aquele código, porque ele não foi escrito por gente: foi transliterado.

O método: entender, documentar, só então codificar

O que tem valor num sistema Delphi de vinte anos não é o código Pascal. São as decisões que ele guarda: a exceção de desconto daquele cliente, o arredondamento que bate com o fiscal, o bloqueio de crédito que alguém pediu depois de um calote. O método da NasteSoft existe para resgatar isso antes de escrever uma linha nova.

1. Entender. Lemos o fonte (.pas e .dfm), o banco, as consultas que as telas fazem e os relatórios. Sentamos com quem usa o sistema todo dia para ver o que de fato é usado e o que está morto. Ferramentas de IA ajudam a ler mais rápido, mapeando dependências entre units e descrevendo rotinas longas, mas a validação é sempre humana, com quem conhece o processo.
2. Documentar. Levantamos as regras de negócio, os fluxos, os cálculos, as integrações (arquivos de banco, TEF, emissor fiscal, EDI) e o modelo de dados. Essa documentação é sua e vale mesmo que a tecnologia escolhida mude depois. Mostramos como fazemos isso em como documentar um sistema legado sem documentação.
3. Codificar. Só então escrevemos o sistema novo, já na arquitetura certa: regra de negócio num serviço com API, testes automatizados sobre os cálculos críticos e interface separada da regra. O passo a passo técnico está em como migrar um sistema Delphi.

A NasteSoft e seus parceiros já migraram bancos de dados e aplicações em Delphi, VB6 e .NET. O que essa experiência ensina é que o tempo gasto entendendo o sistema volta inteiro na hora de codificar.

Para onde levar o sistema: web, aplicativo ou desktop atualizado

Não existe um destino certo para todo sistema Delphi. A escolha depende de quem usa, de onde usa e do que o sistema precisa conversar com o hardware da empresa.

Muitas vezes a resposta é uma combinação: o núcleo vira uma API, o escritório usa a versão web e a equipe de rua usa o aplicativo. Quando o celular entra no plano, a página de aplicativos Android e iOS mostra como trabalhamos essa parte.

Uma observação sobre ficar no Delphi: atualizar de Delphi 7 para uma versão recente também é uma migração. As strings passaram a ser Unicode a partir do Delphi 2009, o BDE dá lugar a bibliotecas como o FireDAC e os componentes antigos precisam ser trocados. Pode ser a melhor opção em alguns casos, mas não é o atalho que parece.

A migração dos dados: BDE, Paradox, Firebird e InterBase

Em sistema Delphi, metade do risco está no banco. Tabelas Paradox com índice corrompido, campos de texto com acentuação gravada num conjunto de caracteres diferente do declarado, bancos Firebird criados com charset NONE, datas inválidas que o sistema antigo aceitava, chaves duplicadas que ninguém via.

Tratamos os dados como um projeto à parte, que começa cedo: mapeamento de cada tabela, regras de limpeza combinadas com a área de negócio, cargas de ensaio repetidas e conferência automática entre origem e destino (contagens, somas, amostras). O destino costuma ser um PostgreSQL ou um SQL Server atual. Os detalhes estão na página de migração de banco de dados.

Migração Delphi sem parar a operação

Não fazemos virada única numa madrugada. Usamos o padrão de estrangulamento: o sistema novo assume uma parte por vez, rodando ao lado do Delphi, e cada etapa pode ser revertida.

Imagine, como exemplo hipotético, uma distribuidora com um ERP em Delphi 7 e Firebird. A primeira entrega poderia ser uma API de consulta de preços e estoque, lendo o mesmo banco, usada por um aplicativo de vendedor externo. O ERP continua igual. Depois, o cadastro de clientes passa para a versão web e o Delphi passa a ler os dados de lá. Em seguida, pedidos. Faturamento e fiscal, que são o coração, ficam para quando a equipe já confia no novo. Em nenhum momento a empresa para de vender.

Quanto tempo leva depende do tamanho do sistema, de quantas integrações ele tem e do estado dos dados. Um sistema pequeno pode ser resolvido em semanas; um ERP inteiro é trabalho de meses, com entregas úteis desde o começo. Explicamos os fatores em quanto custa e quanto tempo leva migrar um sistema legado.

O que você recebe

• Documentação do sistema: regras de negócio, fluxos, cálculos, integrações e dicionário de dados, escritos para quem vai manter, não para enfeitar.
• Sistema novo, entregue por partes e validado em produção a cada etapa.
• API com a regra de negócio, pronta para web, aplicativo e integrações futuras.
• Testes automatizados sobre os cálculos que não podem errar.
• Dados migrados e conferidos, com o histórico preservado.
• Código e acessos em nome da empresa, e repasse para a sua equipe manter sem depender de nós.

Perguntas frequentes