Migrar Delphi para web
O que entregamos, como funciona e o que isso traz para a operação.
ARTIGO · MIGRAÇÃO
Migrar Delphi para web: caminhos, riscos e como não parar o sistema
Sistema em Delphi costuma ser o que a empresa mais depende e o que menos gente sabe manter. Este texto compara os caminhos reais de migração, aponta onde cada um falha e descreve o método que mantém a operação no ar durante a troca.
Por que o assunto chega agora
Raramente é o Delphi em si. São três pressões que chegam juntas.
A base técnica saiu de suporte. Na tabela oficial de versões suportadas da Embarcadero, as versões anteriores já constam fora de suporte. Um sistema construído sobre versão sem suporte não recebe correção quando uma falha nova aparece.
O acesso a dados é de outra era. Muitos sistemas em Delphi ainda usam o BDE, cuja documentação do próprio fabricante o trata como tecnologia legada. Ele funciona, mas amarra o sistema a configuração de estação, a driver antigo e a comportamento que ninguém mais mantém.
Texto quebra. A mudança para Unicode no Delphi alterou o tipo de string. Sistemas escritos antes disso costumam ter tratamento de texto que se comporta de forma diferente quando compilado em versão nova — e isso aparece justamente em nome de cliente, endereço e campo com acento.
Some a isso o que não é técnico: quem escreveu o sistema saiu, e a regra de negócio está no código, não em documento.
Os quatro caminhos, e onde cada um falha
| Caminho | O que é | Onde falha |
|---|---|---|
| Reescrever do zero | Novo sistema, nova base, virada em data marcada | A especificação verdadeira é o comportamento atual, e ninguém a conhece por inteiro. A virada única concentra todo o risco em um dia |
| Publicar a tela em servidor remoto | O mesmo executável, acessado à distância | Resolve o acesso, não o legado. A base técnica continua sem suporte e o custo de licença e infraestrutura entra no lugar |
| Recompilar em Delphi novo com camada web | Manter a linguagem e expor a interface na web | Depende do tamanho do acoplamento entre regra e tela. Onde a regra está dentro do evento do botão, a camada web vira outro sistema |
| Reengenharia por partes | Um módulo por vez, com a regra extraída e reescrita sobre base em suporte, com o legado no ar | Exige disciplina de comparação e prazo maior até o fim. Em troca, nunca existe o dia da virada |
Não há caminho universalmente certo. O que decide é quanto da regra de negócio está separada da interface — e isso é medível antes de escolher, no diagnóstico.
O que costuma dar errado, na ordem em que aparece
- Regra escondida no evento da tela. Validação que só existe dentro do OnClick de um botão. Se a migração recria a tela sem extrair essa regra, o comportamento muda sem ninguém perceber.
- Relatório. Quase sempre subestimado. Há relatório que a empresa usa para fechamento fiscal e que ninguém lembrou de listar no escopo.
- Integração por arquivo. Sistema em Delphi costuma conversar com outros por exportação em pasta de rede. Migrar sem mapear essas trocas quebra o que estava fora do escopo.
- Impressão e periférico. Impressora fiscal, balança, leitor, etiqueta. Na web, cada um desses vira uma decisão de arquitetura.
- Texto e acento. A mudança de tipo de string aparece em comparação, ordenação e tamanho de campo — e o sintoma é sutil.
- Dado histórico. Base antiga tem registro que o sistema novo considera inválido. Migrar sem conferir gera relatório que não fecha com o do ano anterior.
O método que mantém o sistema no ar
É o mesmo desenho que usamos para qualquer legado crítico. A etapa três é o que diferencia de uma reescrita convencional.
Diagnóstico técnico
Inventário de telas, relatórios, integrações e periféricos. Onde a regra de negócio está de fato, e o que não pode parar em hipótese alguma.
Reengenharia por partes
Um módulo por vez. A regra é extraída do código atual e reescrita sobre base técnica em suporte, mantendo o banco de dados enquanto fizer sentido.
Execução em paralelo
O módulo novo e o legado processam a mesma requisição e as respostas são comparadas. A divergência aparece antes de qualquer usuário ver — é isso que transforma “achamos que está igual” em evidência.
Promoção gradual do tráfego
O percentual de uso migra por etapas, com retorno imediato ao legado se algum indicador sair do padrão. O retorno faz parte do desenho, não é plano de emergência.
Entrega com autonomia
Código, documentação e transferência de conhecimento para quem vai manter.
A pergunta que costuma vir aqui é sobre prazo: por que não fazer tudo de uma vez, se seria mais rápido? Porque o risco não é linear. A virada única transfere para um único dia todo o risco acumulado de meses de trabalho — e é nesse dia que se descobre a regra que ninguém documentou.
O que decidir antes de começar
Três decisões que mudam o desenho inteiro e devem estar tomadas na primeira semana.
O banco de dados migra junto? Manter o banco no início reduz muito o risco: o módulo novo lê e escreve na mesma base, e a comparação em paralelo fica direta. Migrar banco e aplicação ao mesmo tempo dobra as variáveis.
O que vira web e o que continua desktop? Nem tudo precisa virar web. Estação de produção com periférico dedicado às vezes continua fazendo mais sentido como aplicação local.
Qual módulo primeiro? Não o mais crítico e não o mais fácil. O que tem regra bem delimitada e uso frequente — porque dá evidência de comparação rápido e ensina o time sobre o sistema antes que o risco suba.
Continue por aqui
O que é um sistema legado
A definição, os cinco sinais e quando modernizar não vale.
Obsolescência tecnológica
O risco que não aparece no orçamento, e a triagem de três perguntas.
Um diagnóstico do seu sistema em Delphi
Trinta minutos para mapear telas, relatórios, integrações e onde a regra de negócio realmente está.
Respondemos em até 1 hora útil. Confirmação no mesmo dia útil.