Actualizar a VMware Cloud Foundation 9.1 es un paso estratégico que va mucho más allá de introducir versiones en un planificador. Muchos equipos técnicos caen en la tentación de abrir el VCF Upgrade Planner como primera actividad, pero la experiencia demuestra que la verdadera diferencia entre una migración exitosa y un fin de semana de caos está en las decisiones que se toman antes de escribir el primer dato. Esta revisión de preparación no es un trámite burocrático: es el filtro que convierte un plan teórico en una hoja de ruta ejecutable.
En el entorno empresarial actual, donde la infraestructura soporta desde aplicaciones críticas hasta procesos de IA y analítica de negocio, cualquier interrupción no planificada tiene costes directos. Por eso, antes de abordar una actualización de VCF, es imprescindible detenerse y evaluar una serie de factores que el planificador no puede resolver por sí mismo. Ni la herramienta más avanzada sabe quién gestiona el DNS, si las IPs de gestión están reservadas o si el equipo de aplicaciones ha dado su visto bueno al calendario. Ese trabajo pertenece a la revisión de preparación.
Inventario basado en hechos, no en memoria
El primer error común es iniciar la planificación con versiones que 'recordamos' o con capturas de pantalla antiguas. Una revisión de preparación sólida exige un inventario actualizado y verificable. Esto incluye no solo las versiones de vCenter, ESXi, NSX y VCF Operations, sino también el estado de los certificados, la configuración de identidad, la topología de bordes NSX y la presencia de VxRail. Cada dato debe ser confirmado por más de un miembro del equipo y contrastado con fuentes oficiales como SDDC Manager o la interfaz de Aria Operations. Si el inventario es incorrecto, el plan generado será lógicamente coherente pero operativamente inviable.
Clasificar el estado de partida
No es lo mismo actualizar un VCF 5.2.x completo que converger un entorno basado solo en vSphere. Broadcom distingue múltiples rutas de actualización según la configuración inicial: despliegues con SDDC Manager, entornos con NSX, automatización Aria, o incluso VCF 9.0.x con Fleet Management Appliance. Escribir en lenguaje claro la clasificación – por ejemplo, 'dominio de gestión VCF 5.2.x con NSX, vSAN y Aria Operations, sin VxRail' – proporciona contexto que ninguna tabla de productos puede sustituir.
Asignar propiedad con nombres y apellidos
Las actualizaciones de VCF cruzan fronteras de equipo. DNS, red, identidad, backup, licencias y validación de aplicaciones necesitan responsables nominales. No basta con asignar a un departamento. Cada decisión debe tener un propietario principal y un respaldo. En organizaciones donde la tecnología se apoya en socios externos, contar con una empresa como Q2BSTUDIO para el desarrollo de aplicaciones a medida o la integración de sistemas puede marcar la diferencia, ya que su experiencia en software personalizado permite alinear la infraestructura con las necesidades reales del negocio.
Espacio IP, DNS y licencias: los tres pilares olvidados
VCF 9.1 introduce cambios sustanciales en el plano de gestión. Los servicios de gestión requieren entre 12 y 30 direcciones IP nuevas, todas en la red de gestión, y un rango interno 198.18.0.0/15 que no debe solaparse con la red existente. Además, las FQDNs de los nuevos componentes deben ser únicas y resolverse tanto en directa como en inversa, y deben quedar fuera del pool de IPs del runtime. El servidor de licencias centralizado es obligatorio y necesita registros DNS A y PTR. Ignorar estos requisitos durante la planificación es garantía de bloqueos nocturnos. Por eso, antes de abrir el planificador, hay que tener reservadas las IPs, configuradas las zonas DNS y definido el despliegue del licenciamiento. En entornos híbridos con cloud AWS o Azure, estos pasos deben coordinarse con el equipo de infraestructura cloud para evitar conflictos de direccionamiento.
Respaldo y recuperación: no basta con decir 'tenemos backup'
La revisión de preparación debe responder a preguntas concretas: ¿los trabajos de backup están al día? ¿Se conoce el punto de restauración exacto? ¿El método de recuperación es conocido por todo el equipo? ¿Se han verificado las restauraciones? Para VCF, ciertas fases de actualización no tienen retroceso sencillo; algunas requieren intervención de soporte o reconstrucción completa. Un plan de retroceso que solo diga 'restaurar desde backup y esperar' no es un plan, es un deseo. Es mejor definir tres categorías: reintentar (si el error es corregible), pausar (si se puede detener en un punto seguro) y recuperar (cuando se necesita restaurar o reconstruir).
Estrategia de ventanas de mantenimiento
Preguntar '¿cuánto tarda la actualización?' antes de definir las ventanas es un error. Lo primero es decidir cómo se secuencian los cambios: una ventana de preparación, otra para el plano de gestión, otra para red y NSX, otra para cómputo, y finalmente una ventana de validación. Cada fase debe tener un propietario, un alcance, un punto de pausa y una condición de escalado. El planificador de VCF ayuda a determinar la secuencia técnica, pero no puede negociar con los dueños de las aplicaciones ni ajustar los calendarios a los ciclos de negocio. La comunicación con los stakeholders debe comenzar semanas antes, no cuando el equipo técnico ya ha comprometido fechas.
Proteger las cargas de trabajo durante el proceso
Una actualización de VCF es un evento de plataforma, pero las aplicaciones lo viven como un riesgo. Antes de empezar, hay que confirmar que los clusters tienen capacidad para mantenimiento, que DRS se comporta según lo esperado, que la evacuación de hosts es realista y que los trabajos de backup no coinciden con la ventana. En entornos con aplicaciones sensibles a la latencia o con segmentación de seguridad estricta, es imprescindible involucrar a los equipos de aplicaciones y ciberseguridad desde el inicio. Soluciones como los agentes IA para monitorización inteligente o los cuadros de mando con Power BI pueden ayudar a visualizar el estado de salud durante la transición, pero deben estar configurados antes del cambio.
El plan de comunicación como requisito técnico
El silencio durante una actualización de plataforma genera ansiedad. Un plan de comunicación debe definir hitos: dos semanas antes (intención y alcance), una semana antes (confirmación de ventana), 24 horas antes (recordatorio de congelación), inicio de ventana, checkpoints de fase, finalización y resumen post-evento. Cada mensaje debe tener un responsable, un canal y un contenido predefinido. Las empresas que integran herramientas de automatización y BI para seguir el progreso en tiempo real reducen el ruido y mejoran la confianza del negocio. En este sentido, Q2BSTUDIO ofrece soluciones de software a medida que permiten orquestar estos flujos de comunicación y monitorización adaptados a cada organización.
Conclusión: la actualización aburrida es la exitosa
El VCF Upgrade Planner es una herramienta excelente para traducir la fotografía actual en una ruta técnica. Pero su valor depende completamente de la calidad de los datos que recibe. Las decisiones difíciles –inventario, propiedad, IP, DNS, licencias, backup, ventanas, retroceso y comunicación– deben tomarse antes de abrir el planificador. Cuando el equipo ejecuta un plan que ya ha sido desafiado y resuelto, la ventana de mantenimiento transcurre sin sobresaltos. Una actualización aburrida es señal de que el trabajo duro se hizo al principio. Y eso, en infraestructura crítica, es el mayor éxito posible.
