El costo real de seguir en VMware

Tesco no está hablando de un ajuste menor. Está hablando de mover 40,000 workloads de servidor fuera de VMware. Ese número, por sí solo, ya te dice que no se trata de una actualización de rutina ni de una prueba piloto. Es una operación enorme, con riesgo real para la continuidad del negocio, para el presupuesto y para el equipo de infraestructura que la tiene que ejecutar.

Y el caso no es solo de Tesco. Lo que está pasando ahí resume una tensión que muchas empresas ya sienten: seguir en VMware se volvió caro, rígido y difícil de defender ante finanzas y dirección. Cuando el proveedor cambia las reglas, sube precios o aprieta contratos, tú no solo pagas más. También pierdes margen para negociar, para planificar y para reaccionar si tu arquitectura depende demasiado de una sola plataforma.

Qué pasó con Tesco y por qué importa

Según el reportaje de Ars Technica y los comentarios recogidos en torno al caso, Tesco decidió mover decenas de miles de cargas de trabajo fuera de VMware en medio de un conflicto con Broadcom por prácticas contractuales y comerciales que la empresa considera abusivas. No es una queja aislada de un administrador de sistemas molesto. Es una señal de que una de las cadenas de retail más grandes del Reino Unido vio suficiente riesgo como para iniciar una migración masiva.

Cuando una empresa como Tesco toma una decisión así, no lo hace por moda tecnológica. Lo hace porque el costo de quedarse supera el costo de salir. Y ese cálculo no se limita a licencias. Incluye soporte, renovaciones, cambios de SKU, presión comercial, dependencia de herramientas específicas y el costo operativo de seguir atado a una plataforma que ya no te da el mismo nivel de previsibilidad.

La cifra de 40,000 workloads también ayuda a poner el problema en escala. En una empresa mediana, hablar de migrar 200 o 500 servidores ya exige coordinación entre infraestructura, aplicaciones, seguridad y negocio. Con 40,000, el reto cambia de categoría: necesitas inventario real, priorización por criticidad, ventanas de mantenimiento, pruebas de compatibilidad y un plan para no romper servicios que el usuario final da por sentados.

Por qué un caso así se vuelve referencia

Tesco sirve como referencia porque combina tres cosas que muchas organizaciones temen al mismo tiempo:

1. Un proveedor con mucho poder de negociación.
2. Un entorno de producción grande y difícil de reemplazar.
3. Una necesidad de salida que no puede detener la operación.

Eso es exactamente lo que hace que el problema sea tan costoso. No estás migrando desde una herramienta pequeña que puedes desinstalar en un fin de semana. Estás moviendo una base instalada que sostiene sistemas de negocio, bases de datos, middleware, herramientas internas y servicios de usuarios.

Además, el caso deja claro algo incómodo: la dependencia tecnológica no siempre se nota cuando todo funciona. Se vuelve visible cuando renuevas contrato, cuando cambian las condiciones o cuando el proveedor decide que tu escala ya no te da poder de negociación.

El costo real no es solo la licencia

Mucha gente mira VMware y piensa primero en el precio por CPU, por core o por suscripción. Pero ese número es solo la punta del iceberg. El costo real incluye todo lo que necesitas para mantener la plataforma viva y todo lo que pierdes si decides salir tarde.

En la práctica, el gasto se reparte en varias capas: licenciamiento, soporte, operación diaria, automatización, observabilidad, capacitación y migración. Si además tu contrato cambió por una adquisición o por un nuevo esquema comercial, el golpe puede ser inmediato. No necesitas esperar a una caída de servicio para sentirlo en el presupuesto.

Te dejo una forma simple de verlo:

La parte más difícil de explicar a dirección es esta: seguir en VMware puede parecer más barato que migrar, hasta que el proveedor cambia el precio otra vez. Entonces descubres que no estabas ahorrando, estabas postergando el costo.

Lo que Broadcom cambió en la ecuación

Desde la compra de VMware por Broadcom, muchas organizaciones han reportado cambios en el modelo comercial, en la forma de empaquetar productos y en la presión para adoptar nuevos contratos. No hace falta exagerar para ver el efecto: si tu costo anual sube y tu flexibilidad baja, tu arquitectura deja de ser solo un tema técnico.

La documentación oficial de VMware sobre productos y licenciamiento está en su portal de soporte y documentación, pero el punto práctico para ti es otro: si tu contrato ya no encaja con tu consumo real, la plataforma empieza a castigar tu presupuesto por el simple hecho de seguir creciendo o incluso por mantenerte estable.

En empresas latinoamericanas, esto pega todavía más fuerte. Muchas operan con presupuestos más ajustados, ciclos de compra más lentos y menos margen para absorber incrementos bruscos. Un alza que en una multinacional se diluye en varias unidades de negocio, en una empresa regional puede obligar a congelar proyectos o recortar otras áreas de TI.

Qué significa migrar 40,000 workloads sin romper nada

Migrar workloads no es mover máquinas virtuales de un hipervisor a otro y listo. En un entorno grande, cada workload tiene dependencias: IPs, DNS, storage, backups, monitoreo, certificados, reglas de firewall, jobs programados y, muchas veces, aplicaciones que nadie documentó bien hace años.

Si piensas en 40,000 workloads, la primera pregunta no es “¿a qué plataforma nos vamos?”. La primera pregunta es “¿qué vive realmente ahí?”. Porque un inventario incompleto te deja fuera de control desde el día uno.

Fases que suelen aparecer en una salida real

Un plan serio de salida suele pasar por estas etapas:

1. Descubrimiento e inventario de workloads, dependencias y criticidad.
2. Clasificación por tipo de carga: stateless, stateful, legacy, tier-1, tier-2.
3. Definición de destino: otro hipervisor, cloud, contenedores o mezcla.
4. Pruebas de compatibilidad y rendimiento.
5. Migración por oleadas, no por salto total.
6. Validación post-migración, con monitoreo intensivo y rollback preparado.

Si alguna de esas fases falta, el riesgo sube. Y si intentas acelerar demasiado, terminas pagando dos veces: una por la migración y otra por corregir lo que se dañó en producción.

Qué cargas son las más difíciles

Las más complicadas no suelen ser las más visibles. Las bases de datos grandes, los sistemas con baja tolerancia a latencia, las aplicaciones con licencias ligadas al entorno y los servicios con ventanas de mantenimiento casi inexistentes son las que más retrasan una salida.

También hay un problema menos glamoroso pero muy real: la gente. Cuando el equipo lleva años operando sobre VMware, conoce sus fallas comunes, sus automatizaciones y sus atajos. Cambiar de plataforma significa reentrenar, rehacer scripts, revisar playbooks y aceptar que durante un tiempo la curva de aprendizaje te va a costar productividad.

Por eso una migración de este tamaño no se mide solo en “servidores movidos”. Se mide en servicios estables, en incidentes evitados y en cuánto tiempo tarda la organización en recuperar la misma confianza operativa que tenía antes.

Cómo se evita que la migración se vuelva un desastre

La salida de VMware no se resuelve con entusiasmo ni con un presupuesto optimista. Se resuelve con disciplina. Si tu empresa está pensando en moverse, lo primero es aceptar que la migración no es un proyecto de infraestructura aislado. Es un programa transversal.

Aquí es donde muchas organizaciones fallan: intentan tratar la migración como si fuera un refresh de hardware. Pero no lo es. Estás cambiando el plano donde corre una parte crítica del negocio. Eso exige gobierno, priorización y métricas claras.

Buenas prácticas que sí reducen riesgo

• Construye un inventario real, no un Excel con nombres bonitos.
• Identifica dependencias de red, almacenamiento y autenticación antes de mover nada.
• Empieza por workloads de bajo riesgo para validar el proceso.
• Define un criterio de éxito por oleada: tiempo de corte, latencia, errores y rollback.
• Reserva capacidad extra en el destino para absorber picos y evitar sobrecarga.
• Documenta cada excepción, porque las excepciones son las que te rompen el calendario.

Si quieres una referencia técnica de planificación de migraciones a la nube o a entornos híbridos, AWS publica guías útiles sobre migración y evaluación de aplicaciones en su documentación oficial: https://docs.aws.amazon.com/migrationhub/latest/ug/what-is-migration-hub.html

No porque tengas que irte a AWS, sino porque la lógica de evaluación y oleadas es aplicable a cualquier salida ordenada de una plataforma de virtualización.

El error más caro: subestimar el estado de las aplicaciones

Una VM no es solo una VM. Puede tener integraciones con sistemas de backup, agentes de seguridad, tareas batch, rutas de red y dependencias con otras máquinas que no aparecen en el hipervisor. Si migras sin validar eso, el problema no será el hipervisor nuevo. Será que la aplicación dejó de comportarse como esperabas.

También conviene separar dos preguntas:

• ¿La carga puede moverse?
• ¿La carga debe moverse ahora?

No todas las workloads tienen el mismo retorno. Algunas se mueven para ahorrar costos. Otras se mueven para reducir riesgo contractual. Otras se quedan temporalmente porque moverlas hoy sería más caro que tolerar el costo actual por unos meses más.

Qué deberían mirar las empresas de LatAm y Ecuador

En Latinoamérica, y también en Ecuador, el caso VMware pega con más fuerza porque los presupuestos suelen ser más sensibles a cualquier cambio de licenciamiento. Además, muchas empresas dependen de socios locales para soporte, lo que agrega otra capa de negociación y tiempos de respuesta.

Si tú administras infraestructura en una empresa regional, no necesitas tener 40,000 workloads para sufrir el problema. A veces basta con 200 VMs críticas y un contrato que ya no cierra. En ese escenario, el impacto no es solo financiero. También puede afectar continuidad operativa, auditorías y planes de modernización que quedaron congelados.

El punto no es demonizar VMware. El punto es reconocer cuándo la dependencia dejó de ser razonable. Si la plataforma sigue siendo útil para tu caso, perfecto. Pero si cada renovación te obliga a improvisar, entonces ya no estás tomando una decisión técnica. Estás administrando una relación de dependencia.

Señales de alerta que ya deberías revisar

• Tu renovación subió y nadie puede explicar bien el nuevo cálculo.
• Tienes workloads antiguas que nadie quiere tocar por miedo a romper algo.
• Tu equipo depende de pocas personas que conocen la plataforma a fondo.
• Las automatizaciones están amarradas a herramientas específicas del stack.
• Finanzas te pide justificar por qué sigues pagando más por lo mismo.

Si varias de esas señales te suenan, conviene abrir el tema antes de que el proveedor te fuerce la conversación.

Tabla resumen

El caso Tesco deja una lección simple: cuando el proveedor cambia las reglas, tu arquitectura también tiene que poder cambiar. Si no, el costo real de seguir en VMware no es solo lo que pagas hoy. Es lo que te obliga a aceptar mañana.