El problema real: no es VMware, es el modelo de licenciamiento
Cuando en 2023 Broadcom completó la adquisición de VMware, el primer movimiento fue discontinuar las licencias perpetuas. El nuevo modelo VCF (VMware Cloud Foundation) y VVF (VMware vSphere Foundation) opera bajo suscripción anual, con agrupaciones de productos que obligan a contratar servicios no utilizados y con requisitos mínimos de nodos que penalizan los entornos medianos.
El impacto en el presupuesto de una organización con infraestructura VMware on-premise de tamaño medio —200-500 VMs, dos CPDs— es directo: la renovación de licencias que costaba 150.000-200.000€ anuales bajo el modelo perpetual pasa a 450.000-700.000€ bajo VCF. Sin cambios en la infraestructura. Sin nuevas capacidades. Solo el cambio de modelo comercial.
Esta es la razón por la que los proyectos de migración a VMware cloud han pasado de ser decisiones estratégicas a largo plazo a conversaciones urgentes de 90 días. No es un debate sobre cloud versus on-premise. Es un debate sobre si tiene sentido seguir pagando las nuevas condiciones de Broadcom o si hay una alternativa económicamente justificable.
El punto de partida correcto: antes de evaluar opciones cloud, calcular el TCO de renovar con Broadcom a 3 años con el nuevo modelo. Ese número es el benchmark contra el que comparar. En todos los proyectos que hemos analizado, la migración a cloud sale favorable a partir del año 2 o 3, especialmente si se incluyen Reserved Instances de 1 o 3 años en el cálculo cloud.
Las tres opciones: stack idéntico, ecosistema diferente
El primer punto que hay que establecer con claridad antes de entrar en la evaluación técnica es que AVS (Azure VMware Solution), VMC on AWS (VMware Cloud on AWS) y GCVE (Google Cloud VMware Engine) ofrecen el mismo stack de virtualización: vSphere como hipervisor, vCenter como plano de gestión, NSX-T como red definida por software, vSAN como almacenamiento distribuido y HCX como herramienta de migración.
La diferencia no está en qué VMware obtienes. La diferencia está en dónde vive ese VMware y con qué ecosistema de servicios nativos puedes integrarlo después.
| Dimensión | AVS (Azure) | VMC on AWS | GCVE (Google) |
|---|---|---|---|
| Stack VMware | vSphere · vCenter · NSX-T · vSAN · HCX Advanced | vSphere · vCenter · NSX-T · vSAN · HCX Advanced | vSphere · vCenter · NSX-T · vSAN · HCX Enterprise |
| Soporte VMware | Microsoft (single vendor) | Broadcom + AWS (dual vendor) | Google + Broadcom (dual vendor) |
| Nodos | AV36P · AV64 (mínimo 3 nodos) | i3.metal · i4i.metal (mínimo 2 nodos) | n1-highmem-96 equiv. (mínimo 3 nodos) |
| Escalado dinámico | Manual (Elastic SAN en preview) | Elastic DRS único | Manual |
| Conectividad nativa | ExpressRoute Global Reach a Azure | ENI (Elastic Network Interface) directa a VPC | Cloud Interconnect a GCP |
| HCX incluido | HCX Advanced | HCX Advanced | HCX Enterprise (replica, DR) |
| Diferenciador | Ecosistema Azure (Entra ID, Defender, Sentinel, Purview) | Elastic DRS · profundidad AWS | HCX Enterprise · BigQuery / Vertex AI |
La única diferencia técnica relevante que no es de ecosistema es el escalado dinámico de nodos. VMC on AWS tiene Elastic DRS, un mecanismo que añade o elimina nodos automáticamente en función del consumo de recursos, algo que AVS y GCVE no tienen en producción estable a fecha de este artículo. Si la carga de trabajo tiene picos de consumo muy pronunciados y predecibles, VMC on AWS tiene una ventaja operativa real en ese punto.
Para el resto de decisiones, el factor determinante es: ¿qué plataforma cloud ya estás usando para el resto de tu infraestructura? Añadir un segundo proveedor cloud principal por una capa de VMware que desaparecerá gradualmente a medida que se modernicen las aplicaciones es casi siempre un error de arquitectura a 3-5 años vista.
La migración con VMware HCX: cómo funciona realmente
VMware HCX (Hybrid Cloud Extension) es la herramienta que hace posible la migración lift & shift de VMs desde un entorno vSphere on-premise a cualquiera de las tres plataformas cloud sin instalar agentes en las VMs, sin modificar las aplicaciones y con mínima ventana de mantenimiento. Entender cómo funciona internamente es importante para dimensionar el proyecto correctamente.
HCX tiene cuatro componentes principales que se despliegan en pares: uno en el datacenter origen y uno en la plataforma cloud destino.
Para entornos de producción con más de 50 VMs, la combinación que mejor funciona es Bulk Migration para la mayoría de las VMs (sincronización en background, switchover de minutos) y RAV para las VMs más críticas que requieren zero downtime real. El vMotion remoto puro —sin pre-sincronización— solo tiene sentido para migraciones individuales de máquinas críticas en ventanas de mantenimiento muy cortas.
sin refactoring
descomisionado
en VMs origen
Los seis puntos técnicos que determinan el éxito del proyecto
Estos son los seis factores técnicos que, en la práctica, marcan la diferencia entre una migración que cumple el calendario y una que se atasca. No son consideraciones de diseño abstractas: son los problemas concretos que aparecen en producción.
La hoja de ruta de 3 fases que usamos
El proyecto que usamos como referencia tenía 200+ VMs distribuidas en 2 CPDs, con sistemas ERP/MES/SCM interdependientes, NSX-V, y un deadline fijo: el datacenter arrendado terminaba contrato a los 12 meses. Aquí está la secuencia que funcionó.
Fase 1 — Piloto y validación (meses 1-3): desplegar el entorno AVS mínimo (3 nodos AV36P), configurar ExpressRoute Global Reach desde on-premise, desplegar HCX en ambos lados, migrar 15-20 VMs no críticas del entorno de test. El objetivo de esta fase no es migrar capacidad: es validar el pipeline de migración, medir latencias reales, detectar los problemas de NSX-V→NSX-T, y entrenar al equipo de operaciones en el nuevo plano de gestión. Cualquier problema que aparezca aquí es preferible a que aparezca en la fase 2.
Fase 2 — Evacuación de CPDs (meses 4-8): migración por olas ordenadas por el mapa de dependencias. Cada ola sigue la secuencia: auditoría de dependencias → pre-sincronización en background (Bulk Migration) → ventana de cutover por ola → retirada de extensión L2 → validación funcional. En esta fase se añaden nodos AVS según la carga real medida en el piloto. El equipo de operaciones gestiona vCenter AVS directamente desde el primer día.
Fase 3 — Optimización (meses 9-12): todas las VMs en AVS, CPDs on-premise desconectados. Esta fase se centra en tres actividades: ajuste de sizing de nodos (rightsizing basado en métricas reales de los primeros meses cloud), activación de Reserved Instances de 1 o 3 años para los nodos de capacidad base, y primera ronda de modernización selectiva — identificar las aplicaciones candidatas a refactoring futuro a PaaS/IaaS nativo, que ya no necesitarán el hipervisor VMware.
El riesgo más frecuente en la fase 2: extender el calendario de migración porque las olas "se complican" y perder la presión del deadline. En todos los proyectos con deadline fijo (contrato de datacenter, fin de soporte), el deadline ha sido el factor que mantuvo el ritmo. Sin él, las migraciones se alargan entre 2 y 4 veces lo planificado. Si no hay deadline externo, créalo: define una fecha de apagado del último nodo on-premise y trátala como compromiso contractual interno.
El argumento financiero en tres números
Para llevar este proyecto a un comité de dirección, el modelo financiero tiene que responder a tres preguntas con números, no con porcentajes: ¿cuánto cuesta renovar con Broadcom en el nuevo modelo? ¿Cuánto cuesta la operación AVS a 3 años con Reserved Instances? ¿Cuándo cruzan las curvas?
En el caso de referencia de este artículo, los números eran: renovación Broadcom bajo VCF = 480.000€/año. AVS con 6 nodos AV36P base + Reserved Instances 3 años = 310.000€/año incluyendo ExpressRoute y soporte. La diferencia en el año 1 es negativa (hay coste de implementación de ~80.000€). A partir del año 2, el ahorro acumulado es positivo. A 3 años, el delta total es de +280.000€ a favor de la migración.
Estos números no son universales. Dependen del tamaño del entorno, de la región Azure, de si se usan Reserved Instances y de si se negocian Enterprise Agreement con Microsoft. Pero la estructura del argumento es siempre la misma: el punto de cruce está entre el año 1 y el año 2, y a 3 años la migración es sistemáticamente más barata que renovar con Broadcom bajo el nuevo modelo.
Un detalle que cambia el modelo financiero: las VMs migradas a AVS ya no necesitan licencias vSphere separadas. Las licencias están incluidas en el precio del nodo AVS. Si el entorno on-premise tenía licencias vSphere separadas de los nodos físicos (licenciamiento por procesador), ese ahorro adicional puede ser significativo y no siempre aparece en los comparativos iniciales.
Lo que viene después de VMware cloud: la modernización selectiva
AVS y sus equivalentes cloud son un destino de transición, no un destino final. La arquitectura correcta a 5 años es: migrar todo con HCX sin refactoring (cero riesgo, cero reescritura), y después identificar selectivamente las aplicaciones que tienen sentido mover a servicios nativos cloud.
No todas las aplicaciones necesitan modernizarse. Los sistemas ERP legacy que corren en vSphere desde hace 15 años y que el fabricante no tiene previsto certificar en contenedores pueden quedarse en AVS indefinidamente, aprovechando las integraciones nativas de Azure (Entra ID, Defender for Cloud, Azure Monitor) sin cambiar una línea de código. El valor de AVS a largo plazo no es ser el paso previo a la reescritura. Es ser la plataforma donde esas aplicaciones conviven con los nuevos servicios cloud nativos bajo un único plano de gestión.
La modernización que sí tiene sentido priorizar son las aplicaciones con componentes claramente separables: el backend de un sistema que ya expone APIs puede tener su capa de integración migrada a Azure API Management o Azure Functions mientras el core sigue en una VM AVS. La base de datos de un sistema de analítica puede moverse a Azure SQL MI o Fabric mientras la aplicación OLTP permanece en la VM. Estas modernizaciones parciales son las que entregan valor rápido sin el riesgo de una reescritura completa.