El caso Tesco contra Broadcom ha dejado de ser solo una disputa de licencias. Se ha convertido en una señal para todos los equipos de infraestructura que todavía dependen de VMware: salir es posible, pero no se improvisa. Y cuanto más crítica sea la plataforma, más importante es empezar antes de que el calendario lo imponga.
Según documentos revisados por The Register, Tesco ha decidido abandonar VMware y también productos mainframe de Broadcom mientras mantiene su demanda en Reino Unido. El caso no se verá en el High Court antes de una ventana que se abre el 01/11/2027 y se cierra el 25/02/2028, pero la parte técnica ya está en marcha: el minorista británico afirma que ha tenido que buscar alternativas, contratar soporte de terceros y asumir riesgos operativos por la rapidez de la migración.
Computer Weekly añade que Tesco empezó los trabajos de migración en abril de 2025 y que su objetivo es desplegar una alternativa a VMware en toda la organización antes de finales de 2027. La compañía sostiene que el plazo le genera coste, disrupción y riesgo comercial, especialmente porque también debe reemplazar software mainframe usado en procesos críticos.
El problema ya no es solo VMware: es la dependencia
El origen del conflicto está en un contrato de 2021 por el que Tesco adquirió licencias perpetuas de productos VMware, además de suscripciones y servicios de soporte hasta 2026 con opción de extensión. Tras la compra de VMware por Broadcom, el modelo comercial cambió y Tesco alega que no pudo acceder a los servicios en las condiciones que esperaba. Broadcom rechaza esa lectura.
La tensión económica es evidente. Tesco afirma que una oferta de Broadcom de abril de 2026 planteaba 23,5 millones de dólares, unos 17,4 millones de libras, por un año de VMware Cloud Foundation 9.0 y soporte mainframe. Según el minorista, eso suponía un incremento de alrededor del 175 % respecto a los precios a los que entendía tener derecho para VMware y del 350 % para productos mainframe.
Más allá del pleito, el mensaje para el mercado es claro: cuando una plataforma de virtualización se convierte en una capa crítica durante años, salir de ella deja de ser una simple sustitución de hipervisor. Hay que revisar backups, redes, automatizaciones, monitorización, seguridad, DR, licencias, appliances, integraciones y soporte.
Tesco no está describiendo un cambio cómodo. Está diciendo que la salida exige trabajar “a un ritmo excepcional”, con soporte de terceros y con una alternativa que, según sus escritos, no encaja de forma directa con herramientas de protección de datos que ya usaba, como Veeam y Zerto.
La migración con bajo riesgo empieza mucho antes del corte
La lectura técnica no debería ser que cualquier empresa puede apagar VMware un viernes y arrancar en otra plataforma el lunes. La lectura correcta es que la salida se puede hacer con riesgo mínimo si se planifica bien.
David Carrero, cofundador de Stackscale (Aire), empresa especializada en infraestructura cloud privado y Proxmox, lo plantea desde una visión práctica: la migración no debe abordarse como una huida, sino como un proyecto de continuidad. Inventario, diseño, pilotos, oleadas, reversión y soporte deben estar definidos antes de mover cargas críticas.
Ese enfoque cambia la conversación. No se trata de elegir Proxmox VE, Hyper-V, OpenShift Virtualization, XCP-ng, Nutanix u otra alternativa mirando solo el coste de licencia. Se trata de comprobar qué cargas se pueden mover, qué funciones de VMware se usan de verdad y qué dependencias no tienen equivalente directo.
| Área a revisar | Pregunta clave antes de migrar |
|---|---|
| Cargas de trabajo | ¿Qué VM son críticas, legacy, appliances o candidatas a reconstrucción? |
| Red | ¿Se usa NSX, microsegmentación, BGP, overlay, DFW o reglas por etiquetas? |
| Almacenamiento | ¿Hay vSAN, SAN externo, NFS, iSCSI, Ceph, ZFS o cabinas dedicadas? |
| Backup y DR | ¿La herramienta actual soporta la nueva plataforma con el mismo nivel funcional? |
| Automatización | ¿Qué scripts, APIs, Terraform, Ansible o pipelines dependen de vCenter? |
| Soporte | ¿Quién responde ante una incidencia en producción? |
| Operación | ¿El equipo domina Linux, KVM, Ceph, redes y troubleshooting del nuevo stack? |
La discusión técnica alrededor del caso refleja precisamente esos puntos: NSX y su firewall distribuido son difíciles de sustituir uno a uno, Proxmox resulta atractivo para muchos entornos, Hyper-V encaja donde ya existe una fuerte inversión en Microsoft, Nutanix reduce fricción inicial pero mantiene dependencia de proveedor, y XCP-ng aparece como opción en determinados nichos. La conversación también muestra dudas reales sobre SDN, microsegmentación, compatibilidad con Veeam/Zerto y costes de salida de cada plataforma.
Proxmox gana terreno, pero no sustituye todo de forma automática
Proxmox VE se ha convertido en una de las alternativas más comentadas porque combina KVM, LXC, almacenamiento definido por software, red, clúster, alta disponibilidad y herramientas de recuperación en una plataforma abierta. Su documentación oficial lo presenta como una solución completa de virtualización empresarial open source, con gestión web y soporte para máquinas virtuales y contenedores.
Además, Proxmox ha mejorado justo en el punto que más interesa a los clientes de VMware: la migración. Desde Proxmox VE 8.2 existe un importador integrado para mover VM desde VMware ESXi mediante la interfaz web y la API, lo que reduce parte del trabajo manual que antes obligaba a convertir discos y reconstruir configuraciones a mano.
El soporte de terceros también está madurando. Veeam ya incluye documentación específica para Proxmox VE dentro de Backup & Replication, con requisitos y compatibilidades propias. Eso no significa que todas las funciones de VMware estén replicadas al mismo nivel ni que cualquier entorno pueda migrar sin cambios, pero sí elimina una de las objeciones clásicas a Proxmox en empresas que dependen de herramientas de backup consolidadas.
La cautela sigue siendo necesaria. Proxmox no es “VMware gratis”. Es otra forma de operar infraestructura. En VMware, muchas complejidades quedan empaquetadas dentro de vCenter, ESXi, vSAN, NSX y el ecosistema de partners. En Proxmox, el administrador está más cerca de Linux, KVM, Ceph, ZFS, bridges, VLAN, firewalling y almacenamiento. Eso puede ser una ventaja enorme para equipos con experiencia, pero un riesgo si se subestima.
El verdadero coste está en las funciones que se dan por hechas
Uno de los grandes aprendizajes del caso Tesco es que el hipervisor no vive solo. Muchas empresas no dependen de VMware únicamente para ejecutar VM. Dependen de su red, su ecosistema, sus APIs, sus herramientas de backup, sus mecanismos de DR, sus integraciones con fabricantes y sus procedimientos internos.
Por eso la salida debe dividirse por capas.
| Función en VMware | Riesgo habitual al migrar | Cómo reducirlo |
|---|---|---|
| vCenter | Automatizaciones y procesos dependientes de API | Inventario de scripts, jobs y herramientas antes del piloto |
| ESXi | Diferencias de drivers, controladoras y arranque | Pruebas por sistema operativo y tipo de appliance |
| vSAN | Cambio de modelo de almacenamiento | PoC con cargas reales y pruebas de fallo |
| NSX | Microsegmentación y troubleshooting avanzado | Rediseño de seguridad, no copia directa de reglas |
| Backup | Funciones no equivalentes en la nueva plataforma | Validar restauración, no solo backup |
| DR | RPO/RTO distintos | Pruebas de recuperación documentadas |
| Soporte | Cambio de interlocutor y SLA | Contrato claro con fabricante, integrador o MSP |
El peor error es pensar que una migración de VMware es un proyecto de conversión de discos. Es un proyecto de arquitectura. Hay VM que se migran, VM que se reconstruyen, appliances que conviene reemplazar, servicios que pueden moverse a contenedores y cargas que quizá deben quedarse temporalmente en VMware hasta encontrar una alternativa sólida.
Salir de VMware no significa caer en otra trampa
La reacción natural ante una subida de precios es buscar el reemplazo más rápido. Pero una salida precipitada puede llevar a otro bloqueo. Migrar de VMware a una plataforma cerrada, sin evaluar costes futuros, soporte, roadmap, compatibilidad y portabilidad, puede resolver el problema de 2026 y crear otro en 2029.
Por eso muchas empresas están comparando varios caminos: Proxmox para cloud privado y virtualización abierta, Hyper-V o Azure Local si ya existe una fuerte base Microsoft, OpenShift Virtualization si Kubernetes es el eje de la estrategia, Nutanix si se prioriza una HCI muy empaquetada, o XCP-ng en entornos que valoran un stack abierto basado en Xen.
No hay una respuesta universal. Sí hay una regla común: la alternativa debe elegirse por carga, no por moda. Un clúster de retail edge no tiene los mismos requisitos que un datacenter con NSX, un entorno de administración pública aislado, una plataforma SaaS o una pyme con tres hosts y cabina compartida.
La oportunidad: recuperar control sobre la infraestructura
El caso Tesco muestra los riesgos de dependencia, pero también una oportunidad. Muchas organizaciones han mantenido VMware durante años porque funcionaba, no porque hubieran revisado si seguía siendo la mejor opción para cada carga. La presión de Broadcom está obligando a hacer ese análisis.
Bien ejecutada, una migración puede reducir costes, simplificar entornos, eliminar deuda técnica, mejorar backups, limpiar VM abandonadas, rediseñar redes y separar mejor los servicios críticos. También puede abrir la puerta a cloud privado europeo, bare-metal, Proxmox gestionado, modelos híbridos y arquitecturas más transparentes.
La clave está en no confundir urgencia con improvisación. Tesco está corriendo porque su calendario contractual y judicial le empuja. Otras empresas todavía tienen margen. Ese margen debería usarse para hacer inventario, montar pilotos, probar restauraciones, definir soporte y migrar por oleadas.
Salir de VMware es posible. Hacerlo con bajo riesgo exige aceptar una realidad menos vistosa: la migración empieza meses antes de mover la primera VM.
Preguntas frecuentes
¿Qué está haciendo Tesco con VMware?
Tesco ha decidido migrar fuera de VMware y de productos mainframe de Broadcom mientras mantiene una demanda por el conflicto de licencias y soporte.
¿Por qué el caso Tesco importa al mercado?
Porque muestra que incluso una gran empresa con sistemas críticos puede iniciar una salida de VMware, aunque el proceso sea caro, complejo y arriesgado si se hace bajo presión.
¿Proxmox puede sustituir a VMware?
Puede hacerlo en muchos escenarios, especialmente en cloud privado, pymes, proveedores y entornos con equipos técnicos fuertes. Pero no sustituye automáticamente funciones avanzadas como NSX o ciertos flujos de DR.
¿Cuál es el mayor riesgo al migrar?
No suele ser el hipervisor, sino las dependencias: red, backup, almacenamiento, automatización, seguridad, appliances y soporte.
¿Cómo se reduce el riesgo de una migración?
Con inventario, piloto, oleadas, pruebas de restauración, plan de reversión, soporte definido y una arquitectura de destino diseñada antes de mover cargas críticas.
