Un plan de migración de datos entre sistemas no consiste en exportar tablas, adaptar columnas e importar registros. El cambio afecta al significado de la información, a sus relaciones, a los permisos que permiten usarla y a los procesos que dependen de ella. Una importación puede terminar sin errores técnicos y, aun así, dejar pedidos sin líneas, usuarios con acceso indebido, importes inconsistentes o flujos bloqueados por estados que el sistema nuevo interpreta de otro modo.
La migración debe tratarse como una transición operativa verificable. El objetivo no es que los datos “estén” en destino, sino que las personas y los sistemas puedan continuar el trabajo con información completa, coherente, trazable y segura. Esto exige definir el alcance, ensayar con datos controlados, conciliar resultados, limitar la convivencia entre plataformas y disponer de una reversión que proteja la actividad y los datos creados durante el cambio.
Por qué fallan las migraciones que parecen correctas
Los recuentos totales suelen ser el primer control: si hay 10.000 clientes en origen y 10.000 en destino, el resultado parece satisfactorio. Pero ese control no demuestra que cada cliente tenga los campos adecuados, que sus contactos estén vinculados, que sus permisos sean correctos ni que sus operaciones históricas puedan consultarse.
Los fallos habituales se producen por diferencias semánticas y operativas:
- Un campo de texto libre en origen se convierte en una lista cerrada en destino y algunos valores quedan sin equivalencia.
- Un mismo estado representa fases distintas según el sistema, por ejemplo, cerrado puede significar completado, cancelado o archivado.
- Las relaciones se rompen porque se generan identificadores nuevos sin mantener una correspondencia fiable.
- Los adjuntos no se trasladan, se duplican o pierden permisos de acceso.
- Las reglas de negocio del destino rechazan datos históricos válidos, como fechas incompletas o registros desactivados.
- Los usuarios validan pantallas principales, pero no los flujos reales de creación, modificación, aprobación, facturación o atención.
La calidad de una migración se mide por la continuidad de los procesos críticos, no solo por el éxito de una tarea de importación.
Definir alcance e inventario antes de transformar
El primer entregable debe ser un alcance explícito. Para cada entidad, decida si se migra todo el histórico, solo un periodo, los registros activos o una combinación. Incluya entidades principales y dependientes: clientes, productos, pedidos, incidencias, usuarios, documentos, catálogos, configuraciones y registros de auditoría cuando sean necesarios para operar o cumplir obligaciones internas.
También hay que declarar qué no se migra. Puede ser más adecuado archivar eventos muy antiguos, excluir duplicados resueltos, mantener adjuntos en un repositorio de consulta o dejar una aplicación anterior accesible en modo lectura durante un periodo limitado. Excluir información no significa perderla: defina dónde se conservará, quién podrá consultarla y durante cuánto tiempo.
Construya un inventario de origen y destino por cada conjunto de datos. Debe recoger, como mínimo:
- Nombre técnico y significado de cada campo.
- Formato, obligatoriedad, valores permitidos y reglas de validación.
- Identificador de negocio e identificador técnico.
- Relaciones, cardinalidad y orden de carga necesario.
- Estado del dato: activo, histórico, anulado, bloqueado o pendiente.
- Propietario funcional que decide las reglas y aprueba excepciones.
- Transformación prevista, incluyendo valores por defecto y normalizaciones.
Una matriz de correspondencia convierte estas decisiones en un artefacto revisable. Por ejemplo, un estado pendiente_revision puede pasar a en_validacion; si no hay equivalencia, debe definirse si se crea un estado nuevo, se deriva a una cola manual o se excluye con justificación. No conviene resolver esta clase de decisiones dentro del script de migración sin validación del responsable del proceso.
Preservar trazabilidad, relaciones y excepciones
Siempre que sea posible, conserve los identificadores estables que utilizan otros procesos, informes o integraciones. Si el destino exige claves nuevas, cree una tabla de correspondencia entre el identificador de origen y el de destino. Esta tabla es esencial para reconstruir relaciones, investigar incidencias, sincronizar temporalmente y revertir decisiones.
La trazabilidad debe incluir un registro de ejecución con versión del extracto, reglas aplicadas, fecha, responsable, número de registros leídos, aceptados, rechazados y transformados. Los rechazos no son un detalle técnico: clasifíquelos por causa, impacto y tratamiento. Un correo mal formado puede requerir corrección o exclusión; una factura sin cliente asociado puede impedir el avance si afecta a un flujo financiero crítico.
Defina además un mecanismo para evitar duplicados si se repite la carga. Una operación idempotente identifica si un registro ya fue procesado y actualiza o ignora según una regla conocida, en vez de crear una segunda copia. Es especialmente importante en ensayos sucesivos y en una eventual reanudación tras un fallo.
Ensayar con migraciones de prueba representativas
Antes de producción, ejecute migraciones de prueba sobre una copia controlada. Evite utilizar datos personales en entornos sin los controles adecuados; aplique anonimización o seudonimización cuando proceda y limite el acceso. El ensayo debe usar un volumen y una variedad suficientes para revelar problemas: registros normales, históricos, cancelados, incompletos, duplicados conocidos, relaciones complejas, adjuntos y casos con permisos especiales.
Un buen ensayo sigue una secuencia repetible:
- Extraer un corte identificable de datos de origen.
- Aplicar las transformaciones documentadas.
- Cargar respetando las dependencias entre entidades.
- Ejecutar controles automáticos de integridad.
- Validar escenarios funcionales con usuarios responsables.
- Registrar defectos, ajustar reglas y repetir hasta cumplir criterios de aceptación.
Controle mucho más que el número de filas. Compare completitud de campos obligatorios, unicidad de claves, relaciones padre-hijo, sumas de importes, fechas, estados, permisos y adjuntos. Para datos financieros, concilie totales por periodos y categorías. Para datos operativos, seleccione muestras con criterios reproducibles y recorra los flujos reales: localizar un cliente, modificar un dato autorizado, crear una operación, aprobarla y recuperarla en un informe.
La validación funcional debe responder a una pregunta concreta: ¿puede el equipo ejecutar mañana sus tareas críticas sin usar el sistema anterior como fuente de corrección?
Convivencia temporal sin dos fuentes de verdad
La convivencia reduce riesgo, pero puede crear el problema más peligroso: dos sistemas editables con datos divergentes. Antes del cambio, defina una fuente de verdad por entidad y proceso. Durante la transición, una opción habitual es dejar el sistema anterior en modo consulta y concentrar las altas y cambios en el nuevo. Si ambos deben recibir cambios, establezca qué campos puede editar cada uno, cómo se sincronizan, con qué frecuencia y quién resuelve conflictos.
Una sincronización bidireccional sin reglas claras suele multiplicar duplicados, sobrescrituras y ambigüedades. Prefiera una ventana de convivencia corta, con límites explícitos y una fecha de retirada. Si el sistema anterior debe seguir generando información, identifique las diferencias desde el último corte y pruebe el mecanismo de carga incremental antes de depender de él.
Planificar el cambio y una reversión realmente viable
El plan de cambio debe especificar una congelación selectiva: qué operaciones se detienen, cuándo, quién las comunica y qué alternativa temporal existe. No todos los procesos necesitan la misma ventana. Puede congelarse la edición de maestros mientras siguen operativas consultas o actividades no afectadas.
Establezca responsables para la ejecución técnica, la aprobación funcional, las comunicaciones, la atención de incidencias y la autorización de avanzar o detenerse. Los criterios de avance deben ser observables: cargas completadas, reconciliaciones aprobadas, pruebas críticas superadas, accesos verificados y ausencia de incidencias bloqueantes.
La reversión no equivale siempre a borrar el destino. Defina qué se deshace, qué datos nuevos creados tras el cambio deben preservarse y cómo se reintroducirían en el sistema anterior si fuera necesario. Mantenga un punto de recuperación previo, conserve los archivos de carga y las tablas de correspondencia, y pruebe la decisión de reversión en un ensayo. Deben existir umbrales concretos para activarla, como pérdida de relaciones en entidades críticas, imposibilidad de operar un flujo esencial o discrepancias no explicadas en datos sensibles.
Operación posterior y lista de comprobación
Tras el cambio, mantenga una conciliación intensiva durante los primeros ciclos operativos. Centralice las incidencias en una cola con prioridad, impacto, propietario y plazo de resolución. Observe errores de integración, trabajos fallidos, accesos denegados, tiempos de respuesta y variaciones anómalas en volúmenes. La retirada del sistema anterior solo debe ocurrir cuando se hayan cumplido los plazos de consulta, las obligaciones de conservación y los criterios de cierre acordados.
Antes, durante y después de producción, compruebe:
- El alcance, las exclusiones y los responsables funcionales están aprobados.
- Existe una matriz de correspondencia de datos y una tabla de claves origen-destino.
- Las reglas de transformación, excepciones y rechazos son auditables.
- Las pruebas incluyen casos representativos y flujos críticos completos.
- La conciliación verifica contenido, relaciones, permisos y resultados de negocio.
- La convivencia asigna una única fuente de verdad para cada dato.
- El cambio tiene ventanas, comunicaciones, responsables y criterios de avance.
- La reversión protege los datos generados después del corte y tiene autorización definida.
- La monitorización y la retirada segura del sistema anterior tienen dueño y fecha.
Una migración madura no pide confianza ciega en una importación: produce evidencias para decidir si avanzar, corregir o revertir sin comprometer la operación.