Cuánto tarda migrar diez años de histórico

Es la primera pregunta de toda reunión de migración, y la respuesta honesta incomoda: el tamaño en terabytes es el peor predictor que existe.

Hemos visto migraciones de 400 GB tardar más que otras de 11 TB. No por incompetencia: porque lo que determina el plazo casi nunca es el volumen.

Las tres cosas que sí lo determinan

1. Cuánto se sabe del dato

Un histórico que alguien puede describir —qué tablas hay, qué significa cada campo, qué se dejó de usar en 2019— se migra rápido. Uno que nadie sabe explicar hay que estudiarlo primero, y ese estudio es tiempo que no aparece en ningún cronograma inicial.

Las señales de que va a costar: campos con nombres como OBS2 o FLAG_TMP, tablas que se llaman igual con sufijos _BAK y _NEW, y ninguna persona en la empresa que sepa cuál de las dos es la buena.

2. Qué acceso hay al origen

Aquí está la diferencia entre semanas y meses:

• Réplica de solo lectura disponible. Lo ideal. Se puede leer todo lo que haga falta, cuando haga falta, sin molestar a nadie.
• Solo producción, con ventana nocturna. Se trabaja, pero cada iteración cuesta un día.
• Solo producción, sin ventana. El proyecto se convierte en un ejercicio de paciencia.
• No hay acceso, solo exportaciones que alguien genera. El plazo pasa a depender de la agenda de esa persona.

3. Cuánto puede parar el sistema

Si puede estar apagado un fin de semana, la migración es un problema técnico. Si no puede parar, es un problema de diseño: hay que montar sincronización en caliente, convivencia de los dos sistemas y un plan de corte. Eso multiplica el trabajo, y lo tratamos aparte en migrar un sistema que no puede apagarse.

Rangos que hemos visto

Con las salvedades de arriba, y para dar algo concreto:

• Histórico documentado, réplica disponible, ventana de fin de semana. De tres a seis semanas de proyecto, con una ventana de corte de horas.
• Histórico sin documentar, acceso solo nocturno. De dos a cuatro meses, y la mitad se va en entender antes de mover.
• Sistema que no puede parar, con integraciones a terceros. De cuatro meses en adelante, y el plazo depende tanto del calendario de los terceros como del nuestro.

En el caso de Servinformación, con 11 TB y un histórico bien acotado, la ventana de sincronización estimada en una semana se resolvió en 20 horas. No porque el volumen fuera pequeño, sino porque para cuando llegó la ventana ya estaba decidido todo lo demás.

Cómo estimar sin mentir

Una estimación útil se construye al revés de como suele pedirse. En vez de partir del tamaño, se parte de lo que no se sabe:

1. Inventariar. Cuántas tablas, cuántas filas, cuántas se consultan de verdad en el último año.
2. Marcar lo desconocido. Qué tablas nadie sabe explicar. Ese número es el que mueve el plazo.
3. Probar una tabla difícil de punta a punta. Extraerla, cargarla y verificarla completa. Lo que tarde eso, multiplicado con criterio, es una estimación defendible.
4. Sumar la verificación. Que no es un trámite: en volúmenes grandes puede ser tanto trabajo como la carga.

Cualquier plazo dado antes del paso 1 es una adivinanza, y las adivinanzas en migraciones las paga siempre alguien. Sobre esto escribimos también en cuánto cuesta modernizar un sistema legacy.