Migre o HFSQL como um programa próprio — não como um detalhe secundário da reescrita.
A modernização da aplicação e a modernização dos dados estão conectadas, mas não precisam acontecer no mesmo momento. Trate o banco de dados como um programa controlado, com seu próprio inventário, sua própria escolha de destino e seu próprio teste de aceitação — e a reescrita fica mais fácil de confiar.
Por que não migrar os dois de uma vez
- Todo defeito vira ambíguo. Mova a aplicação e o banco juntos, e uma tela quebrada pode ser código convertido, semântica SQL, transformação de dados ou infraestrutura — você não vai saber qual.
- O sistema legado precisa de um chão firme. Converta o schema 1:1 primeiro, e sua aplicação WinDev legada continua rodando sobre os mesmos dados enquanto a reescrita avança.
- A reconciliação precisa de um alvo estável. Você não consegue provar que contagens de linhas e totais de controle batem se o schema também está mudando de forma por baixo.
- O banco de dados de destino é uma decisão separada. PostgreSQL, SQL Server ou MySQL devem ser escolhidos pelo que o produto vai precisar depois — não pelo mapeamento mais fácil de automatizar.
O que inventariar antes de tocar em uma única coluna
- Tabelas, chaves e restrições. A espinha dorsal estrutural, capturada antes de qualquer reescrita.
- Consultas embutidas em telas, relatórios e procedimentos. Lógica de HFSQL que nunca viveu em um único lugar óbvio.
- Procedures armazenadas e triggers. Comportamento do lado do servidor que precisa ser contabilizado, não só o schema.
- Blobs, suposições de sistema de arquivos e precisão numérica. Anexos, conjuntos de caracteres, datas e tratamento de nulos — os detalhes que quebram a reconciliação mais tarde.
- Concorrência e comportamento transacional. Como o HFSQL realmente lida com bloqueio hoje, para que o banco de destino possa ser configurado da mesma forma.
Escolhendo o banco de dados de destino
PostgreSQL
Uma stack aberta com fortes capacidades SQL — o padrão quando não há motivo para permanecer centrado em Microsoft.
SQL Server
Um encaixe natural para organizações já padronizadas em infraestrutura e licenciamento Microsoft.
MySQL
Prático para produtos web amplamente hospedados, onde o ecossistema já espera por ele.
A escolha deve vir do que o produto vai precisar depois, não do conversor com o mapeamento de tipos mais fácil.
Reconciliação é o teste de aceitação
O que é verificado: Contagens de linhas, totais de chaves, totais de controle quando aplicáveis, relacionamentos órfãos, comportamento de nulos e precisão, e resultados de consultas representativas — contra a carga de trabalho real, não inserções sintéticas.
Como os marcos fazem a virada: Os marcos da aplicação migrada continuam usando o contrato de dados estabelecido enquanto a nova persistência é preparada, e então um domínio delimitado faz a virada — com seu sistema legado continuando a rodar sobre os mesmos dados enquanto for preciso.
As perguntas que os desenvolvedores fazem primeiro
Não — o schema é convertido 1:1 primeiro justamente para que seu sistema legado continue rodando sem mudanças enquanto a migração da aplicação segue seu próprio cronograma.
Você, com base no que o produto vai precisar depois. O WXCode não impõe um padrão para simplificar a própria conversão.
Por reconciliação de contagens de linhas, totais de controle e resultados de consultas representativas — as mesmas verificações que um programa de dados controlado usa, não uma amostragem qualquer.
Guias relacionados
Teste no seu projeto real.
Comece pela base de conhecimento, as dependências e as regras de negócio — antes de se comprometer com uma reescrita.