Migra HFSQL como su propio programa — no como un añadido a la reescritura.
La modernización de la aplicación y la modernización de los datos están conectadas, pero no tienen que ocurrir en el mismo momento. Trata la base de datos como un programa controlado con su propio inventario, su propia elección de destino y su propia prueba de aceptación, y la reescritura se vuelve más fácil de confiar.
Por qué no migrar ambas cosas a la vez
- Cada defecto se vuelve ambiguo. Mueve la aplicación y la base juntas, y una pantalla rota puede deberse al código convertido, la semántica SQL, la transformación de datos o la infraestructura — no sabrás cuál.
- El sistema legado necesita un suelo firme. Convierte primero el esquema 1:1, y tu aplicación WinDev legada sigue funcionando sobre los mismos datos mientras avanza la reescritura.
- La reconciliación necesita un objetivo estable. No puedes demostrar que coinciden los conteos de filas y los totales de control si el esquema también está cambiando de forma por debajo.
- La base de datos destino es una decisión aparte. PostgreSQL, SQL Server o MySQL deben elegirse según lo que el producto necesite después — no según qué mapeo fue más fácil de automatizar.
Qué inventariar antes de tocar una sola columna
- Tablas, claves y restricciones. El esqueleto estructural, capturado antes de reescribir nada.
- Consultas incrustadas en pantallas, informes y procedimientos. Lógica de HFSQL que nunca vivió en un solo lugar evidente.
- Procedimientos almacenados y disparadores. Comportamiento del lado del servidor que hay que tener en cuenta, no solo el esquema.
- Blobs, supuestos de sistema de archivos y precisión numérica. Adjuntos, juegos de caracteres, fechas y manejo de nulos — los detalles que rompen la reconciliación más adelante.
- Concurrencia y comportamiento transaccional. Cómo maneja HFSQL el bloqueo hoy en la práctica, para poder configurar la base destino de forma equivalente.
Eligiendo la base de datos destino
PostgreSQL
Una stack abierta con fuertes capacidades SQL — la opción por defecto cuando no hay razón para seguir centrado en Microsoft.
SQL Server
Un encaje natural para organizaciones ya estandarizadas en infraestructura y licencias de Microsoft.
MySQL
Práctico para productos web ampliamente hospedados, donde el ecosistema ya lo espera.
La elección debe venir de lo que el producto necesite después, no del convertidor con el mapeo de tipos más fácil.
La reconciliación es la prueba de aceptación
Qué se verifica: Conteos de filas, totales de claves, totales de control donde apliquen, relaciones huérfanas, comportamiento de nulos y precisión, y resultados de consultas representativas — contra la carga de trabajo real, no inserciones sintéticas.
Cómo hacen el corte los hitos: Los hitos de la aplicación migrada siguen usando el contrato de datos establecido mientras se prepara la nueva persistencia, y luego un dominio delimitado hace el corte — con tu sistema legado siempre funcionando sobre los mismos datos hasta que ya no lo necesite.
Las preguntas que hacen primero los desarrolladores
No — el esquema se convierte 1:1 primero, precisamente para que tu sistema legado siga funcionando sin cambios mientras la migración de la aplicación avanza en su propio calendario.
Tú, según lo que el producto necesite después. WXCode no impone una opción por defecto para simplificar su propia conversión.
Mediante reconciliación de conteos de filas, totales de control y resultados de consultas representativas — las mismas verificaciones que usa un programa de datos controlado, no un muestreo al azar.
Guías relacionadas
Pruébalo en tu proyecto real.
Empieza por la base de conocimiento, las dependencias y las reglas de negocio — antes de comprometerte con una reescritura.