El punto de partida: hardware de 15 años, contratos próximos a expirar
Los grupos industriales con más de 20 años de historia IT tienen todos el mismo problema en 2026: infraestructura crítica —SAP ERP, sistemas MES de control de planta, aplicaciones de gestión de la cadena de suministro— corriendo sobre hardware on-premise envejecido, con contratos de soporte y mantenimiento que expiran en 12-24 meses y cuya renovación requiere una inversión CapEx que el CFO no quiere aprobar.
En este proyecto el escenario era exactamente ese: grupo industrial con plantas en España, Francia y Alemania, 2.800 empleados, infraestructura VMware on-premise de 15 años de antigüedad con 340 VMs y un SAP ERP corriendo en hardware certificado cuyo contrato de soporte expiraba en 18 meses. La alternativa al cloud no era "quedarse como está": era comprar nuevo hardware por 4,2M€ con un ciclo de vida de otros 8 años.
El proyecto tardó 36 meses en completarse en sus tres fases. Cero interrupciones de producción. Reducción del TCO del 40% en los primeros 24 meses respecto al escenario de renovación de hardware. Lo que sigue es una guía práctica de las decisiones técnicas que determinaron ese resultado.
La decisión que más tiempo ahorró: Azure VMware Solution primero
El debate habitual en estos proyectos es "lift & shift vs. modernizar desde el primer día". La respuesta correcta no es una de las dos. Es la secuencia correcta.
Azure VMware Solution (AVS) permite mover las VMs VMware existentes a Azure sin reescribir ninguna aplicación, sin cambiar los procesos operativos del equipo de IT, y sin requerimientos de downtime de aplicación. El equipo sigue gestionando las VMs con vSphere, NSX-T y vSAN exactamente igual que lo hacía on-premise. Para Azure, AVS es una zona especial de instancias bare metal dedicadas que ejecutan el hipervisor VMware nativamente.
La decisión de empezar la Fase 1 con AVS ahorró aproximadamente 18 meses de proyecto. La alternativa habría sido hacer el assessment de cada una de las 340 VMs, rediseñar las que necesitaban cambios de arquitectura para ejecutarse en IaaS nativa de Azure, y gestionar las dependencias entre aplicaciones durante la migración. Con AVS: replicación HCX, validación de conectividad, failover. En producción en semanas, no en meses.
El argumento del purista es que AVS es más caro que IaaS nativa de Azure a largo plazo. Es correcto. AVS cuesta aproximadamente un 35-40% más por VM que un equivalente en IaaS nativa, porque pagas el overhead del hipervisor VMware sobre bare metal dedicado. El contraargumento es el coste de oportunidad: cada mes de migración más rápida tiene un valor financiero. Y la modernización progresiva a IaaS nativa se hace desde un sistema estable en cloud, no desde un datacenter propio que está contrarreloj.
Fase 1 — AVS: las tres semanas que más tensión generaron
La migración HCX de las 340 VMs a AVS duró 11 semanas. Las semanas 5, 6 y 7 —cuando migramos los sistemas MES de la planta de Alemania— fueron las más críticas.
El error del MTU. Los sistemas MES de la planta alemana usaban comunicación UDP de baja latencia entre controladores PLC y el servidor MES para envío de datos de planta en tiempo real. La latencia máxima tolerable era de 8ms. Durante la migración, la latencia subió a 22ms durante 40 minutos en el turno de tarde del día 3 de la semana 6. No llegó a parar la planta —el sistema tiene 30ms de margen antes del failsafe— pero el jefe de planta llamó al CIO a las 11 de la noche.
El origen: el MTU configurado en el túnel HCX era de 1500 bytes. El tráfico UDP de los PLCs con encabezados de encapsulación superaba ese MTU y estaba siendo fragmentado. Resultado: latencia adicional por reassembly. La solución fue ajustar el MTU del túnel HCX a 1450 bytes y activar jumbo frames en el switch de planta. 25 minutos de configuración. Tres semanas de análisis previo que no habíamos hecho correctamente.
La lección: en entornos industriales con sistemas OT, el análisis de latencia y MTU del tráfico de planta es tan crítico como el análisis de disponibilidad de aplicación. No se puede hacer después de empezar la migración.
Fase 2 — SAP on Azure: HANA Large Instances vs. HANA en VMs
La migración de SAP ERP a Azure es donde los proyectos industriales suelen pararse más tiempo en el diseño. La decisión central es la plataforma de cómputo para SAP HANA: Large Instances (HLI) o VMs certificadas (M-series).
HANA Large Instances son servidores bare metal dedicados que Microsoft gestiona como infraestructura certificada por SAP con conectividad ExpressRoute directa al Azure Virtual Network del cliente. Las VMs M-series son instancias de Azure IaaS certificadas por SAP con hasta 11,4 TB de RAM y rendimiento de almacenamiento premium.
Para este proyecto elegimos HLI M128s para el sistema productivo por tres razones concretas: el sistema SAP tenía 6 TB de datos en HANA (por encima del límite práctico de M-series para el perfil de carga de este cliente), el SLA de HLI del 99,99% frente al 99,9% de VM single instance, y la latencia garantizada de almacenamiento de HLI con Azure NetApp Files Ultra frente a los discos Premium SSD de VMs M-series.
El sistema de desarrollo y QA fue a VMs M64s certificadas. Con reservas a 3 años, el coste de M64s para dev/QA es un 58% inferior a HLI del mismo tier. No tiene sentido pagar por HLI en entornos que no tienen requerimientos de producción.
La arquitectura de red: Hub-Spoke con Azure Virtual WAN
Conectar tres plantas industriales en tres países a Azure con latencia predecible y sin atravesar internet público requiere ExpressRoute dedicado. El debate habitual es si usar ExpressRoute por planta o un único circuito centralizado con MPLS corporativo que "salta" a Azure en un único punto.
Elegimos ExpressRoute por planta por razones de latencia y resiliencia. El circuito centralizado añade una hop adicional en el MPLS corporativo: de la planta al hub central, y del hub central a Azure. Para los sistemas MES con tolerancia de 8ms esto era inasumible. Con ExpressRoute por planta la latencia de planta a Azure es directa: España Central tuvo latencias de 2-3ms, Francia Sur 3-4ms, Alemania Oeste 4-5ms.
La topología Hub-Spoke con Azure Virtual WAN permite el ruteo entre las tres plantas a través de los hubs de Azure sin necesidad de circuito MPLS propio entre ellas. El tráfico España-Alemania va España → Hub Azure → Alemania. Con el peering entre regiones de Azure Virtual WAN, la latencia es equivalente a la del circuito MPLS corporativo que tenían antes, con mucho menos coste de gestión.
Fase 3 — OpenShift: modernización sin disrupción
La Fase 3, que arrancó en el mes 15 mientras AVS y SAP ya estaban en producción estable en cloud, fue la modernización de nuevas aplicaciones a contenedores en Red Hat OpenShift sobre Azure.
El punto importante es el "nuevas aplicaciones". No migramos las aplicaciones legacy existentes a contenedores. Las aplicaciones legacy ya corrían estables en AVS. El coste de reescribirlas para contenedores no justificaba el beneficio operativo inmediato. En cambio, todas las aplicaciones nuevas —sistema de gestión de calidad de la nueva planta, aplicación de seguimiento de cadena de suministro, herramienta de reporting operacional— se desarrollaron directamente como aplicaciones cloud-native sobre OpenShift con pipeline CI/CD.
El resultado más valorado por el equipo de desarrollo: el tiempo de provisioning de un nuevo entorno de desarrollo pasó de 3 semanas (aprobación de hardware, instalación, configuración) a menos de 4 horas (despliegue de namespace en OpenShift con cuota de recursos predefinida). Esto no es solo un beneficio operativo. Es un cambio en la capacidad del negocio para experimentar y lanzar funcionalidad nueva.
El modelo financiero que aprobó el Comité de Dirección
El análisis TCO que justificó el proyecto ante el Comité de Dirección comparaba tres escenarios a 5 años: renovación de hardware on-premise, migración cloud con el modelo descrito, y cloud con modernización acelerada (sin Fase 1 de AVS, directamente a IaaS nativa).
Los resultados: renovación on-premise tenía el TCO más bajo en el año 1 (sin inversión cloud) pero el más alto en el año 5 por los costes de operación, mantenimiento y segunda renovación de hardware al final del ciclo. El cloud con AVS tenía inversión inicial más alta pero TCO acumulado a 5 años un 40% inferior al escenario on-premise. La modernización acelerada tenía TCO similar al cloud con AVS pero con un perfil de riesgo de proyecto muy superior: 18 meses adicionales de proyecto, mayor probabilidad de incidencia durante la migración y necesidad de cambios en aplicaciones con riesgo de regresión.
El argumento que cerró la discusión del CFO no fue el TCO. Fue la elasticidad: en el escenario cloud, cuando el grupo adquiera una nueva planta —algo que estaba en el plan de negocio a 3 años— el coste marginal de incorporar la nueva infraestructura a la plataforma existente es una fracción del coste de expandir el datacenter propio. Esa opcionalidad tiene valor financiero aunque no aparezca en el modelo de TCO estático.
Lo que aprendimos sobre migrar entornos industriales a cloud
El sector industrial tiene características que hacen que los playbooks de migración cloud diseñados para el sector servicios fallen en puntos concretos. Los tres que más se repiten:
Los sistemas OT no saben que el cloud existe. Los PLCs, SCADA, MES y sistemas de control de planta fueron diseñados para redes industriales cerradas con protocolos propietarios y tolerancias de latencia deterministas. No se pueden migrar, no se pueden "nativizar". Se pueden conectar a cloud de forma segura y con latencia predecible, pero la conectividad debe diseñarse alrededor de sus requerimientos, no al revés. El análisis de latencia, MTU y patrones de tráfico OT antes de la migración no es opcional.
El SAP Basis team tiene veto real, úsalo a tu favor. En todos los proyectos SAP on Azure que hemos hecho, la mayor fuente de fricción no es técnica. Es la resistencia del equipo SAP Basis que lleva años gestionando el sistema on-premise y que percibe el cloud como una amenaza a su rol. La forma de resolverlo no es "convencerles de que el cloud es mejor". Es incorporarles al diseño de la solución desde el primer día, darles formación en Azure con SAP, y reconvertir su expertise de gestión de hardware en expertise de gestión de plataforma cloud. En este proyecto el SAP Basis Lead acabó siendo el arquitecto principal de la Fase 2 y el más activo evangelizador interno del proyecto.
El failback plan es tan importante como el plan de migración. En entornos industriales de producción 24/7, el Comité de Dirección y los responsables de planta necesitan saber que si algo sale mal en la migración, hay un plan de vuelta atrás ejecutable en menos de 4 horas. HCX permite hacer failback de una VM desde AVS al datacenter on-premise en minutos. El hecho de que tengamos ese plan y de que esté documentado y probado no significa que lo vayamos a usar. Significa que la dirección puede aprobar la migración sin sentir que está apostando la producción a una decisión irreversible.