Migrar datos a un nuevo software: por qué contamos los registros tres veces

Cuando una organización pasa a un sistema nuevo, de lo que más se habla es de sus funciones. Las pantallas, los informes, la aplicación móvil. Cómo se van a trasladar los datos del sistema antiguo suele quedar para el final, y se despacha con un «ya haremos una transferencia».

Ahí es donde los proyectos se atascan de verdad. El código funciona, las pantallas están listas, pero parte de los registros de clientes llega incompleta y nadie sabe cuántos faltan ni por qué.

En este artículo cuento qué comprobamos antes, durante y después de la migración.

Primero, el inventario

La migración no empieza con la primera línea de código, sino con una lista. Qué tablas hay en el sistema antiguo, cuántos registros tiene cada una, qué significa cada campo y cuál ya no se usa.

La sorpresa más frecuente en esta lista es que la misma información se guarda en dos sitios. La dirección del cliente está tanto en la tabla de clientes como en la de facturas, y las dos no coinciden. Cuál se da por correcta no es una decisión técnica, sino una que debe tomar la organización. Hay que preguntarlo antes de migrar.

La segunda sorpresa es que el sistema antiguo sea un archivo de Excel. En Excel, todo campo que no está sujeto a una regla es un campo en el que algún día alguien escribió otra cosa «de forma provisional». Aparecen filas con «no hay» en la columna de fecha y celdas con dos números en la columna de teléfono.

Mapeo de campos

Dos sistemas no guardan los datos de la misma forma. El sistema antiguo puede tener un único campo de «nombre y apellidos» y el nuevo, dos campos separados. La ciudad, que en el antiguo era texto libre, puede elegirse de una lista en el nuevo.

Para cada campo escribimos una regla de mapeo: campo antiguo, campo nuevo y la conversión entre ambos. Los registros que no cumplen la regla no se corrigen en silencio. Van a una lista aparte. Esa lista la revisamos uno por uno junto con la organización.

La corrección silenciosa parece tentadora, pero es lo peor que se puede hacer en una migración. Un registro erróneo ya lo era en el sistema antiguo. Si durante la migración se corrige a ojo, en el nuevo sistema queda un registro que parece correcto pero no lo es. Nadie volverá a darse cuenta.

Contar tres veces

Para decir «terminado» cuando acaba la migración, contamos los registros en tres puntos.

El primero es el origen. El número de registros que deben migrarse en el sistema antiguo, tabla por tabla.

El segundo es la transferencia. El número de registros que el script de migración lee, convierte y aparta en la lista separada.

El tercero es el destino. El número de registros que se crean de verdad en el nuevo sistema.

El origen debe ser igual a la suma de los transferidos y los apartados. Y los transferidos deben ser iguales al destino. Si estas dos igualdades no se cumplen, la migración no ha terminado, por pequeña que sea la diferencia. Una diferencia de unos cientos de registros significa que se ha perdido el historial de unos cientos de clientes.

Que cuadren los números no basta por sí solo. Los números pueden cuadrar y el contenido estar dañado. Por eso abrimos registros elegidos al azar en los dos sistemas, uno al lado del otro, y los comparamos campo por campo. Para los campos críticos, como importes y fechas, calculamos además totales y valores resumen en los dos lados.

Migración de prueba y plan de vuelta atrás

No hacemos la migración real por primera vez el día real. Antes hacemos al menos dos migraciones de prueba con una copia de los datos. En cada prueba medimos el tiempo, revisamos los registros apartados y corregimos las reglas de mapeo.

Antes de la migración real, el plan de vuelta atrás queda por escrito. Qué se hará si la migración se queda a medias o si los números no cuadran, hasta qué punto se podrá volver al sistema antiguo y quién tomará esa decisión. Cuando estas preguntas se hacen el día de la migración, las respuestas se dan con prisas.

Los dos sistemas a la vez durante un breve periodo

Siempre que es posible, después de poner en marcha el nuevo sistema, el antiguo sigue abierto en modo de solo lectura durante un breve periodo. Si un registro parece incompleto o erróneo, se puede consultar el sistema antiguo y compararlos.

El final de este periodo se fija desde el principio. Si no se fija, los dos sistemas conviven durante meses y se vuelve a discutir cuál de ellos es el correcto.

No migrar también es una decisión

No todos los registros antiguos tienen que pasar al nuevo sistema. Trasladar al nuevo sistema los datos cuyo plazo de conservación ha vencido obliga a la organización a seguir guardándolos sin necesidad. En el caso de los datos personales, esto puede convertirse además en un incumplimiento de una obligación.

La migración es un buen momento para hacer esta depuración. Identificamos los registros cuyo plazo de conservación ha vencido, los dejamos fuera de la migración con la aprobación de la organización y dejamos constancia del borrado. Así el nuevo sistema empieza limpio.

En resumen

La migración de datos no es una transferencia, sino un pequeño proyecto. Una migración hecha sin inventario, mapeo, recuento en tres fases, migración de prueba y plan de vuelta atrás hace perder la confianza en el nuevo sistema desde su primer día.