Migrar VMware a Proxmox en 2026: checklist antes de mover la primera máquina virtual
Cada vez más empresas están evaluando si su plataforma de virtualización actual continúa siendo la arquitectura adecuada para los próximos años.
Dentro de esas evaluaciones, Proxmox Virtual Environment se ha convertido en una alternativa para organizaciones que actualmente utilizan VMware vSphere o ESXi y buscan revisar costos, arquitectura, almacenamiento, alta disponibilidad, respaldo y estrategia de crecimiento.
Pero existe un error que debemos evitar:
Una migración VMware a Proxmox no comienza exportando la primera máquina virtual.
Comienza entendiendo la infraestructura que tenemos.
Proxmox VE integra máquinas virtuales KVM, contenedores LXC, clustering, alta disponibilidad, almacenamiento y networking dentro de una misma plataforma.
Además, Proxmox dispone de herramientas para facilitar la importación de máquinas virtuales desde VMware ESXi.
Sin embargo, una herramienta de importación no sustituye un proyecto de migración.
En esta guía de la Biblioteca Virtual Sistro 2.0 revisamos qué debemos analizar antes de mover la primera VM.
1. Empieza por un assessment de la infraestructura
El primer paso es saber exactamente qué existe actualmente en VMware.
El assessment debería identificar al menos:
Hosts VMware
- Fabricante y modelo
- Procesadores
- Sockets
- Cores
- Memoria RAM
- Interfaces de red
- Firmware
- HBAs
- Almacenamiento conectado
- Capacidad utilizada
Máquinas virtuales
- vCPU
- Memoria RAM
- Discos
- Sistema operativo
- Interfaces virtuales
- Direcciones IP
- VLAN
- Aplicaciones
- Criticidad
- Responsable de la aplicación
Infraestructura adicional
- vCenter
- Storage
- Switches
- SAN
- NAS
- Backup
- Red de administración
- Red de almacenamiento
- Servicios auxiliares
En Sistro abordamos este tipo de proyectos desde una perspectiva completa de arquitectura.
Conoce nuestras soluciones de Virtualización Empresarial
2. Identifica las dependencias de las aplicaciones
Una máquina virtual rara vez trabaja completamente sola.
Un servidor de aplicaciones puede depender de:
- Active Directory
- DNS
- Base de datos
- Servidor de archivos
- Certificados
- Firewall
- Balanceador
- Storage
- LDAP
- SMTP
- API
- Otros servidores
Por eso no deberíamos organizar una migración únicamente diciendo que VM01 se mueve el lunes, VM02 el martes y VM03 el miércoles.
Debemos migrar servicios y dependencias.
Una máquina puede arrancar perfectamente después de ser migrada y aun así tener una aplicación fuera de servicio porque perdió comunicación con una base de datos, DNS o algún servicio externo.
3. Captura una línea base de rendimiento
Antes de construir la nueva plataforma Proxmox necesitamos saber cuánto consume realmente VMware.
Conviene registrar:
- CPU
- Memoria
- Capacidad utilizada
- IOPS
- Latencia
- Ancho de banda
- Crecimiento histórico
- Sesiones
- Picos de utilización
No debemos dimensionar el nuevo cluster sumando únicamente la vCPU y RAM asignadas a todas las máquinas.
Una VM puede tener 16 vCPU y utilizar normalmente una pequeña parte de esa capacidad.
Otra máquina puede parecer pequeña en CPU y memoria, pero generar una cantidad muy alta de operaciones de almacenamiento.
El objetivo del capacity planning es dimensionar Proxmox de acuerdo con el consumo real y el crecimiento esperado.
4. Clasifica las máquinas virtuales por criticidad
No todas las VMs deberían migrarse de la misma manera.
Baja criticidad
- Desarrollo
- Pruebas
- Herramientas internas
- Servidores que pueden detenerse con facilidad
Criticidad media
- Aplicaciones departamentales
- Servicios internos
- Servidores con ventanas de mantenimiento disponibles
Alta criticidad
- ERP
- Bases de datos
- Servicios de autenticación
- Aplicaciones operativas
- Sistemas 24x7
Casos especiales
- Appliances virtuales
- GPU o vGPU
- VDI
- Hardware virtual específico
- Sistemas legacy
- Software ligado a hardware
- Productos cuyo soporte depende del hipervisor
Los casos especiales deben analizarse antes de incluirlos dentro de una migración masiva.
Conoce el servicio de Migración a Proxmox VE de Sistro
5. Revisa compatibilidad antes del piloto
Antes de mover cualquier máquina virtual debemos revisar:
- BIOS o UEFI
- Tipo de disco
- Controladores virtuales
- Sistema operativo
- Drivers
- Interfaces de red
- Direcciones IP
- Software instalado
- Dispositivos especiales
- Snapshots
- ISO conectadas
Una máquina Linux moderna probablemente tendrá un comportamiento diferente a un Windows Server antiguo o a un appliance especializado.
Esta es precisamente una de las razones para realizar una prueba de concepto antes de tocar producción.
6. Diseña Proxmox antes de comenzar a migrar
Antes de mover máquinas debemos responder una pregunta fundamental:
¿Dónde van a vivir las VMs?
Una arquitectura Proxmox empresarial puede involucrar:
- Uno o varios nodos
- Cluster Proxmox
- Corosync
- Quorum
- Alta disponibilidad
- Linux Bridges
- Bonding
- VLAN
- Storage
- Red de migración
- Red de backup
- Red de administración
- Seguridad
El objetivo no debe ser simplemente instalar Proxmox.
El objetivo es diseñar una plataforma empresarial de virtualización.
Instalación y Configuración Proxmox VE Empresarial
7. ¿Cuántos nodos necesita un cluster Proxmox?
Esta decisión depende del nivel de disponibilidad que necesita la empresa.
Para escenarios empresariales con alta disponibilidad, normalmente conviene evaluar arquitecturas de tres nodos o más cuando el proyecto y presupuesto lo permiten.
También pueden existir diseños de dos nodos con mecanismos adicionales para resolver quorum, pero requieren una evaluación específica.
Alta disponibilidad no consiste únicamente en activar una función.
También debemos revisar:
- Quorum
- Corosync
- Capacidad disponible en los nodos restantes
- Storage
- Red
- Energía
- Switches
- Backup
Si un nodo falla, los nodos restantes deben tener capacidad suficiente para ejecutar las cargas protegidas.
8. Diseña correctamente el almacenamiento
Proxmox puede trabajar con diferentes tecnologías de almacenamiento.
Entre ellas:
- ZFS
- LVM
- LVM-Thin
- NFS
- SMB/CIFS
- iSCSI
- SAN
- Ceph RBD
- CephFS
- Almacenamiento local
- Almacenamiento compartido
Pero no todas las alternativas son adecuadas para todos los proyectos.
La decisión depende de:
- Capacidad
- IOPS
- Latencia
- Redundancia
- Presupuesto
- Crecimiento
- Disponibilidad requerida
Empresa que ya tiene SAN
Puede tener sentido estudiar cómo aprovechar la infraestructura existente.
Empresa que busca infraestructura hiperconvergente
Puede evaluarse una arquitectura Proxmox + Ceph.
Ambiente pequeño
ZFS o almacenamiento local puede ser suficiente dependiendo de disponibilidad, respaldo y objetivos.
Ceph no debe instalarse automáticamente solo porque Proxmox lo soporte.
9. No olvides el networking
Una migración de virtualización también es una migración de red.
Debemos transformar conceptos de VMware hacia la arquitectura de Proxmox.
Por ejemplo:
VMware Port Group → VLAN → Bridge/Bond Proxmox → NIC física → Switch
Hay que revisar:
- VLAN
- MTU
- LACP
- Bonding
- Routing
- Switches
- Redundancia
- Red de administración
- Red de máquinas virtuales
- Red de almacenamiento
- Red de migración
- Corosync
Una plataforma puede tener excelentes servidores y aun así presentar problemas si la red se convierte en el cuello de botella.
10. Confirma el backup antes de migrar
Nunca deberíamos migrar una carga productiva sin una estrategia clara de recuperación.
Antes de cada oleada debemos confirmar:
- Backup reciente
- Capacidad de restauración
- Retención
- Ubicación del respaldo
- Tiempo estimado de recuperación
- Responsable
- RPO
- RTO
Backup y Disaster Recovery deben formar parte del diseño de la plataforma desde el inicio.
11. Proxmox Backup Server o Veeam
Proxmox Backup Server puede complementar el ecosistema Proxmox mediante backups incrementales, deduplicación, compresión y cifrado.
Pero si la empresa ya tiene una plataforma de respaldo, también debemos estudiar la posibilidad de conservarla cuando exista compatibilidad.
Una migración bien diseñada no obliga necesariamente a sustituir toda la infraestructura existente.
La conversación correcta es:
¿Cómo protegemos actualmente las máquinas virtuales y cómo queremos protegerlas después de la migración?
12. Define el rollback antes del cambio
El rollback no debe diseñarse después de que algo falle.
Antes de migrar debemos establecer:
- Cuándo se considera fallida una migración
- Cuánto tiempo tenemos para tomar la decisión
- Quién autoriza el rollback
- Cómo regresará la máquina virtual
- Cómo se manejarán cambios de información
- Qué IP o DNS deben restaurarse
- Cuánto tiempo requiere el procedimiento
Una migración profesional siempre debe contemplar un camino de regreso.
13. Realiza una prueba de concepto
Antes de migrar 50, 100 o 300 máquinas virtuales debemos seleccionar unas pocas cargas representativas.
La prueba podría incluir:
Linux sencillo
Para validar el flujo básico.
Windows Server
Para revisar drivers, almacenamiento y networking.
Aplicación con base de datos
Para validar dependencias.
Máquina con mucho almacenamiento
Para medir tiempos de transferencia.
La PoC permite conocer:
- Tiempos
- Errores
- Compatibilidad
- Intervenciones manuales
- Procedimiento necesario
14. Después realiza un piloto
PoC y piloto no son exactamente lo mismo.
La PoC demuestra que técnicamente podemos realizar la migración.
El piloto demuestra que el procedimiento puede utilizarse en producción dentro de una ventana controlada.
Después del piloto debemos documentar:
- Duración
- Errores encontrados
- Cambios requeridos
- Validaciones
- Tiempo de rollback
- Pasos manuales
15. Migra por oleadas
Para ambientes medianos o grandes, resulta más seguro realizar una migración gradual.
Oleada 0
Laboratorio y prueba de concepto.
Oleada 1
Máquinas de baja criticidad.
Oleada 2
Aplicaciones internas.
Oleada 3
Servicios importantes.
Oleada 4
Cargas críticas.
Este enfoque permite mejorar continuamente el procedimiento antes de llegar a los sistemas más importantes.
16. No prometas cero downtime sin analizar el escenario
Existen herramientas y procedimientos que pueden reducir notablemente la indisponibilidad.
Pero una migración empresarial no debería prometer de forma genérica cero downtime sin estudiar previamente el ambiente.
El tiempo de corte depende de:
- Tamaño de los discos
- Storage
- Red
- Método de migración
- Sistema operativo
- Aplicaciones
- Consistencia de datos
- Pruebas posteriores
Es preferible ofrecer una ventana controlada, procedimiento probado y rollback definido.
17. Valida después de migrar
Una máquina virtual que enciende no está necesariamente migrada correctamente.
Sistema operativo
- Arranque
- CPU
- RAM
- Discos
- Servicios
Networking
- IP
- Gateway
- DNS
- VLAN
- Routing
Aplicaciones
- Login
- Base de datos
- Integraciones
- Servicios
Operación
- Backup
- Monitoreo
- Antivirus
- Logs
Finalmente, el propietario de la aplicación debe validar que el servicio funciona correctamente.
18. ¿Cuándo conviene evaluar VMware a Proxmox?
Puede tener sentido estudiar una migración cuando la empresa busca:
- Modernizar la infraestructura
- Revisar costos
- Reducir dependencia tecnológica
- Consolidar virtualización
- Crear clusters
- Implementar alta disponibilidad
- Evaluar infraestructura hiperconvergente
- Utilizar Ceph o ZFS
- Conservar storage existente
- Integrar backup
- Crear una nueva estrategia de operación
Conoce las soluciones Proxmox VE de Sistro
19. ¿Cuándo no deberíamos migrar inmediatamente?
No recomendaríamos una migración inmediata sin mayor análisis cuando existen:
- Plataformas VDI críticas
- GPU o vGPU
- Appliances certificados únicamente para VMware
- Aplicaciones legacy
- Dependencias desconocidas
- Storage altamente especializado
- Automatizaciones dependientes de VMware
- Restricciones regulatorias
- Ausencia de un backup funcional
- Falta de ventanas de mantenimiento
En algunos escenarios puede ser mejor mantener temporalmente una plataforma híbrida.
La decisión correcta también puede ser no migrar todavía.
20. ¿Qué debería entregar un Assessment de migración?
Un assessment profesional debería terminar con:
- Inventario actual
- Mapa de dependencias
- Baseline de desempeño
- Clasificación de máquinas virtuales
- Matriz de compatibilidad
- Arquitectura destino
- Sizing
- Diseño de almacenamiento
- Diseño de red
- Estrategia de backup
- Prueba de concepto
- Piloto
- Plan de migración
- Rollback
- Cronograma
- Riesgos
- Estimación económica
Así dejamos de hablar solamente de instalar un hipervisor.
Empezamos a hablar de modernizar una plataforma de virtualización empresarial.
Soluciones de Virtualización y Proxmox en Sistro
Virtualización Empresarial
https://sistro.net/virtualizacion
Proxmox VE
https://sistro.net/virtualizacion/proxmox
Migración a Proxmox VE
https://sistro.net/virtualizacion/proxmox/migracion-proxmox-ve
Instalación y Configuración Proxmox VE Empresarial
https://sistro.net/virtualizacion/proxmox/instalacion-proxmox-ve
Soporte Administrado Proxmox VE
https://sistro.net/virtualizacion/proxmox/soporte-administrado-proxmox-ve
Recomendación final
Migrar VMware a Proxmox puede ser una excelente oportunidad para modernizar infraestructura, revisar costos y replantear la arquitectura de virtualización.
Pero la migración no debe comenzar convirtiendo máquinas virtuales.
Debe comenzar con:
Assessment → dependencias → capacity planning → arquitectura → backup → PoC → piloto → oleadas → validación → estabilización.
¿Estás evaluando migrar VMware a Proxmox?
En Sistro Networks podemos ayudarte a revisar hosts, máquinas virtuales, almacenamiento, networking, aplicaciones, backups, dependencias, alta disponibilidad y crecimiento antes de mover la primera VM.
Después construimos un plan de migración con prueba de concepto, piloto, oleadas, validación y estrategia de rollback.
Consulta nuestro servicio de Migración a Proxmox VE
Preguntas frecuentes
¿Proxmox puede importar máquinas VMware?
Sí. Proxmox dispone de herramientas de importación para facilitar escenarios de migración desde VMware ESXi. De cualquier forma, después de importar deben validarse sistema operativo, drivers, red, aplicaciones y servicios.
¿Tengo que apagar las máquinas virtuales?
Depende del procedimiento, almacenamiento y características de la carga. La ventana de indisponibilidad debe determinarse durante la prueba de concepto y el piloto.
¿Proxmox soporta alta disponibilidad?
Sí. Proxmox VE puede trabajar en clusters con alta disponibilidad cuando la arquitectura de nodos, quorum, networking y almacenamiento está correctamente diseñada.
¿Necesito Ceph para utilizar Proxmox?
No. Proxmox soporta diferentes tecnologías de almacenamiento. Ceph es una opción para determinados escenarios distribuidos e hiperconvergentes, pero no es obligatorio.
¿Puedo conservar mi SAN?
En muchos proyectos puede evaluarse el aprovechamiento del almacenamiento existente mediante tecnologías compatibles. La viabilidad debe determinarse durante el assessment.
¿Cuántos nodos necesita un cluster Proxmox?
Depende de disponibilidad, almacenamiento y nivel de resiliencia requerido. Para entornos empresariales de alta disponibilidad suele ser recomendable comenzar evaluando tres nodos o más cuando el proyecto lo permite.
¿Puedo seguir utilizando Veeam?
Actualmente existen opciones de integración de Veeam con Proxmox VE. La compatibilidad debe validarse de acuerdo con las versiones utilizadas y los requerimientos del proyecto.
Deja un Comentario