Evaluación y Migración VMware a Cloud
Azure VMware Solution · VMC on AWS · Google Cloud VMware Engine

Empresa del sector industrial con presencia en varios países europeos operaba su infraestructura crítica de producción sobre un parque de más de 200 máquinas virtuales VMware, distribuido entre dos centros de datos propios. La plataforma, construida sobre vSphere, vCenter y NSX-V a lo largo de una década, daba soporte a los sistemas de gestión de la cadena de suministro, ERP, MES y aplicaciones de integración con planta. El modelo de licenciamiento vigente era perpetuo, renovado anualmente en concepto de soporte y mantenimiento.

La adquisición de VMware por parte de Broadcom en 2023 alteró radicalmente este escenario. El fabricante eliminó las licencias perpetuas y migró todo el portfolio a un modelo de suscripción (VCF y VVF), lo que supuso para la organización un incremento de costes de licenciamiento estimado entre el 3x y el 5x sobre la base actual, con un ciclo de renovación que vencía en menos de doce meses. A esto se añadía la necesidad inminente de reemplazar el hardware de uno de los dos CPDs, que llegaba a fin de soporte de fabricante.

La dirección de TI planteó tres alternativas: renovar con el nuevo modelo de licenciamiento de Broadcom (incremento de coste insostenible a largo plazo), refactorizar las aplicaciones hacia contenedores o PaaS cloud-native (plazos y riesgo inaceptables para sistemas críticos de producción), o migrar el parque VMware a una de las plataformas VMware gestionadas en cloud público. Se encargó la evaluación técnica y económica de las tres opciones de cloud con el objetivo de recomendar la plataforma más adecuada para este entorno concreto.

• Definir un marco de evaluación técnica que permitiera comparar objetivamente Azure VMware Solution (AVS), VMware Cloud on AWS (VMC on AWS) y Google Cloud VMware Engine (GCVE) sobre los mismos ejes: stack VMware incluido, modelo de soporte, conectividad con el CPD on-premise, integración con servicios nativos cloud, sizing de nodos y TCO a tres años
• Diseñar la arquitectura de migración con VMware HCX para trasladar las 200+ VMs sin agentes adicionales, sin refactorización de aplicaciones y con RPO controlado para los sistemas de producción más críticos, manteniendo la continuidad operativa durante la transición
• Evaluar el impacto de la eliminación de NSX-V en el entorno actual y la equivalencia con NSX-T disponible en las tres plataformas cloud, que implicaba revisar las políticas de microsegmentación y los grupos de seguridad distribuidos existentes
• Construir el análisis TCO comparativo a tres años que incluyera el coste real de cada opción: nodos dedicados bare-metal, licencias VMware incluidas en el servicio gestionado (evitando el doble pago con Broadcom), conectividad WAN con los dos CPDs on-premise restantes, y el coste del modelo de integración con los servicios cloud nativos de cada hyperscaler
• Establecer la hoja de ruta de migración por fases que permitiera desalojar el CPD que llegaba a fin de soporte en el plazo comprometido, priorizando las cargas de menor criticidad en las primeras oleadas y dejando los sistemas de producción críticos para las fases finales, una vez validado el entorno cloud

La evaluación se estructuró en cuatro dimensiones para cada plataforma: stack técnico, modelo de soporte y operación, conectividad e integración cloud-native, y TCO a tres años.

// OPCIÓN A — Azure VMware Solution (AVS)

• Stack VMware incluido: vSphere, vCenter, vSAN y NSX-T gestionados íntegramente por Microsoft. El cliente no gestiona la infraestructura de virtualización: Microsoft se encarga de los parches, actualizaciones de VMware y del hardware bare-metal subyacente (nodos AV36P y AV64). Las licencias VMware están incluidas en el precio del nodo, evitando cualquier relación directa con Broadcom para estas cargas
• Conectividad e integración Azure: integración nativa con ExpressRoute para la conectividad con los CPDs on-premise y con el resto del entorno Azure (ExpressRoute Global Reach para conectar el entorno on-premise directamente al SDDC de AVS sin pasar por una VNet gateway). Acceso directo a servicios Azure desde el SDDC: Azure Blob Storage, Azure SQL, Azure Key Vault, Microsoft Entra ID para autenticación de VMs, Azure Monitor y Microsoft Defender for Cloud para visibilidad y seguridad
• Migración: VMware HCX Advanced incluido en el servicio. Extensión L2 de red para preservar IPs en la migración, replicación en caliente (vMotion remoto y Bulk Migration), y Network Extension para mantener la conectividad de los clientes on-premise hacia las VMs migradas a AVS sin cambios de red ni de DNS
• Idoneidad para este entorno: opción más adecuada cuando la organización ya tiene presencia significativa en Azure o planea integrarse con servicios Azure (Azure SQL, Azure AD, Azure Monitor). El soporte lo presta Microsoft directamente, con SLA del 99,9% a nivel de clúster AVS

// OPCIÓN B — VMware Cloud on AWS (VMC on AWS)

• Stack VMware incluido: vSphere, vCenter, vSAN y NSX-T gestionados conjuntamente por VMware (ahora Broadcom) y AWS sobre instancias i3.metal y i4i.metal de AWS. A diferencia de AVS, el interlocutor principal para el soporte del SDDC es Broadcom/VMware, con AWS actuando como proveedor de la infraestructura subyacente. Las licencias VMware están incluidas en el precio del nodo (modelo SDDC por suscripción)
• Conectividad e integración AWS: el SDDC de VMC on AWS reside en la misma Availability Zone que los servicios AWS de la cuenta asociada, lo que permite acceder a S3, RDS, Lambda y otros servicios AWS con latencia de red intra-AZ (sin cruzar Internet). AWS Direct Connect para la conectividad on-premise al SDDC. Transit Gateway para la integración con otras VPCs y regiones AWS
• Migración: VMware HCX Advanced incluido. Mismo modelo de migración que AVS: extensión L2, vMotion remoto y Bulk Migration. Elastic DRS permite escalar automáticamente el número de nodos del SDDC en el momento del failover o de picos de carga, manteniendo un número mínimo de nodos en estado idle para reducir el coste en steady-state
• Idoneidad para este entorno: opción preferible cuando la organización ya tiene servicios significativos en AWS (S3, RDS, servicios de datos) o necesita consumir servicios AWS directamente desde las VMs VMware con latencia mínima. El modelo de soporte dual (Broadcom + AWS) puede generar ambigüedad en la resolución de incidencias cross-stack

// OPCIÓN C — Google Cloud VMware Engine (GCVE)

• Stack VMware incluido: vSphere, vCenter, vSAN y NSX-T gestionados por Google sobre hardware dedicado (nodos standard y highmem). Modelo operativo similar a AVS: Google gestiona la infraestructura VMware, el cliente gestiona las cargas dentro del SDDC. Las licencias VMware están incluidas
• Conectividad e integración GCP: Cloud Interconnect para la conectividad con los CPDs on-premise. Acceso a servicios GCP desde el SDDC mediante Private Service Connect: BigQuery, Cloud SQL, Vertex AI, Cloud Storage. VMware Engine Network peering para integrar el SDDC con las VPCs de GCP de la organización
• Migración: VMware HCX Enterprise incluido (a diferencia de AVS y VMC on AWS que incluyen HCX Advanced, GCVE incluye HCX Enterprise con funcionalidades adicionales como OS Assisted Migration y Network Extension High Availability). Mismo modelo de extensión L2 y migración en caliente
• Idoneidad para este entorno: opción preferible cuando la organización tiene workloads de datos o analítica en GCP (BigQuery, Vertex AI) y necesita integración con esos servicios desde el entorno VMware. En ausencia de presencia previa en GCP, el coste de construir el modelo de integración y operación desde cero es superior al de AVS o VMC on AWS

// RECOMENDACIÓN Y HOJA DE RUTA

• Decisión: Azure VMware Solution como plataforma principal, por tres razones determinantes en este contexto: la organización tenía el mayor footprint en Azure (AD, almacenamiento, backups con Azure Backup), el soporte single-vendor de Microsoft simplificaba el modelo operativo frente al soporte dual de VMC on AWS, y el TCO a tres años fue el más competitivo al incluir las licencias VMware en el precio del nodo sin sobrecoste adicional de Broadcom
• Fase 1 — Piloto y validación (meses 1-3): despliegue del clúster AVS inicial con 3 nodos AV36P, configuración de ExpressRoute desde los dos CPDs on-premise, instalación de VMware HCX y migración de 20 VMs de entornos no productivos para validar latencia, rendimiento y el proceso de extensión L2
• Fase 2 — Migración del CPD en fin de soporte (meses 4-8): migración del 100% de las VMs del CPD con hardware en fin de soporte mediante Bulk Migration de HCX, aprovechando las ventanas de mantenimiento nocturnas. Validación de RPO y RTO reales durante la migración en producción con Network Extension activa para mantener la conectividad
• Fase 3 — Optimización y descomisionado (meses 9-12): migración del segundo CPD o conversión en DR secundario, desactivación de las extensiones L2 de HCX (cutover de red para eliminar el hairpin de tráfico), optimización del sizing de nodos AVS con Azure Reserved Instances a 1 y 3 años, y descomisionado del hardware on-premise

Las tres plataformas ofrecen el mismo stack VMware (vSphere, vCenter, NSX-T, vSAN) en modo gestionado, con licencias incluidas y migración mediante VMware HCX, eliminando en todos los casos el impacto del cambio de modelo de licenciamiento de Broadcom. La diferenciación relevante está en el ecosistema cloud-native de integración, el modelo de soporte y la conectividad con el entorno on-premise. La decisión óptima depende del footprint cloud existente de la organización, no de las capacidades VMware en sí, que son equivalentes entre las tres opciones.