Cómo migrar una base de datos sin detener la operación

Migrar una base de datos da miedo, y con razón. Es donde viven tus clientes, tus pedidos y tu facturación. Un error puede significar días sin operar o, peor, datos que nadie sabe dónde quedaron.

La buena noticia es que casi todos los problemas se evitan con planeación. Este es el proceso que seguimos en proyectos grandes, incluidos los que hemos hecho para Telmex.

1. Entender qué hay antes de mover nada

Antes de hablar de fechas, hacemos un inventario:

• Cuántos datos hay y qué tan rápido crecen.
• Qué sistemas leen y escriben en la base: aplicaciones, reportes, integraciones, procesos nocturnos.
• Qué procedimientos, disparadores y tareas programadas tiene la base, que casi nunca están documentados.
• Cuánto tiempo puede estar detenida la operación sin que duela de verdad.

Esa última respuesta define todo lo demás.

2. Decidir la estrategia de corte

Hay dos caminos principales:

Corte en una sola ventana. Se detiene el sistema, se copian los datos, se valida y se arranca en la nueva base. Funciona cuando los datos no son tantos y hay una ventana de fin de semana disponible.

Migración en paralelo. Se copia la base completa mientras la operación sigue, y luego se sincronizan los cambios en tiempo casi real hasta el momento del cambio. El corte final dura minutos. Es más trabajo, pero es lo indicado para sistemas que no se pueden detener.

3. Ensayar, ensayar y volver a ensayar

Nunca migramos producción en el primer intento. Hacemos al menos un ensayo completo en un ambiente de pruebas con una copia real de los datos. Ahí aparecen los problemas de verdad: tipos de datos que no coinciden, acentos que se rompen, consultas que en el nuevo motor tardan diez veces más.

Cada ensayo nos da algo valioso: el tiempo real que tardará el corte.

4. Validar registro por registro

"Se ve bien" no es una validación. Comparamos conteos por tabla, sumas de control de montos y fechas, y muestras de registros al azar entre la base anterior y la nueva. Si algo no cuadra, se detiene el proceso hasta entender por qué.

5. Tener siempre un plan de regreso

Antes del corte definimos el momento exacto en el que, si algo sale mal, regresamos a la base anterior. Y lo ensayamos también. Un plan de regreso que nunca se probó no es un plan.

6. Acompañar los primeros días

Después del corte vigilamos el rendimiento, los errores de las aplicaciones y los procesos nocturnos. Es normal ajustar índices o consultas en la primera semana.

Señales de que ya te toca migrar

• Tu versión de Oracle, SQL Server o MySQL ya no tiene soporte del fabricante.
• Los reportes tardan cada vez más y el servidor ya no da para más.
• Pagas licencias caras por funciones que no usas.
• Quieres llevar la operación a la nube y la base es lo único que te detiene.

Si te identificas con alguna, platícanos tu caso. En una primera llamada te decimos qué tan compleja se ve la migración y qué estrategia de corte usaríamos.