Respuesta corta: la migración manual funciona bien para unas pocas máquinas y se degrada rápido a partir de ahí. Los problemas no son técnicos sino humanos: el procedimiento se relaja después de repetirlo veinte veces, el trabajo nocturno agota al equipo, el proceso es secuencial y no se puede paralelizar, y coordinar grupos con afinidad o anti-afinidad se vuelve inmanejable. El resultado es un proyecto que se estira, se vuelve impredecible y a veces se abandona a la mitad.
Que es el peor de todos los desenlaces posibles: pagando dos plataformas, para siempre.
Los siete problemas
1. Hacen falta muchos ingenieros
Una migración manual implica trabajar VM por VM: preparar el sistema, ajustar controladores, convertir el disco, registrar la imagen, probar. La cantidad de gente necesaria crece en proporción directa a la cantidad de máquinas, y con ella el costo y la impredecibilidad.
2. El procedimiento se relaja
Al principio todos siguen los pasos con rigor. Después de la vigésima VM, empiezan a saltearse verificaciones "porque siempre dan bien".
Ahí aparecen las desviaciones. Y en una migración masiva, las desviaciones se traducen en fallas, retrabajo y resultados inconsistentes: VMs que quedaron distintas entre sí sin que nadie sepa por qué.
3. Trabajo nocturno extensivo
Las migraciones manuales necesitan ventanas de bajo impacto, y eso significa madrugadas y fines de semana. A escala son semanas o meses de trabajo fuera de horario, con el desgaste correspondiente, más probabilidad de error y menos capacidad de supervisión.
4. El proceso es secuencial
Cada VM se revisa, convierte y valida antes de pasar a la siguiente. Eso limita la paralelización y hace que el proyecto avance lento. Y cualquier incidente en una VM detiene el flujo completo.
5. Los grupos con afinidad son difíciles de coordinar
Ciertas aplicaciones necesitan operar en la misma zona o el mismo clúster. Migrarlas juntas reduce latencia y simplifica la continuidad. Sin automatización, garantizar que un grupo se mueva en simultáneo y en el orden correcto es muy difícil.
6. La anti-afinidad es peor
El caso inverso: aplicaciones que deben estar en hosts distintos por resiliencia. En una migración manual, y más de madrugada, es fácil terminar consolidando en el mismo host dos VMs que existían separadas justamente para tolerar una falla.
Lo peor es que nadie se entera hasta que ese host se cae.
7. El equipo se desgasta
La monotonía y la repetición aumentan los errores e impactan la moral. En migraciones de cientos de VMs, los ingenieros enfrentan semanas de procedimientos idénticos. Eso deriva en desmotivación y, en casos concretos, en renuncias.
Perder a la persona que conoce el proyecto a mitad de camino es uno de los riesgos más caros y menos considerados.
Dónde está el límite
| Cantidad de VMs | Manual | Comentario |
|---|---|---|
| Menos de 20 | 🟢 Perfectamente viable | Automatizar no se paga |
| 20 a 50 | 🟡 Viable con procedimiento estricto | Conviene automatizar lo repetitivo |
| 50 a 150 | 🟠 Se vuelve pesado | Automatización recomendada |
| Más de 150 | 🔴 No escala | Automatización necesaria |
El corte no es exacto y depende de tu equipo. La señal de alarma es concreta: cuando empezás a escuchar "esto ya lo hicimos, salteemos la verificación".
El costo escondido: el período híbrido
Mientras el proyecto se estira, convivís con dos plataformas de virtualización. Eso significa:
- Doble monitoreo
- Doble cadena de soporte
- Doble modelo de parches
- Doble complejidad operativa
- Las licencias de las dos
Es una de las condiciones más costosas y riesgosas de cualquier migración de infraestructura. Reducir ese período debería ser un objetivo estratégico explícito, y la única forma de lograrlo a escala es automatizar.
Un proyecto manual que se estira de 3 meses a 9 no cuesta el triple en horas: cuesta el triple en horas más seis meses adicionales de doble plataforma.
Qué se automatiza primero
No hace falta automatizar todo de entrada. Por orden de retorno:
- La preparación de las VMs — instalar virtio, regenerar initramfs, ajustar fstab. Es lo más repetitivo y lo más fácil de guionar.
- La validación post-migración — un script que verifique servicios, puertos y rendimiento elimina el "se me pasó".
- La conversión y la importación —
virt-v2vinvocado desde un script, con registro. - La orquestación de olas — coordinar grupos, afinidad y anti-afinidad. Lo más complejo y lo último.
Con los dos primeros ya eliminás la mayor parte del riesgo humano, y son los más baratos de hacer.
Preguntas frecuentes
¿Automatizar no lleva más tiempo que hacerlo a mano?
Para 10 VMs, sí. Para 100, la automatización se paga en la primera semana. El punto de equilibrio suele estar entre 30 y 50 máquinas.
¿Qué pasa si el script falla?
Lo mismo que si falla una migración manual, con dos ventajas: el error es reproducible y queda registrado. Un error humano de madrugada no siempre se puede reconstruir.
¿Necesito un programador?
Para lo básico no: bash y PowerShell alcanzan para preparación y validación. Para la orquestación completa, sí conviene alguien con experiencia, o una herramienta comercial.
¿Y si mi equipo no sabe automatizar?
Empezá por lo simple: un script de verificación que corra después de cada migración. Es media hora de trabajo y evita el error más común, que es olvidarse de un chequeo.
En resumen
La migración manual no falla por lo técnico: falla por lo humano. Procedimientos que se relajan, gente cansada de madrugada, imposibilidad de paralelizar y grupos de afinidad imposibles de coordinar.
A partir de cierta escala, automatizar deja de ser una mejora y pasa a ser la condición para que el proyecto termine.
4 páginas · el procedimiento paso a paso, en PDF. Gratis, por dejar tu email.