Para quien haya pasado por ello: ¿alguna vez migrasteis un sistema Visual FoxPro de tablas DBF a un motor de base de datos real (MySQL, SQL Server, PostgreSQL)?

Los DBF tienen limitaciones conocidas que se notan más cuanto más crece el sistema: sin un motor transaccional real detrás (la integridad depende mucho de la disciplina del propio código VFP, no de garantías del motor), acceso concurrente limitado cuando varios usuarios escriben a la vez, y sin las herramientas de administración, backup en caliente o replicación que dan por sentadas los motores de base de datos modernos.

Lo que me interesa saber de quien lo haya hecho de verdad:

¿Migrasteis solo los datos (dejando la interfaz VFP tal cual, conectada ahora a MySQL/SQL Server vía ODBC) o reescribisteis también la aplicación entera a otro lenguaje de una vez?

¿Qué problemas concretos os disteis al pasar de la lógica DBF (donde muchísimo se resuelve con comandos nativos tipo SEEK, índices .CDX, relaciones expresadas en el propio código) a SQL estándar?

¿Compensó el esfuerzo, o os arrepentisteis a mitad de camino?

Cristina

Mi experiencia con esto (no en Visual FoxPro exactamente, pero sí con migraciones parecidas de ficheros planos/DBF a un motor relacional real) es que casi siempre compensa hacerlo de forma incremental, no de golpe: primero conectar la interfaz VFP existente contra el nuevo motor vía ODBC, manteniendo toda la lógica de negocio tal cual, y validar que el comportamiento es equivalente antes de plantearte tocar nada de la capa de aplicación.

Lo que más sorprende a quien no lo ha hecho antes son las diferencias de comportamiento "invisibles" que no aparecen hasta que las pruebas reales las sacan a la luz: coerción de tipos implícita que VFP hace sola y que SQL estándar no hace igual, tratamiento de NULL distinto (VFP tiene su propia forma de gestionar valores vacíos que no siempre mapea uno a uno con NULL SQL), y sobre todo el modelo de bloqueo: DBF usa bloqueo pesimista de registro/fichero a bajo nivel, mientras que un motor SQL moderno normalmente trabaja con bloqueo optimista o niveles de aislamiento configurables, así que código que dependía del comportamiento de bloqueo de DBF puede comportarse de forma sutilmente distinta bajo carga concurrente real.

¿Mereció la pena? En los casos que he visto, sí, pero sobre todo cuando había una necesidad real de crecimiento (más usuarios concurrentes, necesidad de reporting más potente que lo que DBF permite cómodamente). Para un sistema pequeño de un solo usuario que funciona bien tal cual, el riesgo de la migración probablemente no se justifica solo por "modernizar".

Alvaro