Respuesta corta: replicando la mayor parte de los datos con la VM todavía en producción y dejando para la ventana de corte solo los bloques que cambiaron desde la última sincronización. La ventana deja de depender del tamaño del disco y pasa a medirse en minutos. Sumado a un enfoque por olas, es lo que hace que una migración desde VMware sea algo que el negocio puede tolerar.
Es la respuesta técnica a la objeción más común: "no podemos parar".
Por qué esto define el proyecto
Una migración tradicional de una VM de 500 GB pide entre 4 y 8 horas de servicio caído. Multiplicado por un parque entero, no hay fin de semana que alcance, y ahí es donde muchas empresas concluyen que migrar es imposible.
No es imposible: es que el método estaba mal.
Con migración incremental la misma VM se corta en 15 o 20 minutos. Eso cambia la conversación con el negocio por completo.
El método, de punta a punta
1. Preparar (sin impacto)
Todo el trabajo previo: inventario, limpieza y drivers virtio. Nada de esto toca el servicio.
2. Replicar en caliente (sin impacto)
Copia inicial del disco con la VM funcionando. Puede tardar lo que tarde. Los tres mecanismos disponibles: CBT, snapshots o sincronización por bloques.
3. Sincronizar deltas (sin impacto)
Repetido tantas veces como haga falta. Cada pasada es más chica. Los principios.
4. Validar en aislamiento (sin impacto)
Arrancar la VM destino en una red aislada y verificar que levanta. Este paso es el que más sorpresas evita, y se lo saltea seguido.
5. Cortar (única ventana con impacto)
La secuencia del switchover: apagar, delta final, checksum, desconectar red del origen, arrancar destino, validar, decidir.
6. Observar
Dos semanas con el origen apagado pero conservado.
Los números
| Tradicional | Incremental | |
|---|---|---|
| Ventana por VM (500 GB) | 4–8 horas | 15–20 minutos |
| Depende del tamaño del disco | Sí | No |
| Se puede cancelar antes del corte | No | Sí, sin costo |
| Horario del corte | Madrugada obligada | Baja actividad alcanza |
| Rollback | Complejo | Minutos |
| Escalable a cientos de VMs | No | Sí |
Lo que no resuelve
Ser honesto acá evita problemas después:
- Bases de datos muy activas. Replicar el disco puede no converger. La respuesta suele ser la replicación nativa del motor: levantar réplica, sincronizar, promover.
- Aplicaciones que no toleran copia en caliente. Necesitan quiesce o una estrategia propia.
- Enlaces lentos. Si la VM escribe más de lo que el enlace transfiere, no converge nunca.
- El período con dos plataformas. Sigue existiendo y sigue siendo caro. Se acorta automatizando.
El error de olvidar las olas
La migración incremental resuelve el downtime por VM. No resuelve el riesgo del proyecto.
Aun con ventanas de 15 minutos, migrar 60 VMs en una noche sigue siendo big-bang, con todos sus modos de falla. Las dos cosas se combinan: incremental para que cada corte sea corto, olas para que el riesgo esté acotado y el equipo aprenda.
Cómo se ve en la práctica
Una semana típica de proyecto, con la ola 3 en curso:
| Día | Actividad | Impacto |
|---|---|---|
| Lunes | Replicación inicial de 8 VMs | Ninguno |
| Martes | Sincronización de deltas | Ninguno |
| Miércoles | Validación en aislamiento | Ninguno |
| Jueves | Sincronización final + cortes (8 × 20 min) | 20 min por VM |
| Viernes | Validación y observación | Ninguno |
Ocho VMs migradas, con menos de tres horas de downtime acumulado repartido entre ellas, y sin trabajo nocturno.
Preguntas frecuentes
¿Necesito herramientas comerciales?
Para menos de 30 VMs, virt-v2v con un procedimiento ordenado alcanza. Arriba de 100, la orquestación deja de ser opcional y las herramientas comerciales se justifican.
¿Cuánto ancho de banda hace falta?
Suficiente para que el delta se transfiera más rápido de lo que se genera. Medí la tasa de cambio de tus VMs antes de planificar: es el dato que define si el método es viable.
¿Puedo hacerlo con la VM en producción sin ningún riesgo?
La replicación en sí es de lectura sobre el origen: no lo modifica. El riesgo aparece en el corte, y para eso está el rollback.
¿Sirve para cualquier sistema operativo?
Para el disco, sí. Las particularidades están en el sistema operativo invitado y sus drivers, que es el tema de la semana que viene.
¿Y si tengo 500 VMs?
Ahí la conversación cambia: el problema deja de ser cómo migrar una y pasa a ser cómo migrar cientos de forma consistente. Es el cierre de esta serie.
En resumen
La migración incremental saca el tamaño del disco de la ecuación y convierte ventanas de horas en ventanas de minutos. Combinada con olas, hace que una migración desde VMware sea previsible y tolerable para el negocio.
La semana que viene: qué cambia según el sistema operativo de cada VM, y por qué a partir de cierta escala hacer esto a mano deja de ser una opción.
3 páginas · el procedimiento paso a paso, en PDF. Gratis, por dejar tu email.