Una migración se juzga por dos cosas: cuánto estuvo caído y si faltó algún registro.
Movemos bases de datos, aplicaciones y cargas completas entre centros de datos, entre nubes o de un motor a otro. Con ventana de corte acordada por escrito, verificación registro a registro y un plan de reversa que existe antes de tocar nada.
- Ventana de corte típica
- 2 a 6 h
- Registros verificados
- 100 %
- Plan de reversa
- Escrito
Cómo se hace
El corte es el último día, no el primero.
Cuando una migración sale mal casi siempre es porque se saltó el ensayo. Nosotros ensayamos el corte completo al menos una vez, con datos reales, antes del corte de verdad.
Fase 1 / 2 a 3 semanas
Descubrimiento
Qué se migra, qué depende de qué, qué integraciones existen y cuál es el volumen real. Casi siempre aparecen dependencias que nadie recordaba.
Fase 2 / 2 a 4 semanas
Destino y ensayo
Se construye el entorno destino y se hace una migración de prueba completa con datos reales, midiendo cuánto tarda cada paso.
Fase 3 / 1 noche o 1 fin de semana
Corte
Ejecución del plan minuto a minuto, con criterios de aceptación y un punto de no retorno definido de antemano.
Fase 4 / 2 semanas
Estabilización
Acompañamiento cercano, ajuste de rendimiento y el origen todavía disponible en solo lectura por si aparece algo.
La ventana de corte, minuto a minuto.
Este es el plan real de una migración de base de datos de tamaño mediano, con ventana acordada de cuatro horas. Cada paso tiene responsable, duración estimada y criterio de salida. Se ensaya completo antes del corte de verdad.
| Hora | Paso | Criterio para continuar |
|---|---|---|
| 22:00 | Comunicación de inicio y bloqueo de accesos de usuario | Cero sesiones activas en el origen |
| 22:15 | Copia de seguridad final del origen | Copia completada y verificada, no solo terminada |
| 22:45 | Detención de servicios e integraciones | Todas las colas vacías, sin transacciones en vuelo |
| 23:00 | Sincronización del delta pendiente | Retraso de replicación en cero |
| 23:40 | Conteos y sumas de verificación por tabla | Coinciden origen y destino, sin excepción |
| 00:15 | Cambio de apuntamiento de la aplicación | La aplicación conecta y responde |
| 00:40 | Pruebas funcionales del negocio | El usuario clave firma la aceptación |
| 01:30 | PUNTO DE NO RETORNO | Si no se cumplió lo anterior, se reversa |
| 01:45 | Apertura a usuarios y monitoreo intensivo | Sin errores en los primeros 30 minutos |
| 02:00 | Comunicación de cierre | Ventana cumplida |
Por qué existe el punto de no retorno
Porque a las tres de la mañana, cansados y con la presión de abrir a las siete, todo el mundo decide seguir. Fijar la hora límite con anticipación quita esa decisión del momento de mayor presión.
Por qué el origen queda vivo
El sistema anterior se deja en solo lectura durante dos semanas. Cuesta poco y resuelve la pregunta que siempre aparece al tercer día: "¿esto qué decía antes?".
Por qué firma un usuario del negocio
Que la base responda no significa que el negocio funcione. Alguien que conoce la operación tiene que sacar sus propios reportes y confirmar que los números son los de siempre.
Qué incluye una migración.
- Descubrimiento de dependencias
- Qué sistemas consumen esos datos, qué reportes se alimentan de ahí y qué integraciones apuntan al origen. Es donde aparecen las sorpresas y por eso va primero.
- Diseño del entorno destino
- Dimensionamiento basado en la medición del origen, no en la intuición. Con margen para el crecimiento previsto de los siguientes dos años.
- Migración de prueba con datos reales
- Una corrida completa que mide cuánto tarda cada paso. De ahí sale la ventana de corte real, que casi nunca coincide con la estimada al inicio.
- Verificación registro a registro
- Conteos por tabla, sumas de verificación y comparación campo por campo de una muestra estadística. Los resultados quedan por escrito.
- Plan de corte y plan de reversa
- Ambos escritos, con responsables, horas y criterios de aceptación. El de reversa se escribe antes, no se improvisa el día del corte.
- Ajuste de rendimiento posterior
- Índices, consultas lentas y parámetros del motor. Un sistema migrado casi siempre necesita ajuste, porque el destino no se comporta igual que el origen.
- Acompañamiento de dos semanas
- Atención cercana después del corte, con el origen todavía disponible en solo lectura. La mayoría de los hallazgos aparecen en los primeros diez días.
Qué puede salir mal
Los cinco fallos que más veces hemos visto.
Ninguno es exótico. Todos son evitables si se buscan a tiempo, y por eso el descubrimiento es la fase más larga.
La integración que nadie mencionó
Un script que alguien dejó corriendo hace seis años y que alimenta un reporte que gerencia sí mira. Aparece al tercer día después del corte.
La codificación de caracteres
Tildes y eñes que llegan mal al destino. Trivial de arreglar antes, costosísimo de corregir cuando ya hay meses de datos nuevos encima.
El volumen que se subestimó
La ventana se calculó con una tabla de prueba y en producción hay veinte veces más datos. Por eso se ensaya con el volumen real.
Las diferencias sutiles entre motores
Manejo de fechas, ordenamiento de texto, comportamiento de nulos. No rompen nada de forma visible, solo cambian resultados en silencio.
El rendimiento que se cayó
Los datos llegaron completos, pero los índices no se recrearon igual y una consulta que tomaba dos segundos ahora toma cuarenta.
Evidencia, no un correo diciendo que quedó listo.
- InformeActa de verificación de datosConteos por tabla en origen y destino, sumas de verificación y resultado de la comparación de la muestra. Firmada por ambas partes.
- PlanPlan de corte ejecutado con tiempos realesEl plan minuto a minuto con lo que efectivamente tardó cada paso, útil para la siguiente migración.
- DiagramaMapa de dependencias e integracionesTodo lo que consume esos datos, incluido lo que nadie recordaba que existía.
- ProcedimientoPlan de reversa documentadoLos pasos exactos para devolver todo al origen, con el tiempo que toma. Se entrega aunque no se haya usado.
El precio lo define el descubrimiento, no el tamaño de los datos.
Mover un terabyte de una tabla simple es más fácil que mover diez gigas repartidos en cuarenta integraciones. Lo que cuesta es la complejidad de las dependencias.
Migración completa
desde25M COP25.000.000 pesos colombianos
De 8 a 16 semanas. Descubrimiento, entorno destino, ensayo completo, corte, verificación y dos semanas de acompañamiento.
Solo descubrimiento y plan
desde3,5M COP3.500.000 pesos colombianos
Dos semanas. Mapa de dependencias, riesgos y ventana de corte estimada. Sirve para decidir si la migración se hace ahora o el próximo año.
Valores de referencia en pesos colombianos, sin IVA. El precio final depende del alcance, el número de servidores y el nivel de servicio acordado.
Sobre ventanas, verificación y reversa.
¿Cuánto tiempo va a estar caído el sistema?
Es la primera pregunta y la respuesta se define en el diseño, no en la ejecución. Con replicación previa la ventana suele quedar entre 2 y 6 horas para una carga mediana. Sin replicación, depende del volumen y puede ser un fin de semana entero. La ventana se acuerda por escrito antes de empezar y se ensaya al menos una vez.
¿Cómo saben que no se perdió ningún registro?
Con conteos y sumas de verificación por tabla antes y después, más una muestra de registros comparada campo por campo. La migración no se declara exitosa porque el sistema arranque: se declara exitosa cuando los números cuadran y el negocio lo confirma con sus propios reportes.
¿Qué pasa si algo sale mal en el corte?
Se reversa. El plan de reversa se escribe antes de tocar nada y define un punto de no retorno: hasta cierta hora, si no se cumplen los criterios, se devuelve todo al origen y se reintenta otro día. Que exista ese punto definido de antemano es lo que evita las decisiones apuradas a las 3 de la mañana.
¿Migran bases de datos entre motores distintos?
Sí, por ejemplo de Oracle o SQL Server a PostgreSQL. Es más trabajo que una migración del mismo motor porque hay que traducir tipos de datos, procedimientos almacenados y comportamientos sutiles. Se hace con doble corrida en paralelo hasta que los resultados coincidan.
¿Se puede migrar sin detener la operación?
En algunos casos sí, con replicación continua y un corte de minutos. Requiere que el sistema origen soporte replicación y que la aplicación tolere el cambio de destino. Cuesta más y toma más tiempo de preparación, pero para operaciones que no pueden parar suele valer la pena.
Con qué se suele combinar.
Una migración termina el día del corte, pero el entorno destino hay que diseñarlo antes y operarlo después. Cuando esas tres etapas van con proveedores distintos, en el primer incidente cada uno culpa al anterior.
Infraestructura
Infraestructura cloud
AWS, Azure y Google Cloud diseñados para que la factura no se dispare.
Infraestructura
Servidores e híbrido
Cómputo físico, virtualización y arquitecturas mixtas con datos en Colombia.
Operación
Soporte gestionado
Monitoreo, parches y respuesta a incidentes con SLA que se descuenta si se incumple.
¿Qué necesita mover y cuántas horas puede estar caído?
Con esas dos respuestas le decimos si la migración es de una noche, de un fin de semana o si hay que hacerla sin corte, que es más cara pero a veces es la única opción.
Nadie recuerda una migración que salió bien. Ese es el objetivo.
El éxito de este trabajo es que el lunes la gente entre a trabajar y no note nada. Para eso el corte se ensaya antes, completo y con datos reales.
¿Prefiere no llenar un formulario?
Contesta una persona en horario lunes a viernes, 8:00 a 18:00 (cot). Por correo respondemos en 1 día hábil.