Multihipervisor no es una etapa: es lo que vas a mantener dos veces

El titular de la encuesta que ha circulado esta semana dice que nueve de cada diez clientes de VMware miran la puerta. En la misma encuesta hay otro número, el que el propio patrocinador destaca en su blog: el 60% se plantea una estrategia multihipervisor. Y las barreras que más se citan para moverse son la complejidad operativa (40%), la gestión multiproveedor (38%) y, empatadas al 37%, asegurar una superficie de ataque mayor y las competencias del equipo. Las cuatro describen el destino, no el camino. Tener dos hipervisores a la vez las instala en tu casa y te las deja puestas.

Quién preguntó, a quién, cuándo y quién lo pagó

La encuesta la hizo Unisphere Research por encargo de Rimini Street. Son 269 directivos, responsables y técnicos de organizaciones usuarias de VMware, y el trabajo de campo va de diciembre de 2025 a febrero de 2026. The Register la publicó el 7 de octubre de 2026 y de ahí sale el «mirando la puerta» del titular, que es suyo y no de la encuesta: lo que se midió es que el 90% dice que la subida del coste de licencias le ha empujado a mirar alternativas. El 54% cita el fin del soporte de las licencias perpetuas, el 73% pone el ahorro entre sus prioridades principales y el 48% no tiene previsto mover ningún activo a VMware Cloud Foundation.

Quien encarga una encuesta no la falsea, pero sí elige qué pregunta. Rimini Street vende soporte de terceros: su negocio mejora si te quedas donde estás y dejas de pagar mantenimiento al fabricante. Por simetría, el nuestro: hacemos migraciones y servicios gestionados, así que nos conviene que te muevas. No vendemos licencias de VMware ni suscripciones de Proxmox —no somos resellers de ninguna de las dos—, pero el sesgo existe y preferimos ponerlo encima de la mesa ahora y no en la última página.

Entre la pregunta y el titular han pasado ocho meses

Las respuestas tienen entre ocho y diez meses. Eso importa porque en ese intervalo han cambiado cosas que estaban en la columna de los contras cuando alguien contestó el formulario. El 2 de septiembre, Proxmox Server Solutions anunció que su soporte de empresa pasa a 24/7 el 19 de octubre —dentro de nueve días— para Proxmox VE, Backup Server y Datacenter Manager: inmediato para las suscripciones Premium, con una ventana de incorporación para Standard en el último trimestre de 2026, y sin cambio de SLA para Basic. En el mismo comunicado abrió filial en Norteamérica y declaró más de 2,3 millones de servidores Proxmox VE activos. Leímos la letra pequeña de ese comunicado en su momento, incluido el detalle de que el soporte técnico de la filial norteamericana sigue siendo en horario laboral: qué compras de verdad con ese 24/7.

Quien en enero respondió «el fabricante no da soporte fuera de horario» tenía razón entonces y deja de tenerla el 19 de este mes. Las tarifas también son públicas y se llevan a una hoja de cálculo sin pedir presupuesto a nadie: 370 € por zócalo y año en Basic, 550 € en Standard y 1.100 € en Premium. Y el 8 de octubre llegó la otra pieza: IBM traspasó a 11:11 Systems contratos de clientes de su nube VMware —la cifra de «cientos» la dio el comprador, no IBM, y no todos los clientes van allí—, con VCF 9 como destino. Lo contamos ayer. La dependencia, incluso cuando te quedas en la misma plataforma, no termina en el fabricante: también está en quién te lo revende y en a quién le vende después tu contrato.

Lo que sí se divide

Empecemos por lo que el multihipervisor hace bien, porque es verdad y porque es la razón legítima de ese 60%. La factura de suscripción baja si mueves carga de verdad. El riesgo de concentración en un proveedor se reparte. Y la renovación se negocia distinto cuando la alternativa ya está funcionando: no es lo mismo decir «estamos valorando opciones» que decir «el 30% de las máquinas ya corre fuera y el procedimiento de restauración está probado».

Fíjate en el verbo de esa última frase: corre. En producción, con usuarios dentro y con una copia que se restaura. Una plataforma alternativa en un laboratorio no negocia nada, porque todo el mundo al otro lado de la mesa sabe distinguir las dos cosas. Lo escribimos en septiembre y lo seguimos pensando: probar una alternativa no es migrar, y confundirlas es la forma más cara de no decidir.

La lista de lo que vas a tener dos veces

Esta es la parte que no suele estar en la hoja de cálculo, porque no son licencias y no llegan en una factura. Operamos Proxmox VE con Ceph en producción repartido en varios datacenters y venimos de vSphere desde versiones antiguas, así que esta lista sale de ahí: es lo que hay que hacer dos veces cuando conviven las dos plataformas.

• La restauración probada, no la copia. Hacer copias de dos plataformas es fácil; restaurar una máquina completa en cada una, cronometrarla y apuntar el resultado es el trabajo. Dos cadenas, dos pruebas, dos informes que alguien tiene que leer.
• El procedimiento de recuperación y su ensayo. Un plan de continuidad ensayado en una de las dos plataformas está ensayado a medias, y la mitad que falta es siempre la que toca el día malo.
• Las plantillas de monitorización y los umbrales. Los contadores de un clúster no significan lo mismo en las dos. Nosotros usamos Zabbix: el umbral que en una plataforma es «avisa» en la otra es ruido, y no se puede confiar en esa alerta hasta haber observado un ciclo completo de carga en cada plataforma.
• El calendario de parches y la ventana. Dos fabricantes con dos ritmos de publicación, dos ventanas que negociar con el negocio y dos conversaciones sobre por qué hay que reiniciar otra vez.
• El inventario. Mantenemos NetBox como fuente de verdad, y una fuente de verdad con dos modelos de objeto detrás tiene el doble de sitios por donde el papel y la realidad se separan sin que nadie lo note.
• Lo que vive dentro del invitado. Agentes, controladores y plantillas de aprovisionamiento. Una plantilla de Windows preparada para una plataforma no arranca igual en la otra, y eso no se arregla el día de la migración: se arregla antes o se paga después.
• Los permisos y las reglas de colocación. Quién puede hacer qué, y qué máquina puede arrancar en qué nodo, no se traducen de una plataforma a otra. Lo desarrollamos la semana pasada: en una migración los discos viajan y los permisos no viajan. En un estado dual eso no pasa una vez: se mantiene a la vez en los dos sitios.
• Los contratos. Dos relaciones de soporte, dos renovaciones en dos fechas distintas, dos interlocutores a los que escalar y una frontera nueva: la discusión sobre si el problema es del hipervisor o de la cabina, ahora por duplicado.
• El plano de gestión expuesto. Dos interfaces de administración que hay que tener fuera del alcance de cualquiera, dos boletines de seguridad que leer y dos listas de versiones afectadas que cotejar con tu parque. Es la barrera que el 37% de los encuestados puso como «asegurar una superficie de ataque mayor», y es la única de la lista que no se nota hasta que ya ha pasado algo.

A las tres de la madrugada no hay dos personas

De toda la lista, el que más se subestima es este. La guardia no se duplica cuando duplicas la plataforma: sigue habiendo una persona de turno, y ahora tiene que saber las dos. No a medias: saber dónde se mira el estado del clúster, qué significa ese mensaje, qué se puede tocar sin empeorarlo y qué no. Ese conocimiento se construye con repeticiones, y las repeticiones se reparten entre dos plataformas, así que llegas a la mitad en cada una.

Es coherente, por cierto, con lo que votaron los encuestados: el 37% puso las competencias del equipo entre las barreras. Lo que no cuadra es resolver esa barrera eligiendo el escenario que la hace permanente. Si vas a estar en dual, la formación y la documentación de guardia dejan de ser una línea opcional del proyecto y pasan a ser parte del coste de funcionamiento, todos los años.

Cuándo dos hipervisores es la respuesta correcta

Dos de las tres situaciones que vienen ahora ya aparecían en la lista de cuándo no migrar de VMware a Proxmox que publicamos en agosto, y la tercera es nueva. Las repetimos porque allí eran motivos para no mover una carga y aquí son motivos para sostener dos plataformas a la vez, que no es lo mismo ni cuesta lo mismo. En las tres, el dual es una decisión de arquitectura y no el residuo de una migración que se quedó a medias.

La primera: cargas cuya matriz de soporte del fabricante nombra una plataforma y solo una. Un ERP, un sistema sanitario, software industrial con certificación. Mover eso te ahorra una licencia y te deja sin el soporte que de verdad importa el día que no arranca. Ahí el dual se documenta en una línea: qué carga, qué matriz lo dice y con qué fecha de revisión.

La segunda: cuando manda el reloj. Si la renovación llega antes que la migración, se parte por fecha de contrato y no por tecnología, y se escribe la fecha en la que el estado dual termina. Es una decisión legítima y se defiende sola en un comité, siempre que la fecha exista.

Y la tercera: cuando la segunda plataforma es un segundo emplazamiento con su propio contrato, su propia prueba de recuperación y su propio dueño. Ahí el estado dual se ha elegido, y se paga con los ojos abiertos.

Cuándo no lo es

Cuando el estado dual sirve para aplazar la decisión. Se reconoce en una señal concreta: lo que se ha movido es lo fácil —lo que no tiene estado, lo que no tiene matriz de soporte, lo que nadie reclama— y lo caro se ha quedado donde estaba. Esa mitad no ahorra; solo reparte el trabajo en dos sitios y deja intacta la factura que se quería bajar.

Tampoco lo es cuando no hay fecha de salida escrita en ningún sitio, ni cuando la formación de las dos guardias no está presupuestada, ni cuando cada plataforma no tiene un dueño con nombre. Lo de siempre: el fallo es inevitable, la avería es una decisión de diseño. Un estado dual sin fecha y sin dueño es un aplazamiento con hardware dentro.

Vale la pena recordar, además, que el éxodo masivo no llegó a ocurrir. Lo analizamos en julio con los datos que había entonces: dos años después de Broadcom, lo que hubo fue reducción de dependencia por fases, no una salida en bloque. Esta encuesta, ocho meses más tarde, dice lo mismo con otras palabras: mucha gente mirando la puerta y bastante menos cruzándola. La fase intermedia es el sitio donde vive casi todo el mundo, y por eso merece un presupuesto propio.

Seis líneas antes de firmar nada

Si tu organización está en ese 60%, esto cabe en media página y cambia la conversación con dirección más que cualquier comparativa de precios:

• La fecha en la que el estado dual termina, y qué se hace si llega sin haber terminado.
• Qué cargas no se mueven y por qué, con el nombre del documento del fabricante que lo dice.
• Quién es el dueño de cada plataforma. Con nombre, no con departamento.
• Dónde vive el procedimiento de restauración de cada una y cuándo se probó por última vez.
• Qué contrato caduca primero y cuánto tarda de verdad la migración que lo sustituiría.
• Qué formación está presupuestada, para quién y antes de qué fecha.

Si las seis se contestan, el multihipervisor es una decisión. Si se queda alguna en blanco —normalmente la primera y la última—, lo que tienes no es una estrategia: es un estado en el que te has quedado y que vas a mantener dos veces.

Lo que nosotros decimos cuando nos preguntan

Hemos migrado empresas de VMware a Proxmox y también hemos recomendado quedarse en VMware cuando tenía sentido, y eso último lo decimos con la misma tranquilidad porque no vivimos de la licencia. Lo que no recomendamos casi nunca es el estado dual indefinido, que es justo la opción más fácil de aprobar en un comité porque no obliga a decidir nada hoy. Es la que más cuesta y la que menos se nota en la factura, que es la peor combinación posible para un presupuesto de IT.

Fuentes: «Nine in 10 VMware customers eye the exit as licensing bills bite», de Lindsay Clark, publicado en The Register el 7 de octubre de 2026 a las 13:24 UTC, de donde salen la autoría de la encuesta (Unisphere Research por encargo de Rimini Street), la muestra de 269 directivos y profesionales de organizaciones usuarias de VMware, el trabajo de campo de diciembre de 2025 a febrero de 2026 y todos los porcentajes citados: 90%, 54%, 73%, 60%, 48% y las cuatro barreras, que el artículo enumera literalmente como complejidad operativa (40%), gestión multiproveedor (38%), asegurar una superficie de ataque mayor (37%) y competencias del equipo (37%). El 60% de multihipervisor lo destaca también Rimini Street en su propio blog sobre la encuesta. Nota de prensa de Proxmox Server Solutions GmbH «Proxmox expands Enterprise Support to 24/7 and launches Proxmox North America Inc.», del 2 de septiembre de 2026, para la fecha del 19 de octubre, los productos cubiertos, el reparto por niveles de suscripción y la cifra de más de 2,3 millones de servidores Proxmox VE activos. Página pública de precios de Proxmox VE, consultada el 10 de octubre de 2026, para las tarifas por zócalo y año. «IBM offloads 'hundreds' of its cloudy VMware customers», de Simon Sharwood, The Register, 8 de octubre de 2026, para el traspaso de contratos a 11:11 Systems, la cifra de «cientos» atribuida al comprador y el destino en VCF 9. Todo lo que afirmamos sobre nuestra propia operación —Proxmox VE con Ceph en producción en varios datacenters, experiencia previa con vSphere, Zabbix para monitorización, NetBox como inventario, copias con Veeam y Proxmox Backup Server— es nuestro, y no incluye ningún dato de clientes. No hemos puesto cifras de ahorro de ninguna migración concreta porque las que tenemos son de clientes y no son públicas.