Estimación de una migración de datos

La migración en sí es la parte fácil. El paso de conciliación que ha olvidado es donde se esconden los puntos.

Una migración de datos —el traslado de datos de un sistema a otro, o de un formato a otro dentro del mismo sistema— se asemeja a una transformación. Se lee desde la fuente, se transforma, se escribe en el destino y se redirige el tráfico. El equipo vota sobre la transformación. La transformación suele ser la tarea más pequeña de la historia. Los puntos de dificultad residen en lo que la transformación no detecta: registros que parecen correctos pero que hacen referencia a datos que no se han transferido, registros que parecen erróneos pero que, en realidad, son correctos de una forma que las especificaciones no han tenido en cuenta, y casos extremos que han sobrevivido únicamente porque el sistema antiguo los toleraba y el nuevo no.

Este es un problema distinto al de una migración de base de datos. Una migración de esquema modifica la estructura de un almacén con los datos que ya contiene. Una migración de datos traslada datos entre sistemas, y la cuestión no es «¿se completará el ALTER a tiempo?», — sino «¿qué hacemos con las filas que no coinciden en ninguno de los dos lados?». La mayor parte del trabajo consiste en la conciliación, la estrategia de transición y la reversión. El código de transformación es la parte que se escribe más rápido y se termina en último lugar.

Lo que se dice en la sala

Backend: «Es un script. Leer, asignar, escribir. Dos días como máximo».

Ingeniería de datos: «¿Hemos analizado el grado de «suciedad» de la fuente?»

SRE: «¿Cómo se llevará a cabo la transición: mediante un cambio radical o mediante escritura dual?»

Titular: «¿Quién resuelve los problemas con las filas que no se migran correctamente?»

PM: «¿Cuándo vamos a dejar de utilizar el antiguo sistema?»

La pregunta del director general es la que debe determinar la estimación. Si el sistema antiguo desaparece dentro de un mes, se necesita una estrategia que alcance una precisión del 100 %; si se mantiene en paralelo al nuevo durante dos trimestres, se puede dejar la «cola larga» para más adelante. La estimación no se refiere a la transformación, sino a la estrategia.

Preguntas que conviene plantearse antes de votar

¿Cuál es la calidad de los datos de origen: están limpios, sucios o se desconoce su estado?
Estrategia de transición: ¿«big bang», escritura dual, lectura en paralelo o gradual?
¿Durante cuánto tiempo coexistirán ambos sistemas? ¿Hay una fecha límite?
¿Quién se encarga de resolver las discrepancias en las filas que no se migran correctamente, y en qué nivel?
¿Cuál sería el procedimiento de reversión en caso de que el nuevo sistema recibiera datos erróneos tras la migración?
¿Existen consumidores posteriores (informes, integraciones) que deban migrar de forma sincronizada?

Si el equipo vota un 5 y alguien dice «un momento, ¿qué pasa con los registros del diario de auditoría?», no se trataba de un problema de estimación; se trataba de dos historias que se hacían pasar por una sola. Divídalo: la transformación es un ticket, y la conciliación y el plan de transición son otro.

Voten sobre la estrategia, no sobre la transformación. La transformación dura dos días. La estrategia abarca todo el trimestre.

Consulte cómo realizar una estimación de la migración de una base de datos para la variante de cambio de esquema en un único sistema, así como los demás ejemplos prácticos de estimación. Inicie una sesión gratuita de «planning poker» una vez esbozada la estrategia de transición.