Desde que Broadcom cerró la adquisición de VMware, las cuentas para operar infraestructura virtualizada han cambiado. Las licencias perpetuas han desaparecido, el portafolio se ha colapsado en un puñado de paquetes de suscripción y el precio ha pasado a un modelo por núcleo. Las cotizaciones de renovación han vuelto, en general, entre 2 y 5 veces más altas que lo que los equipos pagaban antes. Para muchos CTO y arquitectos de toda Europa, la pregunta dejó de ser “¿deberíamos buscar alternativas?” y pasó a ser “¿a qué migramos y en qué orden?”.
Esto es una guía, no un argumento de venta. Somos una consultoría de ingeniería, no un proveedor de nube, así que no tenemos ninguna plataforma a la que empujarte. El objetivo aquí es darte los conceptos, los estándares abiertos y un mapa honesto de las opciones para que puedas tomar una decisión que encaje con tu stack.
Por qué los equipos están dejando VMware
Los motivos son consistentes en las organizaciones con las que hablamos:
- Coste. La licencia por núcleo penaliza a los hosts de alta densidad. Un servidor de dos sockets con dos CPU de 16 núcleos que antes necesitaba dos licencias de CPU ahora cuenta como 64 núcleos. Sumado a la consolidación de paquetes, muchas renovaciones quedan muy por encima del gasto previo.
- Empaquetado. vSphere, vSAN, NSX y la suite Aria ahora se empaquetan en grandes suscripciones como VMware Cloud Foundation (VCF) y vSphere Foundation (VVF). Si solo usabas vSphere, puede que estés pagando por capacidades que nunca despliegas.
- Dependencia y presión del fin de soporte. vSphere 7 alcanzó el fin del soporte general en octubre de 2025, y vSphere 8 está previsto para octubre de 2027. Las licencias perpetuas siguen funcionando, pero sin parches ni soporte el reloj es real.
- Disrupción del ecosistema. Los cambios en los programas de partners y proveedores de servicios cloud (el modelo VCSP pasó a ser solo por invitación a principios de 2026) han llevado a renegociar algunas relaciones de hosting gestionado.
Nada de esto significa que tengas que arrancarlo todo el próximo trimestre. Significa que deberías conocer tus opciones y tener una vía de salida creíble.
No existe un reemplazo único de VMware
Este es el punto más importante de toda la guía. VMware empaquetaba la virtualización de cómputo, el almacenamiento (vSAN), las redes (NSX) y la gestión (vCenter, Aria) en un solo stack. Ningún proyecto open source reemplaza todo eso con un único producto. La jugada correcta es mapear opciones a cargas de trabajo, apoyarse en estándares abiertos (KVM, QEMU, libvirt, Ceph, OVN/Open vSwitch, las APIs de OCI y Kubernetes) y elegir herramientas que encajen en cada capa.
Este es el panorama general, agrupado según dónde brilla cada opción. Tómalas como representativas, no exhaustivas, y no como una recomendación de una herramienta sobre otra.
Plataformas centradas en VM (lo más parecido a la experiencia de vCenter)
- Proxmox VE - KVM más LXC, con clustering integrado, migración en vivo e integración con Ceph. Muy buen encaje para pymes y mercado medio, y para virtualización on-prem sencilla donde la simplicidad importa.
- oVirt - el upstream de la antigua Red Hat Virtualization. Ahora mantenido por la comunidad tras la retirada de Red Hat, y base de productos como Oracle Linux Virtualization Manager. Un modelo familiar de datacenter/cluster/host para equipos que apreciaban la estructura de vCenter.
- Harvester - la plataforma hiperconvergente open source de SUSE, construida sobre Kubernetes, KubeVirt y Longhorn. Te ofrece una interfaz centrada en VM mientras se apoya en una fontanería cloud-native por debajo.
Plataformas de nube privada (IaaS con multitenancy y autoservicio)
- OpenStack - la opción más capaz y más modular, con proyectos separados para cómputo (Nova), redes (Neutron, normalmente OVN), almacenamiento (Cinder, Swift) e identidad (Keystone). Excelente a gran escala, pero es genuinamente compleja y recompensa a un equipo de operaciones con experiencia.
- Apache CloudStack - una IaaS integrada y opinada que se levanta más rápido que OpenStack, con soporte multihipervisor y redes maduras. Popular entre proveedores de servicios y telcos.
- OpenNebula - ligera y pragmática, idónea para edge, entornos híbridos y nubes privadas de pequeño a mediano tamaño donde quieres orquestación sin el peso operativo de OpenStack.
Caminos cloud-native con Kubernetes
Si tu hoja de ruta ya es cloud-native, puedes converger VM y contenedores en un único plano de control:
- KubeVirt - ejecuta VM como recursos de Kubernetes. Es un proyecto de la CNCF (que entró en revisión de graduación a finales de 2025) con una base de adoptantes creciente, y es el motor detrás de varios productos de virtualización comerciales.
- Cluster API - aprovisionamiento declarativo y gestión del ciclo de vida de clústeres de Kubernetes, a menudo combinado con KubeVirt o bare metal para un modelo de cluster-as-a-service.
Para la migración masiva de VM al mundo Kubernetes, el proyecto open source Forklift (base del Migration Toolkit for Virtualization de Red Hat) se conecta a vCenter, inventaría las VM, convierte los discos y realiza migraciones en frío o en caliente.
Cómo elegir
Parte de tus cargas de trabajo y de tu equipo, no de una lista corta de productos. Algunas preguntas que separan de forma consistente los buenos encajes de los dolorosos:
- ¿Qué estás ejecutando realmente? ¿Sobre todo VM de Windows y Linux de larga duración? Una plataforma centrada en VM es el camino de menor resistencia. ¿Ya estás contenerizando? Un camino cloud-native puede consolidar dos stacks en uno.
- ¿Necesitas multitenancy y autoservicio? Si es así, estás en territorio de nube privada (OpenStack, CloudStack, OpenNebula) en lugar de un gestor de hipervisor de un solo tenant.
- ¿Cuál es tu madurez operativa? La potencia de OpenStack viene con un coste real en el día 2. Sé honesto sobre si tienes -o vas a contratar, o vas a externalizar- las competencias para operarla.
- ¿Qué funciones de VMware son críticas? vMotion, HA, DRS, vSAN, la microsegmentación de NSX y Site Recovery Manager tienen todas equivalentes open source, pero rara vez se mapean uno a uno. Inventaría las funciones de las que realmente dependes, no las que licenciaste.
- La realidad de almacenamiento y redes. La mayoría de los caminos open source se apoyan en Ceph para almacenamiento y en OVN/Open vSwitch para redes. Tu SAN, tu fabric y tus políticas de segmentación actuales necesitarán un diseño deliberado, no un copia y pega.
Un enfoque de migración por fases
Las migraciones fracasan cuando se tratan como un corte único de una sola vez. Secuencia el trabajo y reduce el riesgo en cada puerta.
1. Evaluar
Construye un inventario completo: VM, dependencias, esquema de almacenamiento, políticas de red y seguridad, y exposición de licencias con sus fechas. Puntúa cada carga de trabajo por tolerancia a la indisponibilidad, complejidad y sensibilidad de cumplimiento. El resultado es un backlog de migración priorizado, no una hoja de cálculo que se queda obsoleta.
2. Diseñar
Elige la plataforma o plataformas objetivo por grupo de cargas de trabajo y diseña la arquitectura de almacenamiento y red de forma explícita. Aquí es donde mapeas las políticas de NSX a security groups de OVN, vSAN a Ceph y la ubicación al estilo DRS a tu nuevo planificador. Decide también aquí la mecánica de la migración: migración en frío o en caliente, herramientas y rollback.
3. Pilotar
Levanta el entorno objetivo en un laboratorio y migra entre el 10 y el 20 % de cargas equivalentes a producción. Mide la paridad de rendimiento, valida el failover de HA, prueba el backup y la restauración, y ejercita tus políticas de seguridad. Un piloto de dos a cuatro semanas saca a la luz las sorpresas mientras aún son baratas.
4. Migrar
Avanza en oleadas, secuenciadas por riesgo, manteniendo pequeño el impacto en producción por oleada (un techo del 10-15 % es una regla práctica sensata). Empieza por dev/test sin estado, luego las capas web, y después las bases de datos y los sistemas críticos. Mantén el entorno antiguo como destino de rollback hasta que cada oleada esté validada.
5. Operar
Una plataforma nueva necesita nuevos runbooks, monitorización, cadencia de parcheo, planificación de capacidad y procedimientos de DR. Planifica la transferencia de competencias para que el equipo asuma las operaciones del día 2 en lugar de depender indefinidamente de quien hizo la migración.
Trampas que conviene prever
- El problema del 10 %. Un pequeño conjunto de aplicaciones exclusivas de VMware genera la mayor parte del lastre de la migración. Identifícalas pronto; dictarán tu calendario.
- Las redes son más difíciles que el cómputo. Los vSwitches, los port groups y las políticas de NSX no se transfieren directamente. Los desajustes de VLAN y la recreación de políticas son una de las principales causas de indisponibilidad prolongada.
- Las pruebas de DR llevan meses, no semanas. No lo descubras cerca del go-live. Involucra a los responsables de cumplimiento y DR en la fase de diseño.
- Subestimar el día 2. La licencia que cancelas se sustituye por responsabilidad operativa. Presupuesta competencias, automatización y observabilidad.
- Monogamia de herramientas. Resiste la tentación de estandarizar todo en una sola plataforma antes de que el piloto lo demuestre. Los entornos mixtos son normales y a menudo óptimos.
La ventaja de la soberanía en la UE
Para las organizaciones europeas, y las alemanas en particular, esta migración es también una oportunidad de soberanía. Operar infraestructura open source sobre capacidad alojada en la UE elimina dos capas de dependencia externa a la vez: el software no está controlado por la hoja de ruta ni los precios de un único proveedor extranjero, y los datos permanecen bajo jurisdicción de la UE. Esa combinación -open source más residencia de datos en la UE- es exactamente lo que persiguen los marcos detrás del reciente impulso franco-alemán por la soberanía digital y los esfuerzos de Cloud Sovereignty de la Comisión Europea.
El punto estratégico es la palanca de negociación. Los estándares abiertos hacen que tus cargas de trabajo sigan siendo portables, negocias desde una posición de elección en lugar de dependencia, y tu postura de cumplimiento (GDPR, normativas sectoriales de datos) viene integrada en lugar de añadida a posteriori. Aquí la soberanía es una capacidad que diseñas, no una casilla que marcas.
Preguntas frecuentes
¿Es Proxmox un reemplazo real de VMware?
Para entornos centrados en VM, sí. Proxmox VE cubre clustering, migración en vivo, HA y almacenamiento respaldado por Ceph. No es una IaaS de nube privada completa, así que si necesitas autoservicio multitenant, mira OpenStack, CloudStack u OpenNebula en su lugar.
Proxmox vs VMware: ¿cuál es la mayor diferencia práctica?
La arquitectura y el ecosistema. VMware ofrece un stack estrechamente integrado y de un solo proveedor; Proxmox ensambla componentes abiertos (KVM, LXC, Ceph). Cambias la integración del proveedor y los contratos de soporte empresarial por control de costes, sin licencias por núcleo y sin dependencia del proveedor.
¿Cuánto tarda una migración de VMware?
Depende del tamaño del entorno y de la proporción de cargas exclusivas de VMware, pero piensa en trimestres, no en semanas. Un plan por fases con un piloto real y un corte basado en oleadas es lo que mantiene contenidos el riesgo y la indisponibilidad.
¿Tenemos que sacarlo todo de VMware a la vez?
No. Las licencias perpetuas siguen funcionando sin soporte, lo que da tiempo. La mayoría de los equipos migran en oleadas y mantienen una huella de VMware cada vez menor durante la transición.
¿Pueden ejecutarse VM y contenedores en una sola plataforma?
Sí. KubeVirt ejecuta VM como objetos de Kubernetes, lo que te permite converger ambos en un único plano de control. Encaja con equipos ya invertidos en operaciones cloud-native.
Dónde encaja Rapid Solutions
Somos una consultoría de ingeniería neutral, con oficinas en Ámsterdam y Dubái. No vendemos una plataforma, así que nuestra recomendación se rige por tus cargas de trabajo, tu equipo y tus necesidades de cumplimiento, no por lo que tengamos que monetizar. Te ayudamos con la evaluación, el diseño objetivo, el piloto, la migración basada en oleadas y el modelo operativo del día 2, con un enfoque open-source-first y soberano por diseño de principio a fin.
Si te enfrentas a una renovación de VMware o estás planificando una salida, contacta con Rapid Solutions y te ayudaremos a construir una vía de migración que encaje con el stack que realmente operas.