Las migraciones rara vez fallan por la tecnología. Fallan por el certificado que caducaba esa semana, por el trabajo programado que nadie recordaba, por la dependencia con un sistema de terceros que no aparecía en ningún diagrama. Fallan por lo que nadie comprobó, no por lo que nadie sabía hacer.
Por eso lo que marca la diferencia no es la destreza durante la ventana de migración, sino el trabajo de las semanas anteriores. Este es el guion que seguimos.
Semanas antes: el trabajo que nadie ve
Inventario real, no el documentado. El diagrama de arquitectura de la wiki suele tener dos años. Nosotros partimos del tráfico observado: qué habla con qué, con qué frecuencia y por qué puertos. Casi siempre aparecen dos o tres integraciones que nadie mencionó en la reunión inicial.
Criterios de éxito medibles. «Que funcione» no es un criterio. Sí lo es: la latencia del percentil 95 se mantiene por debajo de X, la tasa de errores no supera Y, el proceso nocturno termina antes de las Z. Sin números acordados de antemano, decidir si la migración ha ido bien acaba siendo una discusión de opiniones a las tres de la mañana.
Criterios de vuelta atrás, y quién los decide. Esto es lo que más se salta y lo que más caro sale. Hay que acordar antes qué situación concreta dispara la marcha atrás y qué persona tiene autoridad para ordenarla sin convocar a nadie. Improvisar esa decisión bajo presión es como se convierte un problema de una hora en una noche entera.
Ensayo completo. Al menos uno, en un entorno equivalente y con volumen de datos realista. Un ensayo con una base de datos de juguete no prueba nada: los problemas de las migraciones aparecen casi siempre por volumen o por tiempo de proceso.
La víspera
- Copia de seguridad verificada. No «hecha»: verificada, restaurando en otro sitio y comprobando que los datos están.
- Congelación de cambios. Nada entra en producción las 24 horas previas.
- Canal de comunicación abierto y una persona designada para informar, que no debe ser ninguna de las que están ejecutando.
- Caducidades revisadas: certificados, credenciales, tokens de integraciones.
El día
Se ejecuta el guion escrito, sin improvisar. Si aparece algo no previsto, se para y se valora; no se resuelve sobre la marcha con una idea brillante de madrugada.
Siempre que la arquitectura lo permite, migramos por fases con tráfico progresivo: un porcentaje pequeño primero, se observa, se amplía. Es más lento y evita casi todos los desastres, porque cuando algo va mal afecta al 5% de los usuarios y no al 100%.
Y una regla que parece obvia y se incumple constantemente: quien ejecuta no es quien vigila los paneles. Con la cabeza metida en un procedimiento no se ve subir una gráfica.
Después: la parte que todos se saltan
La migración no termina cuando el tráfico está en el sistema nuevo. Termina días después.
Hay que vigilar activamente al menos un ciclo completo de negocio: si tienes cierres mensuales o picos semanales, no sabrás realmente que la migración ha ido bien hasta que hayan pasado. Muchos problemas de rendimiento solo se manifiestan con el patrón de carga real.
Y hay que apagar lo viejo. Suena trivial y es donde se acumulan meses de coste: infraestructura antigua encendida «por si acaso» durante un trimestre entero. Ponle fecha a ese apagado el mismo día que termines la migración, o no ocurrirá nunca.
¿Tienes una migración por delante? Cuéntanos qué quieres mover →
Sigue leyendo
- ¿Multi-cloud o un solo proveedor? Cómo decidirlo sin dogmas
- Tu factura cloud no baja sola: cómo recuperar el control del gasto
Puedes ver todo lo que hacemos en servicios, o echar un vistazo a los tipos de proyecto que solemos abordar.