Cómo compruebo que una migración de datos llegó completa

Un proceso de migración que termina sin errores demuestra una sola cosa: que se ejecutó. No demuestra que llegaron todas las filas, que los totales siguen cuadrando ni que los reportes que la gente lee a la mañana siguiente dicen lo mismo que decían ayer. Desde 2009, buena parte de mi trabajo ha sido mover datos de banca y seguros de un lugar a otro, y la parte a la que dedico más cuidado es la prueba.

Comparar la carga nueva con la vieja

Cuando dirigí la migración de más de 100 procesos del almacén de datos de Pentaho a Azure Data Factory en un banco grande del Caribe, los procesos viejos siguieron funcionando mientras se construían los nuevos. Eso nos dio algo mejor que una especificación contra la cual probar: el resultado real del sistema que estábamos reemplazando.

Así que cada carga migrada se comparó con la carga vieja mediante scripts de validación y de perfilado. La misma fuente, el mismo día, dos resultados y un script que dice si coinciden. Escribir esos scripts una vez y correrlos en cada lote también redujo las pruebas manuales en un 40 %.

Comprobar por lotes, no al final

Los más de 100 procesos no salieron a producción de una vez. Con el scrum master y los product owners los convertimos en épicas y tareas de sprint, y cada lote salía a producción y se comprobaba antes de empezar el siguiente.

Un problema que aparece en un lote de cinco procesos tiene cinco lugares donde esconderse. El mismo problema, encontrado después de que cien procesos salen juntos, tiene cien, y para entonces los reportes de la mañana ya dependen de él.

Hacer visibles las diferencias

Algunos registros no van a coincidir, y es normal: los datos de origen tienen errores, casos raros y reglas que solo recuerda alguien del negocio. El error es forzar esos registros para que los totales se vean limpios.

En un proceso mensual de facturación y conciliación que construí para una organización de salud en Puerto Rico, el resultado son tres cosas: la facturación, el reporte de conciliación y una lista de los registros que no coinciden. Esa lista va a una persona para que la revise. Una lista corta de excepciones que alguien lee vale más que un total perfecto que nadie puede explicar.

Dejar a una persona donde está la decisión

Ese mismo proceso se inicia desde una pantalla de la aplicación, porque un usuario revisa y confirma los resultados en el camino. La automatización hace el trabajo pesado; la persona que responde por las cifras decide qué se factura.

Lo que reviso

• El resultado nuevo coincide con el viejo, y lo comprueba un script, no la vista.
• Cada lote queda probado antes de empezar el siguiente.
• Los registros que no coinciden terminan en una lista, no en el total.
• La persona dueña de las cifras ve las excepciones antes de que algo quede en firme.

Nada de esto es complicado. Solo hay que planearlo desde el primer día, porque una migración que no se puede probar es una migración que le van a pedir rehacer.