Cuándo NO migrar de VMware a Proxmox

Migrar de VMware a Proxmox es parte de lo que hacemos. Y hay casos en los que la respuesta que damos es que no toca. No por prudencia comercial: por la cuenta que sale. Estos son los cinco casos, y de paso los dos argumentos con los que ya no se puede defender que te quedes.

La conversación sobre si Proxmox «está listo» se sigue haciendo, en la mayoría de reuniones a las que llegamos, con una lista de carencias copiada de una comparativa de hace tres años. Hay una parte de esa lista que caducó en mayo de este año y otra que sigue exactamente igual de vigente. Separar las dos es la mitad del trabajo de decidir, y casi nadie la hace antes de sentarse a mirar el precio de la renovación.

Conviene además quitarse de encima el marco épico. Casi tres años después de la compra, el movimiento real de clientes de VMware fue mucho más pequeño que el ruido: lo miramos con los datos que había en el éxodo que no fue. La mayoría de empresas ni huyó ni se quedó tan tranquila; renegoció y siguió. Así que esto no va de bando. Va de si en tu caso concreto salen los números.

Dos objeciones que ya no se sostienen

La primera: «no tiene DRS». Era cierta. Dejó de serlo el 21 de mayo de 2026, con Proxmox VE 9.2. La nota de prensa oficial lo describe así: «operando en un nuevo modo dinámico, el planificador de recursos del clúster (CRS) incorpora la utilización de recursos de nodos e invitados en tiempo real a cada decisión de colocación». Y añade que «el balanceador de carga integrado puede migrar automáticamente invitados gestionados por la pila de alta disponibilidad (HA) para reducir el desequilibrio entre los nodos del clúster, respetando estrictamente todas las reglas de HA definidas por el usuario».

Lee entera la segunda frase, porque la parte que importa está a mitad: invitados gestionados por la pila de HA. El balanceador mueve lo que esté dado de alta como recurso de alta disponibilidad. Las máquinas que tengas simplemente arrancadas en un nodo, sin declarar en HA, se quedan donde están por muy desequilibrado que esté el clúster. Es coherente y está documentado; sencillamente no es lo que la gente entiende cuando lee el titular.

La segunda: «no hay copias de terceros serias». Veeam da soporte a Proxmox VE desde 2024 y la versión 13.1, publicada el 29 de julio de 2026, incorpora trabajos de replicación para la plataforma. Ahora el matiz honesto, que está en las notas de esa misma versión, en el apartado de problemas conocidos: «un trabajo de replicación puede fallar si la máquina virtual de origen tiene discos cuyo tamaño no es múltiplo del tamaño de bloque usado por el almacenamiento de destino». Traducido: funciona, y tiene aristas. Se planifican antes, no se descubren el fin de semana del corte.

Lo que de verdad cambia: quién toma las decisiones por ti

La diferencia relevante entre las dos plataformas no es una lista de funciones. Es que vSphere llegaba con un montón de decisiones ya tomadas —por el fabricante, por el integrador, por quien lo montó hace ocho años— y Proxmox espera que las tomes tú. Cuando nadie las toma, quedan tomadas igual: en el valor por defecto. Y los valores por defecto están escritos en la documentación, a la vista de cualquiera.

La página del manual de datacenter.cfg define el bloque crs. Tres cosas de ahí conviene mirarlas antes de firmar nada:

• ha=<basic|static|dynamic>, con «default = basic». Y basic es, literalmente, «solo se usa el número de servicios». De fábrica, el planificador reparte contando máquinas: la base de datos que se come el nodo entero y la maquinita del servidor de licencias valen exactamente lo mismo.
• ha-auto-rebalance, con «default = 0». Ese balanceo automático del titular no se activa solo. Es una casilla que alguien tiene que marcar, con su umbral (ha-auto-rebalance-threshold, por defecto 30%) y su histéresis (ha-auto-rebalance-hold-duration, por defecto 3 rondas).
• ha-rebalance-on-start, con «default = 0». Ni siquiera al arrancar un servicio parado se busca el nodo más adecuado, salvo que se lo pidas.

Nada de esto es un defecto. Son valores conservadores, y para un clúster recién montado son los correctos: un balanceador que empieza a mover máquinas solo el primer día es peor que uno quieto. El problema no es el valor, es la creencia. Si alguien vendió la migración diciendo «ya tiene DRS» y nadie tocó el fichero, el clúster está repartiendo por número de máquinas y nadie lo sabe hasta que un nodo va ahogado y el de al lado está medio vacío.

La objeción que sigue en pie: la red de seguridad que no viene puesta

Hay una función de vSphere de la que casi nadie habla en las comparativas y que echamos de menos de verdad: el admission control. La documentación de Broadcom describe la política de slots como un mecanismo que calcula cuántas máquinas caben si fallan N anfitriones y que, cuando la capacidad de conmutación disponible baja de la configurada, impide la operación. No avisa: la impide. Es decir, vSphere te prohíbe arrancar la máquina que rompería tu propia N-1.

La documentación de alta disponibilidad de Proxmox VE no describe ningún mecanismo equivalente. Hay reglas de afinidad de nodo y de recurso, hay prioridades, hay fencing con watchdog. No hay nada que reserve capacidad ni que te frene cuando te la comes. De hecho, la propia documentación te pasa la pelota con todas las letras: al explicar qué ocurre cuando cae un nodo, dice que el gestor reparte los servicios entre los que quedan y que eso sube el número de servicios en esos nodos, y añade «diseñe su clúster de forma que pueda soportar esos escenarios del peor caso». Es una instrucción para ti, no una función del producto. Puedes llenar el clúster hasta el borde y todo funcionará perfectamente hasta el día en que se caiga un nodo y descubras que lo que había dentro no cabe en los que quedan. Ese día no es una caída: es un fallo convertido en avería por una decisión de diseño que nadie tomó. Lo mismo que contamos en la HA de Proxmox no evita la caída, la acorta, con la diferencia de que aquí ni siquiera la acorta.

Se resuelve, claro. Se resuelve con una hoja de cálculo, una revisión trimestral y una regla escrita de cuánta RAM se deja libre por nodo. Pero pasa de ser una barrera de la plataforma a ser una disciplina de la casa, y las disciplinas de la casa se relajan en agosto.

Los cinco casos en los que decimos que no

Ninguno de los cinco es un problema de Proxmox. Uno es del calendario, otro es de tu proveedor de software y los otros tres son de casa.

1. Cuando la fecha la pone la renovación

Es el caso más frecuente y el más caro. Llega la oferta de renovación, el número escuece, quedan seis semanas y alguien decide que se migra antes de que expire. Migrar con la fecha impuesta desde fuera significa renunciar a lo único que hace segura una migración: poder pararla. Nosotros trabajamos con vuelta atrás preparada y con una ventana en la que el origen sigue encendido y arrancable, y esa ventana caduca sola por contrato y por datos. Si la renovación se te come la ventana, la recomendación honesta es renovar el periodo más corto que te dejen y migrar sin cuchillo en el cuello.

2. Cuando lo que sostiene la facturación tiene matriz de soporte

El ERP, el sistema de gestión sectorial, el software del laboratorio, la aplicación que valida las facturas. Muchos de esos fabricantes publican una lista de hipervisores sobre los que dan soporte, y esa lista no se negocia por foro ni por benchmark: se pregunta por escrito, con el número de contrato delante, y se guarda la respuesta. Si tu proveedor crítico contesta que fuera de su lista atiende en modo best effort, eso es una decisión de riesgo que corresponde a dirección, no a sistemas. Y no la arregla que Proxmox rinda igual o mejor, porque el problema no era técnico.

3. Cuando nadie ha hecho la cuenta de la N-1

La cuenta es de primaria y aun así casi nunca está hecha. Súmale a cada nodo la memoria realmente asignada a las máquinas que tiene encendidas —no la del último inventario, la de hoy—, quítale el nodo más cargado y comprueba si esa suma cabe en los que quedan dejando margen para el propio sistema. En vSphere no hacía falta hacerla porque la hacía el admission control; en Proxmox la haces tú o no se hace. Cuando sale que no cabe, hay tres salidas honestas: comprar un nodo más, apagar algo, o escribir en el plan que ante la caída de ese nodo concreto hay servicios que no arrancan y decir cuáles. Las tres son válidas. Fingir que la pregunta no existe no lo es, y migrar un clúster sobreaprovisionado a una plataforma que no te va a frenar es quitar el airbag y comprar un coche más nuevo.

4. Cuando el problema no es el hipervisor

Una sola sala. Copias que nunca se han restaurado de verdad. Un tiempo objetivo de recuperación que nadie ha cronometrado. Cambiar de hipervisor no arregla nada de eso y consume el presupuesto y las horas de la persona que podría estar arreglándolo. Si tu exposición real está ahí, el orden correcto es primero poner número al RTO y al RPO y probar un restore con cronómetro, y después ya hablamos de plataforma. Es peor consejo comercial y mejor consejo a secas.

5. Cuando no hay quien lo mantenga a las tres de la mañana

Proxmox VE es Debian por debajo, y eso es una ventaja enorme el día que hay que mirar un log y una desventaja el día que nadie sabe cuál mirar. La plataforma tampoco perdona el olvido del ciclo de vida: la rama 8 llega a fin de soporte a finales de este mes de agosto y el gestor de paquetes no te va a avisar por su cuenta. Si en la empresa no hay nadie que vaya a leer eso, y tampoco hay contratado quien lo haga, la migración se convierte en una plataforma nueva sin dueño. Eso es peor punto de partida que un vSphere caro pero cuidado.

Y cuándo sí, entonces

Cuando la cuenta a tres años sale con las horas de proyecto dentro y no solo con el precio de las licencias. Cuando hay una ventana en la que se puede parar sin drama. Cuando el software crítico está confirmado por escrito. Cuando alguien —de casa o de fuera— se queda con la plataforma después de la foto de fin de proyecto. Y cuando se hace por capas: un grupo de máquinas poco críticas primero, semanas de convivencia entre las dos plataformas, y el origen encendido hasta que ya nadie se acuerda de él.

Trabajamos con las dos plataformas desde hace muchos años y no vendemos licencias de ninguna, que es exactamente por lo que nos podemos permitir escribir esto. Cuando la respuesta es que te quedes, cobramos bastante menos. También dormimos mejor.

Nota de fuentes

Las citas del modo dinámico del CRS y del balanceador integrado son de la nota de prensa oficial de Proxmox Server Solutions sobre Proxmox VE 9.2 (21 de mayo de 2026). Los valores por defecto de crs (ha=basic, ha-auto-rebalance=0, ha-rebalance-on-start=0, umbral 30, duración 3) están en la página de manual datacenter.cfg(5) de la documentación de Proxmox VE. La frase sobre diseñar el clúster para el peor caso es del capítulo de alta disponibilidad de esa misma documentación. La ausencia de un mecanismo de reserva de capacidad es una lectura nuestra de ese capítulo: describe reglas de afinidad, prioridades y fencing, y no describe nada equivalente al admission control. La descripción de la política de slots y de que impide la operación es de la documentación técnica de Broadcom para vSphere. La fecha de la 13.1 de Veeam (29 de julio de 2026) y el problema conocido de los trabajos de replicación son de sus notas de versión oficiales; el soporte de Veeam a Proxmox VE viene de 2024, no de este año. El fin de soporte de Proxmox VE 8 aparece como «2026-08» en la tabla de ciclo de vida de la FAQ de Proxmox VE. Las citas en castellano son traducción nuestra del original en inglés. Los cinco casos, el orden en que los ponemos y la opinión sobre los valores por defecto son nuestros, no de las fuentes.