Migrar datos desde Excel o un sistema de gestión antiguo: cómo controlar el resultado

Una migración de datos no se juzga por el hecho de que los datos hayan entrado. Se juzga por el hecho de que se pueda demostrar que han entrado todos y correctos. La diferencia se ve tres meses después, cuando alguien busca un documento de hace dos años y no lo encuentra: en ese momento ya nadie sabe si no estaba antes, si se excluyó a propósito o si se perdió durante la transferencia.

La parte difícil no es trasladar la información. Es mantener los vínculos entre ella —el cliente conectado con sus pedidos, el pedido conectado con sus documentos— y conservar la posibilidad de verificar. Esta guía sirve para preparar la transferencia de modo que sea controlable, no solo ejecutable.

Inventario: qué existe y qué no debe pasar

Antes de mirar los campos se miran las fuentes. Casi siempre son más de las declaradas: junto al sistema de gestión hay hojas de cálculo con las que alguien resolvió un problema que el sistema de gestión no resolvía, y esas hojas contienen datos que nadie más tiene.

• Para cada fuente: quién la usa, quién la actualiza, desde cuándo existe, cuántas filas contiene y cuál es la más reciente.
• La calidad, de forma concreta: cuántas filas tienen el campo obligatorio vacío, cuántas direcciones están incompletas, cuántas fechas son imposibles. Bastan pocas comprobaciones para entender con qué se está tratando.
• Qué no debe pasar: fichas inactivas desde hace años, pruebas, filas de servicio, datos que ya no hay motivo de conservar. Es una decisión que hay que tomar y escribir, no aplazar hasta el momento de la transferencia.
• Qué debe seguir siendo consultable pero no activo: los históricos. A menudo la elección correcta es trasladar los últimos años al sistema nuevo y conservar el resto en un archivo legible, en lugar de arrastrarlo todo.

El mapeo origen-destino

Es el documento central del trabajo: una línea por campo, con la regla escrita al lado. Se rellena antes de ejecutar nada, y también sirve como documentación después. Los valores son ilustrativos.

La última fila es una regla general útil: lo que no se sabe interpretar se transfiere tal cual, en un campo de texto. Peor que perder un dato es transformarlo según una hipótesis equivocada, porque el primer error se ve y el segundo no.

Identificadores y duplicados

Cada entidad que se transfiere necesita una clave estable, y la clave del sistema antiguo debe conservarse también en el nuevo, en un campo auxiliar. No cuesta nada y permite durante años responder a la pregunta «¿de dónde viene este cliente?».

• Los duplicados se buscan antes de la transferencia, en la fuente, donde todavía se pueden corregir quienes conocen los datos.
• La fusión de dos fichas debe decidirla una persona, no una regla automática: dos sedes de la misma sociedad pueden ser dos clientes distintos por razones contables.
• Cuando dos filas se unen, se conservan ambas claves antiguas: los documentos históricos apuntan a una de las dos.
• Los duplicados que no se consiguen resolver se transfieren igualmente, marcados. Un duplicado visible es un problema; un duplicado eliminado por error es una pérdida.

La prueba, y los tres controles que importan

La transferencia se ejecuta primero en un entorno de pruebas, con una muestra que incluye los casos difíciles: el cliente con más pedidos, el de la dirección extraña, el que tiene caracteres acentuados en el nombre, el pedido más antiguo y el más reciente.

1. Recuentos: cuántas filas en origen, cuántas en destino, cuántas descartadas y por qué motivo. La suma debe cuadrar exactamente, y los descartes deben estar enumerados por nombre, no solo contados.
2. Totales: la suma de los importes por año, en origen y en destino. Es el control que descubre de un solo golpe los separadores decimales leídos mal y las filas perdidas.
3. Relaciones: tomado un cliente, ¿tiene todos sus pedidos? Tomado un pedido, ¿tiene todas sus líneas y sus documentos? Es el control que más se salta, porque el recuento total cuadra incluso cuando los vínculos se han roto.

El acta de reconciliación y el día del traspaso

El acta es una página que se firma y se conserva: fecha de la transferencia, versión de las fuentes, recuentos y totales comparados, listado de los descartes, decisiones tomadas sobre las exclusiones, nombre de quien lo verificó. Sirve para cerrar la discusión meses después, cuando la memoria ya no basta.

El traspaso definitivo se planifica como se planifica una mudanza. Se elige un momento de actividad parada, se comunica a las personas desde cuándo el sistema antiguo deja de actualizarse, y se establece de antemano qué hacer con la información introducida mientras tanto, porque alguien la introducirá de todos modos.

• Copia de seguridad completa de origen y destino, verificada antes de empezar: una copia que nadie ha intentado releer no es una copia.
• El sistema antiguo permanece accesible en solo lectura durante un período acordado. Es la verdadera vía de vuelta, más que la restauración técnica.
• Una condición de renuncia escrita de antemano: si en un momento dado los controles no cuadran, se anula y se vuelve a intentar otra vez. Decidirlo durante el proceso es imposible, porque para entonces ya están todos cansados.
• Las excepciones conocidas se asignan a alguien con una fecha límite, no se dejan en un listado: las direcciones que hay que arreglar a mano no se arreglan solas.

Lo que esta guía no cubre

Aquí se habla de la transferencia puntual: llevar los datos de donde están a donde deben estar, una vez. Mantener alineados dos sistemas que siguen funcionando ambos es un problema distinto, con reglas propias sobre quién manda sobre qué dato y qué pasa cuando los dos se contradicen, y se trata aparte. Fuera de alcance también la decisión previa, es decir, si sustituir la herramienta actual.