Como migrar um sistema Delphi: o passo a passo sem parar a empresa

Antes do passo a passo: o que "migrar" quer dizer aqui

Quando alguém pergunta como migrar um sistema Delphi, quase sempre está perguntando outra coisa: como trocar a base tecnológica sem perder o que o sistema sabe fazer. Porque o valor de um sistema de quinze ou vinte anos não está no código Pascal — está nas regras de negócio que foram sendo acumuladas nele: o desconto que só vale para um tipo de cliente, o arredondamento do imposto que o contador pediu em 2011, o bloqueio de pedido que alguém acrescentou depois de um prejuízo.

É por isso que a abordagem que defendemos em toda migração de sistemas legados tem três tempos, nesta ordem: entender como o sistema funciona de verdade, documentar essas regras e só então codificar o sistema novo — por partes, com o antigo rodando ao lado. O roteiro abaixo detalha cada etapa para o caso específico do Delphi — e vale tanto para quem quer sair do Delphi quanto para quem quer modernizar o sistema Delphi e continuar nele.

Etapa 1 — Inventário: o que exatamente você tem

Parece burocracia e é a etapa que mais economiza dinheiro. Sem inventário, toda estimativa é chute, e a surpresa aparece no meio do projeto: um componente que ninguém sabia que existia, uma DLL que conversa com a balança, um relatório que o financeiro usa uma vez por ano no fechamento.

Versão do Delphi e do código

Delphi 7 é a versão mais comum em sistemas legados, mas também aparecem Delphi 5, 6, 2007 e versões posteriores. A versão importa: a partir do Delphi 2009 o tipo string passou a ser Unicode, o que muda o comportamento de todo código que trata texto byte a byte, chama APIs do Windows ou grava em arquivo. Verifique também se o código-fonte que está no repositório (quando há repositório) é de fato o que gerou o executável em produção.

Componentes de terceiros

Liste cada pacote instalado na IDE e usado no projeto: grades, editores, geradores de relatório, bibliotecas de comunicação, controles visuais. Para cada um, anote se o fornecedor ainda existe, se há versão para Delphi recente e se você tem o código-fonte do componente. Componente sem fonte e sem fornecedor é o ponto em que muitas atualizações de versão travam.

Banco de dados e driver de acesso

Duas perguntas separadas: qual banco (Paradox, Access, Firebird/InterBase, MySQL, SQL Server, Oracle) e por qual camada o sistema chega nele. O BDE, comum em sistemas da era Delphi 7, foi descontinuado há anos e depende de configuração em cada estação. Depois vieram o dbExpress, o ADO (dbGo), bibliotecas específicas como IBX para InterBase/Firebird e, nas versões mais recentes, o FireDAC. Saber qual é usado — e se são vários misturados — define boa parte do esforço.

Relatórios

QuickReport, Rave, FastReport, ReportBuilder, Crystal: cada relatório é uma pequena aplicação com consulta, agrupamento, totalização e formatação próprias. Conte quantos são, quais são usados de verdade (pergunte, e se possível meça) e quais têm cálculo que não existe em nenhum outro lugar.

DLLs, integrações e arquivos

DLLs próprias ou de fornecedores (impressora fiscal, TEF, balança, leitor biométrico), chamadas a webservices, troca de arquivos texto com banco ou contabilidade, arquivos .ini e chaves de registro com configuração, tarefas agendadas que rodam executáveis auxiliares. Cada integração é um contrato que o sistema novo precisa honrar.

Infraestrutura e uso real

Onde roda: estações locais, pasta compartilhada na rede, servidor de terminal, acesso remoto. Quantos usuários simultâneos. Quais telas são usadas todos os dias e quais ninguém abre há anos — migrar o que ninguém usa é desperdício puro.

Etapa 2 — Mapear onde está a regra

Em sistemas Delphi, a regra de negócio raramente está num lugar só. O RAD incentivou, durante décadas, a escrever a lógica onde era mais rápido: no evento do componente. Os esconderijos típicos:

• Eventos de tela. OnClick de botões, OnExit de campos, OnChange de combos. É comum um botão "Gravar" com trezentas linhas de validação, cálculo e SQL.
• Eventos de dataset nos DataModules. BeforePost, AfterPost, OnCalcFields, OnNewRecord, OnValidate de campos. Regras importantes ficam aqui e são invisíveis para quem só olha as telas.
• Banco de dados. Triggers, stored procedures, generators e constraints — especialmente em Firebird/InterBase e SQL Server. Às vezes metade da regra está no banco e a outra metade na aplicação.
• Units utilitárias. Funções de cálculo de imposto, formatação de documento e arredondamento usadas por dezenas de telas.
• SQL montado em string. Consultas concatenadas em tempo de execução, com filtros condicionais que só aparecem em certos caminhos.

Um exemplo ilustrativo do padrão que encontramos com frequência:

procedure TFrmPedido.BtnGravarClick(Sender: TObject);
begin
  if (QryClienteTIPO.AsString = 'R') and (EdtDesconto.Value > 5) then
    EdtDesconto.Value := 5;   // revenda: desconto máximo 5%
  QryPedido.FieldByName('TOTAL').AsCurrency :=
    CalculaTotal(QryItens) * (1 - EdtDesconto.Value / 100);
  QryPedido.Post;
  ...
end;

A regra "revenda tem desconto máximo de 5%" não está em nenhum documento — está num if dentro do clique de um botão. Um conversor automático levaria esse if para o C# exatamente onde está; a migração bem feita o tira dali e o coloca numa camada de regra testável.

Etapa 3 — Documentar antes de reescrever

Com o inventário e o mapa da regra em mãos, a etapa seguinte é transformar o que foi lido em documentação que um humano consiga validar: regras de negócio escritas em linguagem de negócio, fluxos principais, cálculos com exemplos numéricos, integrações com formato de entrada e saída, e o dicionário de dados com o significado real de cada campo (inclusive os campos reaproveitados para outra finalidade).

Essa documentação é validada com quem opera o sistema — e é ela, não o código Pascal, que serve de especificação para o sistema novo. Ela também fica com a empresa, valendo mesmo que a tecnologia mude de novo daqui a dez anos. Detalhamos o método em como documentar um sistema legado sem documentação.

Etapa 4 — Decidir o destino

Só agora, com o sistema entendido, a pergunta "para onde vamos?" tem resposta honesta. Há três caminhos, e nenhum é certo para todo mundo.

Atualizar para um Delphi recente

O Delphi continua sendo vendido e atualizado pela Embarcadero, compila para Windows 64 bits e tem o FireDAC como camada de acesso a dados. Atualizar aproveita o código existente e a equipe que já conhece Pascal. Os custos estão na migração para Unicode, na troca do BDE, na substituição de componentes de terceiros sem versão nova e no licenciamento da ferramenta. O ponto fraco: se a regra continua dentro dos eventos de tela, você tem o mesmo sistema numa versão mais nova — o que pode ser exatamente o que precisa, ou não.

Reescrever em web ou .NET

É o que se costuma chamar de migração Delphi para web — ou, no caso mais comum, de Delphi 7 para .NET. Um sistema novo, por exemplo em C# com .NET e interface web, abre acesso pelo navegador e pelo celular, integrações por API, hospedagem em nuvem e um mercado de profissionais maior. Em troca, é o caminho de maior esforço inicial e o que mais depende da documentação da etapa anterior — sem ela, a reescrita esquece regras e a equipe descobre na produção. É viável quando feito por partes; é arriscado quando planejado como uma entrega única.

Híbrido

O Delphi segue em uso enquanto a regra de negócio migra para uma API nova, e as funcionalidades novas (portal do cliente, app do vendedor, painel gerencial) já nascem na tecnologia nova. Com o tempo, as telas Delphi vão sendo substituídas até o executável antigo ficar vazio. É o caminho mais comum na prática, porque permite começar com pouco risco — mas exige disciplina para não virar dois sistemas para manter para sempre.

Na página de migração Delphi descrevemos como conduzimos cada um desses caminhos.

Etapa 5 — Separar a regra numa API

Seja qual for o destino, o passo que mais reduz risco é tirar a regra de negócio das telas e colocá-la num lugar só, com testes. Na reescrita e no híbrido, esse lugar costuma ser uma API (em C# com ASP.NET Core, por exemplo) que passa a ser a dona das regras: calcular o pedido, validar o crédito, gerar o título.

No caminho híbrido, o próprio Delphi pode passar a chamar essa API em vez de executar a regra localmente. Mesmo um Delphi 7 consegue fazer requisições HTTP — com Indy, por exemplo —, embora HTTPS em versões antigas exija atenção com as bibliotecas de criptografia. Assim, a regra passa a existir uma vez só, e as telas Delphi e as telas novas usam a mesma.

Os testes automatizados dessa camada são escritos a partir da documentação da etapa 3: para este cliente, este pedido e este desconto, o total esperado é este. Quando os números batem com os do sistema antigo, a regra está migrada.

Etapa 6 — A primeira fatia

Escolha uma parte do sistema que seja relevante o bastante para provar o caminho e pequena o bastante para não pôr a operação em risco. Bons candidatos:

• Uma consulta ou relatório muito usado, que só lê dados.
• Um módulo periférico com poucas dependências — cadastro de fornecedores, agenda de entregas.
• Uma funcionalidade nova que o negócio está pedindo e que, de qualquer forma, teria de ser construída.

Imagine uma distribuidora com um ERP em Delphi 7 sobre Firebird. Em vez de começar pelo faturamento, ela começa pela consulta de pedidos para os vendedores externos: uma tela web, lendo o mesmo banco, sem alterar nada. Em poucas semanas os vendedores param de ligar para o escritório para saber se o pedido saiu, a equipe valida a arquitetura nova e ninguém arriscou a emissão de nota.

Etapa 7 — Dados

Se o banco é Paradox ou Access, a troca do banco quase sempre vem junto: são formatos de arquivo compartilhado, sensíveis a falhas de rede e a acesso simultâneo. Se é Firebird ou SQL Server, o banco pode continuar por um tempo e ser migrado depois — ou nunca, se estiver bem.

Os cuidados que mais aparecem em dados de sistemas Delphi:

• Codificação de texto. Dados gravados em ANSI (Windows-1252) que precisam virar UTF-8 sem corromper acentos.
• Datas e valores. Datas zeradas ou fictícias usadas como "sem data", valores monetários em ponto flutuante com arredondamento acumulado.
• Integridade. Bancos sem chave estrangeira, com registros órfãos que o sistema antigo tolerava e o novo vai recusar.
• Campos reaproveitados. A coluna OBS2 que, para um tipo de cliente, guarda o código do representante.

Migração de dados se ensaia: carga completa num ambiente de teste, conferência de totais e de amostras com quem usa, e repetição até bater. Tratamos o tema em detalhe em migração de banco de dados.

Etapa 8 — Convivência e desligamento

Durante a transição, o sistema novo e o Delphi convivem. Isso é planejado, não improvisado: quem é dono de cada dado em cada momento, como os dois se mantêm consistentes (banco compartilhado, sincronização ou API), e como cada usuário sabe em qual sistema fazer cada tarefa.

Cada fatia segue o mesmo ciclo: a parte nova entra em uso, roda em paralelo com conferência por um período, e a tela correspondente no Delphi é desativada. Se algo não bater, volta-se para a tela antiga enquanto se corrige — por isso cada etapa precisa ter caminho de volta.

O desligamento final é a última fatia, não um evento: quando o executável Delphi não tem mais nenhuma tela em uso, ele é arquivado junto com uma cópia somente leitura dos dados históricos que não foram migrados. Sem madrugada de virada.

E o conversor automático?

É a pergunta que mais ouvimos. Ferramentas que traduzem Delphi para C# linha a linha existem, e o resultado costuma ser o mesmo: a regra continua dentro do evento do botão, o SQL continua espalhado pela tela, e os componentes de terceiros viram adaptadores ou buracos. Você troca um legado em Pascal por um legado em C#, que ninguém escreveu e ninguém entende. Explicamos com mais detalhe em conversor automático de código legado funciona?

Checklist para migrar um sistema Delphi

• Versão do Delphi identificada e código-fonte conferido com o executável em produção.
• Lista de componentes de terceiros, com situação do fornecedor e disponibilidade de fonte.
• Banco de dados e camada de acesso (BDE, dbExpress, ADO, IBX, FireDAC) mapeados.
• Relatórios contados e classificados por uso real.
• DLLs, integrações, arquivos trocados e tarefas agendadas listados.
• Regras localizadas em telas, DataModules, units e banco (triggers e procedures).
• Documentação de regras, cálculos e dados validada por quem opera.
• Destino escolhido — atualizar, reescrever ou híbrido — com os motivos registrados.
• Regra de negócio separada numa camada própria, com testes baseados na documentação.
• Primeira fatia definida, pequena e com caminho de volta.
• Migração de dados ensaiada e conferida antes de cada entrada em produção.
• Plano de convivência e critério de desligamento de cada tela antiga.

Perguntas frequentes

Conclusão

Migrar um sistema Delphi é menos uma questão de linguagem e mais uma questão de conhecimento. Quem sabe o que o sistema faz — porque inventariou, mapeou a regra e documentou — consegue escolher o destino com calma e migrar por partes, com a empresa funcionando. Quem pula essas etapas troca de tecnologia e perde regras no caminho.

A NasteSoft e seus parceiros já migraram bancos de dados e aplicações em Delphi, VB6 e .NET. Se o seu sistema está chegando no limite, a conversa começa pelo inventário.