Por qué el trabajo previo define el resultado
La mayoría de los problemas que aparecen durante o después de una migración a Proxmox no tienen origen en la plataforma. Tienen origen en información que no se levantó antes: hardware incompatible que se descubre en producción, dependencias entre sistemas que no estaban mapeadas, backups que se asumían correctos pero nunca se verificaron, o equipos que no estaban preparados para operar el nuevo entorno.
El checklist que presentamos a continuación es el que Aleph Server ejecuta antes de iniciar cualquier proyecto de migración. No es un requisito formal: es el resultado de haber visto qué pasa cuando se omite cada uno de estos pasos.
Bloque 1: inventario de hardware y compatibilidad
El primer bloque evalúa si el hardware existente es compatible con Proxmox VE sin restricciones.
La verificación crítica es la compatibilidad del procesador con virtualización por hardware: Intel VT-x para procesadores Intel, AMD-V para AMD. Ambas extensiones deben estar habilitadas en el BIOS o UEFI del servidor. Es común que estén disponibles pero deshabilitadas por defecto en equipos que venían configurados para otros usos.
La segunda verificación es la compatibilidad de los controladores de red y almacenamiento con el kernel de Linux que usa Proxmox VE. La versión actual de Proxmox está basada en Debian 13 Trixie con kernel 6.8. La mayoría del hardware de servidor de los últimos diez años tiene soporte nativo, pero hay excepciones documentadas en ciertos controladores RAID de marcas específicas y en algunas tarjetas de red de generaciones anteriores.
El recurso más útil para esta verificación es el foro oficial de Proxmox (forum.proxmox.com), donde la sección de hardware documenta comportamientos específicos por modelo de controladora y tarjeta de red. Para verificar el estado del driver de un componente específico en el kernel de Linux 6.8, la base de datos del kernel (kernel.org/doc) y el tracker de drivers de Linux son complementarios. La verificación toma entre una y dos horas para un servidor con componentes estándar; ese tiempo se invierte antes de comprometer la arquitectura, no durante el incidente.
La tercera verificación es la memoria RAM disponible. Proxmox VE necesita memoria para el sistema anfitrión además de la que se asigna a las VMs. Para entornos con múltiples VMs, el dimensionamiento de memoria del host debe contemplar un margen operacional para el hipervisor.
Bloque 2: mapa de VMs y dependencias
Este bloque produce el documento más importante de todo el proceso de migración: el mapa de qué sistemas existen, qué hacen, de qué dependen y en qué orden deben migrarse.
El inventario debe incluir cada máquina virtual o servidor físico en el entorno actual, con el sistema operativo, las aplicaciones que corre, los puertos y protocolos que usa, y las dependencias con otros sistemas. Las dependencias son el punto crítico: un ERP que depende de un servidor de base de datos que depende de un servidor de directorio activo tiene un orden de migración específico que no puede invertirse.
El mapa también debe identificar las ventanas de mantenimiento disponibles para cada sistema. Sistemas críticos con uso continuo tienen restricciones de tiempo que sistemas secundarios no tienen, y eso determina el cronograma real de la migración.
La priorización por criticidad define el orden de migración: primero las VMs no críticas con bajo tráfico, luego las de criticidad media, al final los sistemas core. Migrar primero los sistemas no críticos permite validar el proceso en producción antes de tocar lo que no puede fallar.
Bloque 3: plan de backup y procedimiento de rollback
Antes de ejecutar cualquier paso de migración en producción, debe existir un backup completo verificado del estado actual y un procedimiento de rollback documentado para cada etapa.
El backup verificado no es el backup que se asume que funciona: es el que se restauró en un ambiente de prueba y se confirmó que el sistema arranca y opera correctamente desde ese backup. La diferencia entre asumir y verificar es la diferencia entre tener un plan de contingencia real y tener la ilusión de uno.
El procedimiento de rollback documenta qué pasos se ejecutan si la migración de una VM específica falla o genera comportamiento inesperado en producción. Ese procedimiento debe existir antes de empezar, no improvisarse durante el incidente.
Bloque 4: validación en ambiente de pruebas
Antes de migrar sistemas de producción, el proceso completo de migración debe ejecutarse al menos una vez en un ambiente controlado.
La validación mínima incluye migrar al menos una VM no crítica al nuevo entorno Proxmox, confirmar que el sistema arranca correctamente, medir el rendimiento de las operaciones más frecuentes, y verificar que las integraciones con otros sistemas funcionan como se espera.
Si el proceso de migración involucra conversión de formato de disco —por ejemplo, de VMDK de VMware a QCOW2 de Proxmox— esa conversión debe validarse con una VM real antes de aplicarla a sistemas de producción. Las conversiones de disco son el paso con mayor probabilidad de generar problemas silenciosos que no aparecen inmediatamente.
Bloque 5: preparación del equipo
El último bloque evalúa si el equipo que va a operar el entorno Proxmox después de la migración tiene la capacidad técnica para hacerlo.
Las operaciones del día a día en Proxmox —crear y administrar VMs, gestionar backups, monitorear el estado del clúster, reintegrar un nodo después de una falla— requieren familiaridad con la interfaz y con los conceptos de la plataforma. Si el equipo no tiene esa familiaridad, la migración debe incluir un componente de capacitación práctica antes de que el entorno quede bajo su responsabilidad.
La documentación de operaciones específica para el entorno implementado —no la documentación genérica de Proxmox, sino los procedimientos escritos para ese entorno concreto— debe estar disponible antes de que el equipo quede operando de forma autónoma.
