Como migrar Visual FoxPro para web sem parar a operação

## Por que isso é tão difícil Visual FoxPro deixou de ser suportado pela Microsoft em 2015. Não há novas versões, não há patches de segurança, não há driver de banco para sistemas operacionais modernos. E, ainda assim, milhares de empresas brasileiras rodam operação crítica em VFP — porque o sistema funciona, porque o conhecimento de quem fez se perdeu, porque trocar parece arriscado demais. O problema não é técnico. É de **continuidade de operação**. Estacionamento, distribuidora, gráfica, indústria de médio porte. Para essas empresas, qualquer parada de mais de uma hora gera prejuízo direto que pode ser maior que o custo da própria migração. Este post descreve a estratégia que aplicamos no case **Prossiga** (gestão de estacionamento) e em projetos similares. **Resultado entregue: zero parada de receita durante a migração.** ## A regra de ouro: nunca migre de uma vez A tentação é grande: agendar fim de semana, virar o sistema, voltar segunda com o novo. **Isso falha em 7 de cada 10 casos.** Os motivos: - Dados reais sempre têm casos que o teste não cobriu - Regra de negócio escrita no VFP original tem detalhe esquecido - Treinamento da equipe não acompanha o ritmo do projeto - Stress de "tudo ou nada" leva a decisão precipitada em hora errada A abordagem correta é **migração em paralelo com corte cirúrgico**. Os dois sistemas (antigo VFP e novo web) rodam ao mesmo tempo, com replicação contínua, durante semanas. O corte final acontece num momento controlado, quando todo mundo já está confortável com o novo. ## As 5 fases do projeto (em ordem) ### Fase 1: Engenharia reversa do schema DBF Visual FoxPro guarda dados em arquivos .DBF. Não há documentação na maioria dos sistemas legados. Primeira ação: extrair o schema completo lendo os arquivos diretamente. Ferramentas que usamos: - **dbfread (Python)** — leitura programática dos arquivos DBF - **pandas** — análise exploratória dos dados - **DBML** — linguagem para documentar o schema resultante O entregável dessa fase é um **diagrama ER** moderno (em geral 30-80 tabelas para sistemas reais) e um **DBML completo** com chaves estrangeiras, tipos de dados e cardinalidades. Isso vira a base para o banco novo. ### Fase 2: Modelagem do banco novo Não copie o schema DBF tal como está. Use a oportunidade para: - **Normalizar** o que estava desnormalizado por limitação do VFP - **Tipar corretamente** (DBF tem tipos limitados; PostgreSQL aceita JSONB, arrays, ENUMs) - **Adicionar constraints** que faltavam (CHECK, FOREIGN KEY, UNIQUE) - **Pensar em multi-tenant** se for o caso (RLS no PostgreSQL/Supabase) No case Prossiga, o esquema final teve menos tabelas que o DBF original (consolidamos algumas tabelas redundantes) mas com modelagem muito mais sólida. ### Fase 3: Pipeline de migração de dados com checksum Aqui está o coração da operação sem parada. O pipeline tem três passos: 1. **Snapshot inicial** — primeira carga completa do DBF para o PostgreSQL novo 2. **Replicação contínua** — script que roda a cada 5 minutos, copiando deltas (registros novos e alterados) do DBF para o novo 3. **Validação por checksum** — para cada tabela, calculamos checksum dos dados em ambos os lados. Se divergir, alerta. A replicação contínua mantém os dois sistemas sincronizados durante todo o período de transição. A validação por checksum garante que ninguém migra dados corrompidos. ### Fase 4: Operação dual com cutover programado Durante 2 a 4 semanas, ambos os sistemas estão no ar: - **VFP** continua sendo o sistema "de verdade" (faz o trabalho) - **Web novo** está disponível para uso paralelo (consulta, validação, testes) A equipe usa os dois, compara resultados, aprende o novo. Bugs encontrados são corrigidos com o sistema antigo ainda rodando como rede de segurança. O **cutover** é um momento agendado — geralmente fim de semana, durante baixa atividade — em que três coisas acontecem em sequência rápida: 1. Pare o VFP (impede novos lançamentos) 2. Rode última replicação delta 3. Valide checksum final em todas as tabelas críticas 4. Aponte o time para o sistema web 5. VFP fica em modo leitura por 90 dias (consulta histórica, sem novos lançamentos) ### Fase 5: Plano de rollback **Sempre tenha plano de rollback.** Se algo der errado no cutover, você precisa voltar ao VFP em até 30 minutos. O plano é simples: - VFP fica congelado, mas funcional, durante o cutover - Se algo crítico falhar no novo nas primeiras 24-48h, redirecione a equipe de volta - Sistema web fica em "modo congelado" enquanto se investiga - Sem cobrar orgulho — voltar e seguir é sempre melhor que ir adiante quebrado Nunca precisamos usar o rollback em projetos que aplicamos essa metodologia. Mas o fato de existir muda a tensão do dia do cutover. ## Stack típica Para projetos de migração de VFP que rodamos: - **Python + pandas + dbfread** — extração e ETL - **PostgreSQL** (direto ou via Supabase) — banco novo - **DBML** — documentação de schema - **Next.js + React** — frontend web - **FastAPI ou Laravel** — backend - **Docker + Traefik** — infraestrutura - **Veeam ou rsync** — backup do VFP antes do cutover ## Quanto tempo leva Para um sistema VFP de porte médio (40-80 tabelas, 5-10 GB de dados, 5-15 anos de histórico): - Engenharia reversa: 2-4 semanas - Modelagem nova: 2-3 semanas - Pipeline de migração: 3-5 semanas - Operação dual: 2-4 semanas - Cutover e estabilização: 1-2 semanas **Total: 3 a 4 meses.** Sistemas maiores ou mais complexos podem chegar a 6 meses. Sistemas que já são reescrita completa (com regras de negócio novas) levam mais. ## O que não fazer - **Não use ChatGPT para gerar o schema novo a partir do DBF.** O modelo não vê os dados reais e inventa relações. - **Não confie em "exportar para Excel"** como ponte. Excel perde tipo de dado, encoding, e arquivos grandes corrompem. - **Não migre só metade do sistema.** Você acaba com duas verdades simultâneas e ninguém sabe qual é a boa. - **Não terceirize só a TI sem envolver a operação.** Sem o usuário final usando o sistema durante a fase dual, você sai do cutover descobrindo que nada funciona na prática. ## Quando faz sentido Migrar de Visual FoxPro vale o investimento quando você tem pelo menos um destes três sintomas: 1. **Sistema trava em horários de pico** — sintoma de banco DBF com limite de concorrência 2. **Auditoria ou compliance pediu controle que o VFP não tem** — LGPD, ISO, banco financiador 3. **A equipe que mantinha o sistema saiu ou está saindo** — conhecimento congelado é bomba relógio Se nenhum desses sintomas existe e o VFP roda em paz, talvez ainda não seja o momento. Mas você está atrasado: o Windows 11 e o Windows Server 2022 vão começar a ter problemas com VFP em breve. ## Conclusão Migrar Visual FoxPro para web é projeto de engenharia, não de marketing. Tem método, tem risco, tem prazo. Quem promete "migração relâmpago em 30 dias" está vendendo problema futuro. Se você está nessa situação, agende uma conversa. Mostramos o método em detalhe, sem custo de avaliação.