Estimación de una migración de datos

La migración en sí misma es la parte fácil. El paso de conciliación que se le 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 contemplaban, y casos extremos que sobrevivieron únicamente porque el sistema antiguo los toleraba y el nuevo no.

Este es un problema distinto al de la migración de una base de datos. Una migración de esquema modifica la estructura de una base de datos con los datos que ya contiene. Una migración de datos traslada los datos de un sistema a otro, y la cuestión no es «¿se completará la instrucción 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: «¿Cuál es el método de transición: “big bang” o “dual-write”?»

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

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

La pregunta del director general es la que debe determinar la estimación. Si el sistema antiguo desaparece dentro de un mes, necesita una estrategia que alcance una precisión del 100 %; si se mantiene en paralelo al nuevo durante dos trimestres, puede permitirse 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: correctos, erróneos o desconocida?
• Estrategia de transición: ¿«big bang», escritura dual, lectura en sombra 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, sino de que había dos historias que se hacían pasar por una sola. Divídalas: 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 la sección sobre 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. Organice una sesión gratuita de «planning poker» una vez que se haya esbozado la estrategia de transición.