La pregunta que se repite en las reuniones previas a una migración es si los datos van a llegar completos al destino. La que casi nunca aparece en la agenda es qué ocurre con la operación durante las horas en que los datos están a medio camino, y qué se hace a las tres de la mañana si hay que devolverlo todo al punto de partida.
Una migración es el único momento en que una empresa rompe deliberadamente un sistema que funciona. La fase de validación previa existe para que esa ruptura sea reversible y para que, si algo sale mal, el negocio siga operando mientras se resuelve. Lo que sigue es el procedimiento que aplicamos antes de tocar el primer registro.
Las ocho fases
- Redactar el plan de vuelta atrás
- Inventariar quién consume el dato
- Congelar la línea base
- Ensayar con datos reales y cronómetro
- Fijar los criterios de aborto
- Definir el modo degradado
- Validar en secuencia
- Sostener la convivencia
Fase 01
El entregable de esta fase es el plan de vuelta atrás
Antes de escribir un solo script de extracción conviene tener redactado el procedimiento de reversión, con el mismo nivel de detalle que el de avance: qué comandos se ejecutan, en qué orden, quién los ejecuta, cuánto tarda cada paso y cómo se verifica que el sistema origen quedó otra vez consistente y recibiendo escrituras.
Un plan de reversión que solo existe como intención —«si algo pasa volvemos al servidor viejo»— se descubre incompleto justo cuando hay presión de tiempo. El equipo que redacta ese documento suele encontrar en el camino tres o cuatro dependencias que nadie había considerado, y ese hallazgo temprano vale más que el documento en sí.
Fase 02
Quién consume el dato, más allá de la aplicación
El inventario de dependencias es la parte que más sorpresas produce, porque la aplicación principal casi nunca es el único consumidor de la base de datos.
En una revisión seria aparecen los reportes de gerencia que consultan las tablas directamente, los procesos programados que corren de madrugada y que nadie recuerda haber configurado, las integraciones con terceros que tienen la dirección del servidor escrita en su propia configuración, los tableros de indicadores conectados por ODBC, y con bastante frecuencia una hoja de cálculo del área comercial que se actualiza sola contra la base de producción y de la que depende el informe semanal de ventas.
Cada uno de esos consumidores es un punto que puede quedar apuntando al origen después del corte, entregando información que ya dejó de actualizarse. Conviene levantarlos con evidencia —logs de conexión de los últimos noventa días, no memoria del equipo— porque las conexiones que nadie recuerda son precisamente las que no se van a migrar.
Fase 03
La línea base: cómo demostrar después que nada se perdió
Comparar dos bases de datos después de una migración sin haber definido antes qué se compara termina en una discusión sin final. La línea base se toma sobre el origen, en frío, y se guarda firmada.
| Se captura | Qué revela si cambia |
|---|---|
| Conteo de registros por tabla | Pérdida o duplicación de filas |
| Suma de columnas de dinero y cantidades | Truncamiento de decimales, signos invertidos |
| Máximo y mínimo de cada campo de fecha | Desplazamiento por zona horaria, fechas cero |
| Nulos en columnas críticas | Campos que la transformación dejó vacíos |
| Casos frontera elegidos a mano | Codificación, comillas, adjuntos externos |
Qué incluir en los casos frontera
Registros con caracteres especiales y con eñes, nombres con tildes, textos que contienen comillas o saltos de línea, fechas antiguas o con valor cero, campos numéricos con más decimales de los habituales, registros con claves foráneas que apuntan a nada porque el sistema origen toleraba esa inconsistencia, y adjuntos o imágenes almacenados fuera de la base.
Media docena de esos casos revela problemas que ningún conteo global muestra. Migrar desde una base en Latin-1 hacia una en UTF-8 sin declarar la conversión produce doble codificación, y el síntoma aparece semanas después, cuando alguien nota que los apellidos con tilde salen corruptos en facturas ya emitidas. Las fechas guardadas sin zona horaria se comportan igual: al cargarlas en un servidor configurado en otro huso, los registros se desplazan unas horas y el desfase se descubre al cuadrar un cierre.
Fase 04
El ensayo, con datos reales y cronómetro
La ventana de mantenimiento se mide, no se estima. El ensayo se hace sobre una copia reciente de producción, con el volumen real, en infraestructura equivalente a la del día del corte, y cronometrando cada etapa por separado: extracción, transformación, carga, reconstrucción de índices, verificación.
De ahí salen los números que se le prometen al negocio. Y salen también las sorpresas de rendimiento: la carga que era rápida en el ambiente de pruebas con cincuenta mil registros y tarda seis horas con doce millones, la reconstrucción de índices que resultó ser la etapa más larga de todas, la tabla con un campo de texto largo que multiplica el tiempo de transferencia.
Un ensayo que no se cronometra deja al equipo entrando a la ventana real con una estimación optimista, que es la forma más común de que un corte planeado para cuatro horas termine a mediodía del día siguiente.
Fase 05
Criterios de aborto, escritos y con hora
Antes del corte hay que fijar tres cosas y dejarlas por escrito: la hora límite después de la cual ya no se inicia la migración aunque todo esté listo, la hora límite después de la cual se revierte sin discusión aunque falte poco, y el nombre de la persona que toma esa decisión.
El punto de no retorno
Se define en el mismo documento: la etapa a partir de la cual revertir cuesta más que avanzar, generalmente cuando el sistema destino ya empezó a recibir escrituras de usuarios reales. Todo lo que ocurra antes de ese punto debe ser reversible en un tiempo conocido.
Sin esos límites acordados en frío, la decisión de continuar o volver se toma a las cuatro de la mañana, por gente cansada, con el sesgo de haber invertido ya muchas horas.
Fase 06
Qué pasa con lo que llega durante la ventana
Mientras la migración corre, el negocio sigue existiendo. Llegan pedidos, llaman clientes, alguien necesita consultar un saldo.
Hay que definir explícitamente el modo degradado: qué operaciones se suspenden, cuáles siguen disponibles en modo de solo lectura, y dónde se registra manualmente lo que entre durante la ventana para cargarlo después. Un formulario en papel o una hoja compartida con instrucciones claras evita que el área comercial improvise, y evita también la discusión posterior sobre qué transacciones faltan.
Este acuerdo se cierra con las áreas usuarias y se comunica con varios días de antelación, junto con la hora exacta de inicio y el canal por el que se avisará que el sistema volvió.
Fase 07
La validación posterior, en orden
Terminada la carga, la verificación sigue una secuencia. Primero los conteos y las sumas contra la línea base, porque una diferencia ahí detiene todo lo demás. Después los casos frontera, uno por uno, comparados visualmente. Luego la integridad referencial y los índices. Y al final, la parte que suele omitirse: las pruebas funcionales sobre la aplicación, ejecutadas por usuarios del negocio siguiendo sus procesos habituales.
Que los datos estén completos y que el sistema funcione son dos verificaciones distintas. Una consulta que tardaba dos segundos y ahora tarda cuarenta pasa todas las validaciones de integridad y aun así deja la operación inutilizable.
También forman parte de esta etapa los permisos y los usuarios, que viajan por un camino separado del de los datos y se olvidan con frecuencia. Un sistema migrado donde todos los perfiles quedaron con acceso total funciona perfectamente hasta la primera auditoría.
Fase 08
Convivencia: cuándo se apaga el origen
El sistema origen no se apaga el día del corte. Se deja disponible en modo de solo lectura durante un periodo de convivencia que debería cubrir, como mínimo, un ciclo completo de negocio: un cierre contable, un corte de facturación, un proceso de nómina, según lo que corresponda a la operación.
Los errores que sobreviven a la validación técnica aparecen cuando alguien ejecuta un proceso mensual y el resultado no cuadra con el del mes anterior. Tener el origen consultable en ese momento convierte una crisis en una consulta de veinte minutos.
Al cerrar ese periodo se toma un respaldo final del origen, se archiva con su documentación, y solo entonces se libera la infraestructura.
El resumen operativo
- Redactar el plan de reversión con el mismo detalle que el de avance.
- Inventariar consumidores con evidencia de conexiones, no con memoria.
- Congelar y firmar la línea base sobre el origen.
- Ensayar con datos reales y cronometrar cada etapa.
- Fijar por escrito los criterios de aborto y el punto de no retorno.
- Acordar el modo degradado con las áreas usuarias.
- Ejecutar y validar en secuencia.
- Sostener la convivencia hasta cerrar un ciclo de negocio completo.
Conseguir que el negocio ponga por escrito cuánto tiempo puede estar detenido y quién tiene autoridad para revertir suele costar más trabajo que cualquiera de las etapas técnicas, y esa conversación conviene tenerla semanas antes del corte, mientras todavía se puede mover la fecha.
Preguntas frecuentes
¿Cuánto tiempo antes del corte debería empezar esta validación?
Entre tres y seis semanas para una migración de complejidad media. El ensayo cronometrado y el inventario de consumidores son las dos etapas que consumen más calendario, y ninguna se puede comprimir sin perder su valor.
¿Sirve migrar por partes en lugar de hacer un corte único?
Cuando el modelo de datos lo permite, reduce el riesgo de cada ventana y hace manejable la reversión. A cambio exige mantener sincronizados dos sistemas durante el periodo de transición, con un proceso de reconciliación que hay que diseñar y probar igual que el resto.
¿Quién debería firmar la línea base?
La persona responsable del dato en el negocio, no solo el equipo técnico. Esa firma es la que permite cerrar cualquier discusión posterior sobre si un registro faltaba antes o después de la migración.
