Estimación de una migración de datos

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

Una migración de datos (el traslado de datos de un sistema a otro, o de una estructura a otra 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 retos residen en aquellos aspectos 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 que ya contiene datos. 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 que surgen cuando la migración no se realiza correctamente?»

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

La pregunta del director general es la que debe marcar la pauta de la estimación. Si el sistema antiguo desaparece en 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: correctos, erróneos o desconocida?
• Estrategia de migración: ¿«big bang», escritura dual, lectura en sombra, gradual?
• ¿Durante cuánto tiempo coexistirán ambos sistemas? ¿Hay una fecha límite?
• ¿Quién se encarga de conciliar 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 transició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 ha tenido un problema de estimación; lo que ha tenido son 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 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 esbozada la estrategia de transición.