Una migración puede terminar con el mismo número de filas en origen y destino y seguir siendo incorrecta.
Los datos de un sistema de negocio no son sólo valores almacenados. También contienen estados, relaciones, unidades, fechas, excepciones y reglas que determinan qué significa realmente cada información.
Cuando cambia el modelo de datos, la base de datos o la aplicación que interpreta esos valores, parte de ese significado puede alterarse aunque técnicamente todos los registros se hayan copiado.
Por eso migrar datos no consiste simplemente en exportarlos de un sistema e importarlos en otro. Hay que entender qué representan, decidir cómo deben transformarse y comprobar que siguen teniendo sentido después del cambio.
Los datos significan más de lo que vemos
Un campo status = 4 no nos dice por sí solo si un pedido está facturado, enviado o pendiente de algún proceso interno.
Un campo vacío puede significar desconocido, no aplica o todavía no calculado. Una fecha puede representar la hora del usuario, del almacén o del servidor.
Parte de esta información está definida en la propia base de datos mediante relaciones y restricciones. Pero otra parte suele estar en el código, informes, procesos automáticos, integraciones o incluso en la forma habitual de trabajar de la empresa.
Antes de diseñar una migración conviene responder algunas preguntas:
- ¿Qué representa realmente cada registro?
- ¿Cómo identificamos de forma estable cada entidad?
- ¿Qué datos son originales y cuáles se calculan?
- ¿Qué estados existen y cómo se pasa de uno a otro?
- ¿Hay información histórica que ya no cumple las reglas actuales?
- ¿Qué otros sistemas dependen de identificadores o estructuras internas?
- ¿Qué información debe conservarse, anonimizarse o descartarse?
Si todavía no podemos responder estas preguntas, la correspondencia entre el sistema antiguo y el nuevo sigue siendo una hipótesis.
Migrar es transformar, no copiar
Una buena migración debería poder repetirse obteniendo resultados previsibles.
No debería depender de una serie de pasos manuales que sólo conoce la persona que escribió el script.
El diseño debe dejar claro:
- cómo se corresponde la información de origen con la de destino;
- qué reglas de limpieza o transformación se aplican;
- cómo se mantienen los identificadores y relaciones;
- qué ocurre con duplicados o registros incorrectos;
- de dónde proceden los valores calculados;
- qué versión de los scripts y configuraciones se utiliza;
- qué errores aparecen y cómo se resuelven.
Siempre que sea posible, partiendo de los mismos datos y de la misma configuración deberíamos obtener el mismo resultado.
También debemos decidir qué hacer con las excepciones.
Un registro que incumple una regla del sistema nuevo puede corregirse, separarse temporalmente para revisarlo, migrarse como una excepción conocida o dejarse fuera.
Lo importante es que esa decisión sea explícita y quede registrada.
El equipo técnico puede encontrar anomalías y automatizar tratamientos previamente acordados. Lo que no debería hacer es decidir por su cuenta qué significa un NIF incorrecto, un saldo incoherente o un estado de negocio imposible.
Hay decisiones que necesitan a alguien que conozca el negocio.
Esto también afecta al rendimiento. Una migración puede estar bien diseñada y ser inviable si tarda más de lo permitido. Por eso conviene probarla con un volumen de datos representativo y medir el proceso completo, no extrapolar los tiempos a partir de una pequeña muestra.
Cómo sabemos que la migración es correcta
Comparar el número de registros entre los dos sistemas es útil, pero no suficiente.
Podemos tener exactamente el mismo número de pedidos y haberlos asociado al cliente incorrecto. Podemos mantener todas las facturas y haber alterado importes durante un redondeo. Podemos copiar todos los registros y perder relaciones importantes entre ellos.
Las mejores prácticas contrastadas desde distintos referentes en esta área recomiendan definir la estrategia de validación antes de ejecutar la migración y automatizar tantas comprobaciones como sea razonable.
Podemos comprobar el resultado en varios niveles:
- Integridad técnica. Tipos de datos, campos obligatorios, claves, relaciones y restricciones.
- Comparación cuantitativa. Cantidades y totales por periodos, estados, clientes o unidades de negocio.
- Reglas que siempre deben cumplirse. Por ejemplo, saldos, identificadores únicos o conservación de determinados totales.
- Casos reales de negocio. Operaciones completas con situaciones normales y excepciones conocidas.
- Sistemas que utilizan los datos. APIs, informes, procesos automáticos e integraciones deben interpretar correctamente el nuevo modelo.
- Funcionamiento operativo. Tiempos, capacidad, monitorización, copias de seguridad y recuperación.
No todos los errores tienen la misma importancia.
En determinados datos puede aceptarse una diferencia conocida y controlada. En otros, como información contable, identificadores o datos que necesitan trazabilidad, una única discrepancia puede ser suficiente para detener el cambio.
El criterio de aceptación debe depender del riesgo y del significado de la información, no de un porcentaje genérico.
El momento del cambio: quién controla los datos
Durante algunas migraciones el sistema antiguo y el nuevo funcionan al mismo tiempo.
En ese momento aparece una pregunta fundamental: ¿qué sistema contiene la versión válida de cada dato?
La opción más sencilla es detener temporalmente las modificaciones, migrar, comprobar el resultado y activar el nuevo sistema. Facilita mantener la coherencia, pero requiere una ventana de parada.
También podemos mantener ambos sistemas sincronizados para reducir esa interrupción. El problema es que entonces aparecen retrasos, cambios que llegan fuera de orden y posibles errores durante la sincronización.
Otra posibilidad es que una misma operación se guarde en los dos sistemas. Es lo que suele llamarse doble escritura.
Sobre el papel parece sencillo. La dificultad aparece cuando la operación funciona en un sistema y falla en el otro. Si no existe una forma de detectar y corregir esa diferencia, terminamos con dos versiones distintas de la realidad.
No hay una solución universal. La elección depende de cuánto tiempo puede detenerse el servicio, cuánto cambian los datos, qué nivel de consistencia necesitamos y lo difícil que sería volver atrás.
Volver atrás no siempre significa lo mismo
Antes de que el nuevo sistema reciba operaciones reales, volver al anterior puede ser relativamente sencillo.
Después de la puesta en producción, la situación cambia.
Si el sistema nuevo ya ha recibido pedidos, pagos, modificaciones u otras operaciones que el anterior desconoce, volver atrás deja de consistir simplemente en redirigir a los usuarios.
Hay que decidir qué ocurre con esas nuevas transacciones.
Por eso el cambio definitivo debería seguir una guía operativa, también conocida como runbook, que indique qué debe hacerse, quién toma las decisiones y en qué momento se puede continuar o volver atrás.
Esta guía debería definir al menos:
- cuándo se detienen o redirigen las operaciones;
- qué copia de seguridad se utilizará;
- cómo se realiza la última sincronización;
- qué comprobaciones permiten continuar;
- quién decide seguir adelante o detener el proceso;
- qué ocurre con tareas automáticas e integraciones;
- cómo se comunica la intervención a los usuarios;
- qué se monitoriza después del cambio.
El momento en que el nuevo sistema pasa a ser el sistema principal suele denominarse cutover. Podemos entenderlo simplemente como el cambio definitivo de autoridad entre el sistema antiguo y el nuevo.
Estas decisiones deben ensayarse antes de la migración real. No deberían descubrirse durante una incidencia.
Qué hacemos con el sistema anterior
Una migración tampoco termina necesariamente cuando el nuevo sistema entra en funcionamiento.
Mantener indefinidamente el anterior por si acaso tiene un coste. Hay que seguir manteniéndolo y protegiéndolo y, además, puede generar dudas sobre cuál de los dos sistemas contiene la información correcta.
Pero retirarlo demasiado pronto también puede eliminar información necesaria para auditorías, consultas históricas o recuperación.
No todo el histórico tiene que trasladarse al nuevo sistema operativo.
Antes conviene clasificar la información:
- datos que siguen activos;
- información histórica que debe poder consultarse;
- datos que deben conservarse durante un periodo determinado;
- información que puede eliminarse según la política establecida.
Parte del histórico puede permanecer en un archivo o temporalmente en una copia de sólo lectura del sistema antiguo.
Lo importante es que siga siendo accesible cuando sea necesario, mantenga su significado y tenga unas reglas claras de conservación y borrado.
Antes de retirar definitivamente el sistema anterior deberíamos haber superado un periodo de estabilización, comprobado los datos, trasladado los sistemas que todavía dependían de él y verificado las copias y procedimientos de recuperación.
Sólo entonces podemos decidir qué conservar y qué eliminar.
Conclusión
Mover datos de un sistema a otro es sólo una parte de una migración.
El objetivo real es que la información siga significando lo mismo después del cambio.
Eso implica entender los datos antes de moverlos, definir cómo se transforman, comprobar el resultado y saber qué ocurrirá mientras los dos sistemas conviven o si algo falla durante la transición.
Por eso la migración debe estudiarse desde el principio de una modernización y no dejarse como una tarea para el final.
Si se hace demasiado tarde, es fácil descubrir que el nuevo software depende de reglas, relaciones e historia que nunca estuvieron únicamente dentro de las tablas de la base de datos.
Si la migración forma parte de una transición más amplia, consulta nuestro enfoque de modernización. El caso Condis muestra de forma acotada una migración diseñada como un proceso repetible, verificable y trazable. Cuando los datos y sus dependencias todavía pueden cambiar de forma importante la estrategia del proyecto, un estudio técnico previo permite investigar esa incertidumbre antes de asumir el compromiso.
