Respuesta corta: cuando el problema deja de ser cómo migrar una VM y pasa a ser cómo migrar cientos de forma coherente, segura y en un tiempo razonable. En la práctica, arriba de 50 máquinas la automatización se paga sola; arriba de 150 es la condición para que el proyecto termine. El objetivo real no es ahorrar horas: es acortar el período con dos plataformas prendidas, que es lo más caro de toda la migración.
Es el cierre de esta serie, y también la conclusión que más ordena las decisiones anteriores.
Por qué el período híbrido manda
Mantener dos plataformas en paralelo significa doble monitoreo, doble cadena de soporte, doble modelo de parches, doble complejidad operativa y las licencias de las dos.
Es una de las condiciones más costosas y riesgosas de cualquier migración de infraestructura. Reducir su duración debería ser un objetivo estratégico explícito del proyecto, con fecha.
Y la única manera de lograrlo a escala es automatizar. No por elegancia técnica: por plata.
Qué automatizar, en orden de retorno
1. Preparación de las VMs
Lo más repetitivo y lo más fácil de guionar: instalar virtio, regenerar el initramfs, pasar fstab a UUID, instalar el guest agent, desinstalar VMware Tools.
Con Ansible sobre las VMs Linux y PowerShell sobre las Windows, esto se resuelve con un playbook por familia. Es lo primero que hay que hacer y lo que más riesgo elimina, porque es donde el procedimiento manual se relaja.
2. Validación post-migración
Un script que verifique disco virtio, red, servicios, puertos y rendimiento, ejecutado igual en la VM 1 y en la 200. Elimina el "se me pasó" y produce evidencia para el acta de aceptación.
3. Conversión e importación
virt-v2v invocado desde un script, con registro de cada corrida y manejo de errores. Permite lanzar varias conversiones en paralelo, que es donde se gana el tiempo grande.
4. Orquestación
Lo más complejo y lo último: coordinar grupos, respetar afinidad y anti-afinidad, secuenciar las olas, manejar reintentos. Acá es donde las herramientas comerciales se justifican.
Afinidad y anti-afinidad
Es lo que más se rompe cuando se migra a mano y de madrugada.
Afinidad: VMs que deben quedar juntas por latencia o continuidad. Migrarlas en simultáneo y en el orden correcto.
Anti-afinidad: VMs que deben quedar separadas por resiliencia. Si dos nodos de un clúster terminan en el mismo host físico, perdiste la redundancia sin enterarte, y te enterás el día que ese host falla.
Un proceso automatizado puede agrupar por red, por ciclo de vida o por dependencia, y garantizar la distribución. Un proceso manual, no.
Vale la pena exportar las reglas antes de migrar:
`powershell
Get-Cluster | Get-DrsRule | Select Cluster, Name, Type, Enabled,
@{N='VMs';E={($_.VMIds | ForEach-Object {(Get-VM -Id $_).Name}) -join ', '}}
`
Esas reglas hay que recrearlas explícitamente en destino. No viajan con la VM.
Consistencia de red y CIDR
Mantener la misma segmentación durante la migración suele ser imprescindible. Migrar VMs del mismo CIDR de manera incoherente obliga a crear reglas temporales, redistribuir rutas y hacer configuraciones manuales propensas a error.
Agrupar por red es una de las decisiones que más simplifica el proyecto, y es fácil de automatizar.
El punto de equilibrio
| Parque | Recomendación |
|---|---|
| Menos de 20 VMs | Manual con procedimiento escrito |
| 20 a 50 | Manual + scripts de preparación y validación |
| 50 a 150 | Automatización de preparación, conversión y validación |
| Más de 150 | Orquestación completa, propia o comercial |
Automatizar la preparación y la validación se paga a partir de las 20 o 30 VMs, y es donde está el mayor retorno por hora invertida.
Las herramientas
- Ansible — preparación de VMs Linux. Curva de aprendizaje razonable y sirve mucho más allá de la migración.
- PowerShell + PowerCLI — todo el lado VMware y las VMs Windows.
- virt-v2v — conversión, con instalación de drivers incluida. El caballito de batalla.
- Herramientas comerciales de migración — orquestación, tableros y soporte. A partir de cierta escala se justifican solas.
Para menos de 30 VMs, los tres primeros alcanzan.
Cómo se ve un proyecto automatizado
| Manual | Automatizado | |
|---|---|---|
| Preparación por VM | 30 min | 2 min |
| Conversión | Secuencial | En paralelo |
| Validación | Variable, según quién | Idéntica siempre |
| Trabajo nocturno | Semanas | Mínimo |
| Consistencia | Se degrada con el tiempo | Constante |
| Errores reproducibles | No | Sí |
| Período híbrido | Meses | Semanas |
La fila que le importa a la dirección es la última.
Preguntas frecuentes
¿Cuánto lleva armar la automatización?
Para preparación y validación, entre una y dos semanas de trabajo. Se recupera antes de la VM número 40.
¿Y si no tengo a nadie que sepa?
Empezá por lo más simple: un script de validación post-migración. Media hora de trabajo, y evita el error más frecuente. Después, un playbook de preparación.
¿Las herramientas comerciales valen lo que cuestan?
Arriba de 200 VMs, casi siempre sí: lo que ahorran en tiempo de proyecto y en período híbrido supera la licencia. Abajo de 50, difícilmente.
¿La automatización elimina el riesgo?
No, lo hace consistente y reproducible. Un script mal hecho falla siempre igual, y eso se detecta y se corrige. Un error humano de madrugada es único e irrepetible.
¿Puedo automatizar a mitad de proyecto?
Sí, y es lo que pasa seguido: se arranca a mano, se ve que no escala y se automatiza. Mejor decidirlo al principio, pero llegar tarde es mejor que no llegar.
Cierre de la serie
Cinco semanas de recorrido: por qué migrar dejó de ser una decisión técnica, qué alternativas existen, cómo se prepara, cómo se mueve sin downtime y cómo se hace a escala.
Si tuviera que dejar una sola idea: una migración desde VMware no es un problema técnico difícil, es un problema de orden. Las que salen mal casi siempre saltearon el inventario, no probaron el backup o intentaron hacer todo de una vez.
Y el proyecto no termina cuando se migra la última VM: termina el día que se apaga la plataforma vieja. Hasta entonces, estás pagando las dos.
En Bootable Computación acompañamos este camino completo, con el objetivo explícito de que tu equipo quede en condiciones de operar la plataforma nueva sin depender de nadie.
4 páginas · el procedimiento paso a paso, en PDF. Gratis, por dejar tu email.