Migración de VMware a Proxmox
Cambiar de hipervisor es un proyecto de infraestructura, no una conversión de ficheros. Se planifica, se prueba y se puede deshacer.
El problema
Los cambios en el modelo de licenciamiento de VMware de los últimos años han llevado a muchas organizaciones a revisar el coste de su plataforma de virtualización. En algunos casos el incremento es asumible; en otros, obliga a evaluar alternativas en serio.
El riesgo está en cómo se aborda esa evaluación. Un cambio de hipervisor toca la base sobre la que funciona todo lo demás y, si se hace mal, los efectos aparecen semanas después: rendimiento distinto del esperado, copias que ya no encajan con la nueva plataforma, integraciones rotas o una alta disponibilidad que sobre el papel existe y en la práctica nunca se ha probado.
Tampoco es una decisión que deba tomarse por tendencia. Hay entornos donde la migración se amortiza rápido y otros donde el ahorro de licencia no compensa el coste del proyecto ni el riesgo de tocar una plataforma estable.
Qué hace IT Encore
Empezamos por el análisis, no por la migración. Con el inventario real del entorno —número de máquinas, recursos consumidos, tipo de almacenamiento, integraciones y licencias actuales— se puede comparar el coste de continuar con el coste de cambiar, incluido el proyecto.
Si la migración tiene sentido, la ejecutamos con la misma metodología que aplicamos a una migración de centro de datos: descubrimiento, diseño del destino, pruebas con un grupo piloto, ventana de cambio acordada, validación y plan de vuelta atrás disponible hasta el final.
Trabajamos con las dos plataformas en producción, incluidas nuestras propias infraestructuras. Eso nos permite decir con criterio cuándo la migración conviene y cuándo no, sin un interés comercial en empujar en una dirección concreta.
Metodología del proyecto
- 1
Descubrimiento
Inventario de máquinas, recursos asignados y consumidos, sistemas operativos, discos y dispositivos especiales.
- 2
Análisis de dependencias
Integraciones, licencias atadas a hardware, dispositivos en modo directo, aplicaciones sensibles al cambio.
- 3
Comparativa de coste
Coste de continuar frente a coste de cambiar, incluidos el proyecto y el soporte de la nueva plataforma.
- 4
Diseño del destino
Clúster Proxmox dimensionado, almacenamiento, red segmentada, política de copia y alta disponibilidad.
- 5
Piloto
Migración de un grupo reducido de máquinas representativas y validación funcional y de rendimiento.
- 6
Plan de migración
Agrupación por dependencias y criticidad, calendario y ventanas de cambio acordadas.
- 7
Ejecución
Migración por oleadas, con el entorno de origen disponible hasta la validación de cada oleada.
- 8
Vuelta atrás
Procedimiento definido y probado para revertir una oleada si la validación no es satisfactoria.
- 9
Validación
Pruebas funcionales, de rendimiento, de copia y de conmutación de nodo en el entorno definitivo.
- 10
Estabilización
Acompañamiento posterior, ajuste fino y retirada ordenada de la plataforma de origen.
Aspectos técnicos que se resuelven en el proyecto
- Conversión de discos. Traslado de los discos virtuales al formato de destino, con verificación de integridad.
- Controladoras y arranque. Adaptación de controladoras de disco y de red, y de la configuración de arranque de cada sistema.
- Herramientas del hipervisor. Sustitución de las herramientas de invitado de VMware por los controladores correspondientes.
- Direccionamiento. Conservación de direcciones y de identificadores de red para no romper integraciones.
- Licencias atadas al hardware. Identificación previa de software cuya licencia depende de identificadores de máquina.
- Copia de seguridad. Rediseño de la política de copia sobre la nueva plataforma antes del cambio, no después.
- Alta disponibilidad. Configuración y prueba real de la conmutación en el clúster de destino.
- Monitorización. Instrumentación del nuevo entorno desde el primer día, con comparativa frente al anterior.
Cuándo NO recomendamos migrar
Cuando el entorno depende de funcionalidades específicas de VMware que no tienen equivalente directo y que son críticas para el negocio.
Cuando existe software con licencias atadas a identificadores de hardware cuyo cambio implica una renegociación costosa con el fabricante.
Cuando el ahorro de licenciamiento no compensa el coste del proyecto en un plazo razonable, algo que ocurre en entornos pequeños.
Cuando la organización atraviesa un momento en el que no puede asumir el riesgo ni la atención que exige un cambio de plataforma. Entonces se planifica para más adelante.
Preguntas frecuentes
¿Cuánto tiempo lleva una migración?
Depende del número de máquinas, del almacenamiento y de la ventana disponible. Un entorno de unas decenas de máquinas se aborda en oleadas a lo largo de varias semanas, con paradas cortas por máquina. El calendario se cierra tras el descubrimiento.
¿Hay parada de servicio?
Sí, aunque acotada. Cada máquina requiere una parada durante su traslado y adaptación. Se planifica por grupos y en ventanas acordadas, y los servicios en alta disponibilidad pueden migrarse sin interrupción percibida por el usuario.
¿Se puede volver atrás?
Sí, y es parte del plan. El entorno de origen se mantiene disponible hasta que cada oleada queda validada. La vuelta atrás no es una posibilidad teórica: es un procedimiento escrito y probado.
¿Hace falta comprar hardware nuevo?
No necesariamente. En muchos proyectos se reutiliza el hardware existente liberando hosts a medida que avanzan las oleadas. Cuando el hardware está próximo a su fin de vida, suele aprovecharse la migración para renovarlo.
Servicios relacionados
Proxmox VE: diseño, clúster y operación
Diseño, implantación, clúster, alta disponibilidad, Ceph, backup y mantenimiento de Proxmox VE.
Ver servicioVMware vSphere y ESXi
Operación, upgrades, troubleshooting y evolución de plataformas vSphere, ESXi y vCenter.
Ver servicioMigración de centros de datos
CPD a CPD, on-premise a CPD, CPD a cloud y entre clouds, con plan de vuelta atrás.
Ver servicioPlanifique su migración
Empezamos por el análisis: números concretos antes de decidir nada.