Respuesta corta: porque concentra todo el riesgo en una sola ventana sin salida. Si algo sale mal a las 4 de la mañana con 60 VMs a medio migrar, no hay rollback posible en el tiempo que queda. El enfoque por olas parece más lento y termina siendo más rápido, porque cada paso tiene punto de retorno y el equipo aprende antes de tocar lo crítico.
La tentación es entendible: un fin de semana largo, todos los recursos puestos, y el lunes ya está. En el papel cierra.
Los cinco modos de falla
1. El tiempo nunca alcanza
Las estimaciones se hacen con la VM que salió bien en el laboratorio. En producción cada máquina tiene su particularidad: un disco más grande, un servicio que no frena, un appliance que nadie recordaba.
Con 60 VMs, si el 10% se complica —y siempre se complica— son seis problemas que no estaban en el cronograma, en una ventana que no tiene aire.
2. El rollback deja de existir
A la mitad del proceso, con parte migrada y parte no, volver atrás implica deshacer todo lo hecho. Y en ese punto ya hay datos nuevos en el destino.
El big-bang tiene rollback en el papel. En la práctica, pasada cierta hora, la única salida es hacia adelante.
3. El equipo se agota
Doce horas de trabajo repetitivo de madrugada degradan la calidad de las decisiones. Los errores más caros de una migración se cometen entre las 3 y las 6 de la mañana, cuando alguien decide saltear una verificación "porque ya la hicimos veinte veces".
4. No hubo aprendizaje previo
En una migración por olas, la ola 3 se hace mucho mejor que la ola 1: se ajustó el procedimiento, se automatizó lo repetitivo, se conocen las trampas.
En big-bang, la VM crítica número 55 se migra con la misma inexperiencia que la número 1.
5. Todo falla junto
Si aparece un problema sistémico —un driver que no funciona como se esperaba, un almacenamiento que no rinde— en big-bang lo descubrís con todo migrado. Por olas lo descubrís en la ola 1, con cinco VMs no críticas.
La comparación
| Big-bang | Por olas | |
|---|---|---|
| Duración total | Un fin de semana | Semanas o meses |
| Riesgo por evento | Muy alto | Bajo |
| Rollback | Teórico | Real y probado |
| Aprendizaje aplicado | Ninguno | Cada ola mejora la siguiente |
| Desgaste del equipo | Extremo | Manejable |
| Período con dos plataformas | Casi nulo | Semanas o meses |
| Previsibilidad | Baja | Alta |
Hay una columna donde el big-bang gana: el período con las dos plataformas prendidas, que es caro. Ese es su único argumento honesto, y no alcanza para compensar el resto.
El argumento del período híbrido
Es cierto que mantener dos plataformas en paralelo cuesta: doble monitoreo, doble cadena de soporte, doble modelo de parches, doble complejidad. Reducir ese período debería ser un objetivo explícito.
Pero la forma de acortarlo no es hacer todo de una noche: es automatizar el proceso para que las olas avancen rápido. Ahí está la respuesta real, y es el tema del cierre de esta serie.
Cuándo el big-bang sí tiene sentido
Para ser justos, hay casos:
- Menos de 10 VMs, todas simples y sin criticidad
- Entorno de laboratorio o desarrollo, sin usuarios
- Todo el parque apagado por un feriado largo, con negocio detenido de todos modos
- Hay un deadline duro —un contrato que vence, un datacenter que cierra— y no hay alternativa
En esos casos, igual conviene ordenar por dependencia y tener rollback definido para cada grupo.
Preguntas frecuentes
¿Cuánto tarda una migración por olas?
Para 50 a 100 VMs, entre 2 y 4 meses de trabajo parcial. Suena largo comparado con un fin de semana, hasta que contás los fines de semana que se pierden reparando un big-bang.
¿No es más caro mantener las dos plataformas?
Sí, y hay que contarlo en el TCO. La respuesta correcta es acortar ese período automatizando, no comprimirlo en una noche.
¿Cómo convenzo a la dirección de que lleva meses?
Con el argumento del riesgo, no del tiempo: por olas, si algo falla afecta a 5 VMs no críticas; en big-bang, afecta a toda la empresa un lunes a la mañana.
¿Cuántas VMs por ola?
Entre 5 y 15 al principio. Cuando el procedimiento está aceitado y automatizado, más.
En resumen
El big-bang concentra todo el riesgo en el peor momento posible y elimina el rollback justo cuando más se necesita. Por olas cada paso tiene retorno, el equipo mejora sobre la marcha y los problemas aparecen cuando todavía son baratos.
Lo que hace viable el enfoque por olas sin ventanas largas es la migración incremental: replicar mientras la VM sigue en producción.
3 páginas · el procedimiento paso a paso, en PDF. Gratis, por dejar tu email.