Migrar de VMware a Proxmox: los pasos que reducen el riesgo

Una migración de infraestructura de virtualización es uno de los proyectos TI con mayor potencial de impacto operacional si se ejecuta sin el orden correcto. No por la complejidad técnica de Proxmox, sino porque los servicios que corren sobre esa infraestructura son críticos y cualquier interrupción tiene consecuencias directas para el negocio.

Este artículo describe el enfoque que usamos en Aleph Server para estructurar migraciones de VMware a Proxmox, priorizando la reducción del riesgo sobre la velocidad de ejecución.

Antes de hablar de migración: el inventario

El error más frecuente al planificar una migración es subestimar lo que existe. En empresas medianas que llevan años con el mismo entorno, el inventario real de VMs, dependencias y servicios suele ser más complejo de lo que nadie recuerda.

El primer paso es siempre un inventario completo: qué máquinas virtuales existen, qué procesos de negocio dependen de cada una, qué integra con qué, qué SLA informal tiene cada servicio, y quién es el responsable técnico de cada uno. Ese inventario puede tomar entre uno y tres días dependiendo del tamaño del entorno. Sin él, el plan de migración tiene huecos que aparecen en los peores momentos.

Evaluación de hardware: lo que hay que verificar

Proxmox funciona sobre hardware estándar, pero hay componentes que requieren validación previa. Las controladoras de almacenamiento para configuraciones con Ceph, las tarjetas de red para configuraciones con bonding o LACP, y la compatibilidad general del hardware con el kernel de Linux en la versión de Proxmox que se va a usar deben verificarse antes de instalar nada.

Si hay hardware que no es compatible o que requiere reemplazo para soportar la configuración objetivo, ese costo entra en el análisis de viabilidad de la migración y debe evaluarse antes de comprometer fechas.

Entorno paralelo: la regla que no se negocia

La migración directa de VMware a Proxmox, reemplazando uno por el otro en el mismo hardware, es el enfoque de mayor riesgo. La recomendación es siempre construir el entorno Proxmox en paralelo al entorno VMware existente.

Esto permite migrar cargas de trabajo de menor criticidad primero, validar el comportamiento del entorno nuevo con servicios reales pero no críticos, afinar la configuración antes de comprometer servicios importantes, y mantener la capacidad de reversión mientras el equipo construye confianza en la plataforma.

El primer proceso que se migra no debería ser el más crítico del negocio. Debería ser el que permita aprender más con el menor impacto potencial.

Acciones de quick win en las primeras semanas

Backup automatizado y verificado: Proxmox tiene capacidades de backup integradas configurables en menos de un día. Las copias de seguridad se pueden almacenar en NFS, PBS (Proxmox Backup Server) o almacenamiento en la nube. La verificación automática de backups, que confirma que los archivos son restaurables, es una funcionalidad que muchos entornos VMware no tienen activa. Implementarla sola ya justifica parte del costo del proyecto.

Proxmox Backup Server, disponible como proyecto separado e integrado nativamente en Proxmox VE, agrega verificación de integridad, deduplicación y cifrado sobre los backups básicos. Para entornos con más de tres hosts o con requisitos de recuperación ante desastres, PBS es el paso natural desde la configuración inicial.

Monitoreo de recursos con visibilidad real: la interfaz de Proxmox provee métricas de CPU, memoria, red y almacenamiento por VM en tiempo real, con historial configurable. Para equipos que hasta ahora no tenían visibilidad del uso de recursos, esto tiene impacto operacional inmediato.

Alta disponibilidad básica: si el entorno tiene al menos tres nodos físicos, configurar un clúster con HA toma menos tiempo en Proxmox que en VMware y no requiere licencias adicionales. Eso reduce el riesgo de indisponibilidad por falla de hardware de forma estructural.

Acciones de mayor alcance y su secuencia recomendada

Almacenamiento distribuido con Ceph: Ceph se integra de forma nativa en Proxmox y permite almacenamiento distribuido sin depender de SAN dedicadas. Requiere hardware compatible y un diseño de red adecuado. Es una inversión de configuración que tiene sentido cuando el entorno ya está estabilizado y el equipo tiene experiencia con Proxmox.

Migración de VMs críticas: solo cuando el entorno paralelo ha demostrado estabilidad con cargas reales durante un período suficiente. No antes.

El plan de rollback: no es opcional

Toda migración de infraestructura crítica necesita un plan de vuelta atrás documentado y practicado. No como formalidad de gestión de proyectos: como documento operacional que el equipo sabe cómo ejecutar bajo presión.

El plan debe incluir los pasos específicos para restaurar el servicio en el entorno VMware si algo falla en el entorno Proxmox, los tiempos estimados de cada paso, y quién es responsable de cada decisión durante una contingencia. Si ese plan no existe o no ha sido revisado con el equipo, la migración no debería empezar.

Cómo estructuramos estos proyectos en Aleph Server

Los proyectos de migración de infraestructura que trabajamos en Aleph Server siguen siempre este orden: inventario → evaluación de hardware → construcción de entorno paralelo → quick wins → migración progresiva por criticidad → revisión post-migración.

La velocidad no es el objetivo. La estabilidad operacional al final del proceso es el objetivo. Un proyecto que tarda cuatro meses pero deja la infraestructura en condiciones robustas y con el equipo del cliente en control tiene más valor que uno que tarda seis semanas y genera dependencias de soporte externo para cada ajuste.


Artículos relacionados

Orquestación de datos

Automatización de procesos de negocio: cómo saber qué automatizar primero

La automatización de procesos de negocio es una de las iniciativas TI con mayor potencial de impacto en empresas medianas, y también una de las que más frecuentemente se implementa en el orden equivocado. No por falta de criterio técnico, sino porque la presión operacional del día a día hace difícil detenerse a evaluar qué tiene más sentido atacar primero.

Leer más >
Criterio Aleph Server

Por qué en Aleph Server documentamos lo que hicimos, aunque parezca obvio

La documentación técnica es probablemente el entregable más subestimado en proyectos TI. No el plan previo al proyecto, que suele estar bien desarrollado. Lo que se subestima es la documentación de lo que realmente quedó implementado: la arquitectura resultante, las decisiones que se tomaron en el camino, y los procedimientos que el equipo del cliente necesita para operar el sistema de forma autónoma.

Leer más >