// 005Sector Industrial · Manufactura

Transformación Legacy
a Cloud-Native

Azure VMware SolutionSAP on AzureHub-SpokeOpenShiftExpressRoute
−40%TCO en 24 meses
0interrupciones de producción
Meses → Semanastime-to-market nuevas apps

Grupo industrial con plantas de producción en España, Francia y Alemania operaba su infraestructura crítica — SAP ERP, sistemas MES de control de planta y aplicaciones de gestión de la cadena de suministro — en un entorno VMware on-premise con hardware propio de más de 15 años de antigüedad. Los contratos de soporte y mantenimiento estaban próximos a expirar y la renovación del hardware requería una inversión CapEx muy elevada.

El equipo de IT no podía seguir el ritmo de demanda del negocio: aprovisionar un nuevo entorno de desarrollo tardaba semanas. La internacionalización del grupo y la apertura de nuevas plantas requerían una plataforma IT más ágil, escalable y con menor dependencia de infraestructura propia.

  • Migrar SAP ERP a cloud garantizando la continuidad de operaciones de producción industrial 24/7 en tres países simultáneamente
  • Mantener la latencia requerida por los sistemas de control de planta (MES, SCADA) que no podían tolerar degradación en comunicaciones
  • Rediseñar la arquitectura de red para soportar conectividad segura de baja latencia entre plantas industriales y cloud
  • Modernizar progresivamente las aplicaciones legacy sin un "big bang" disruptivo que pusiera en riesgo la producción
  • Justificar la inversión ante el Comité de Dirección con un modelo financiero que demostrara la reducción de TCO a medio plazo
  • Fase 1 — Azure VMware Solution (AVS): lift & shift del parque VMware completo sin reescritura de aplicaciones. Continuidad total del servicio durante la migración mediante replicación HCX
  • Fase 2 — SAP on Azure: migración de SAP ERP a Azure con HANA Large Instances y Azure NetApp Files para garantizar los requisitos de performance y latencia de SAP HANA
  • Arquitectura Hub-Spoke con Azure Virtual WAN: conectividad segura y de alta disponibilidad entre las tres plantas industriales y los hubs cloud en cada región
  • ExpressRoute dedicado por planta: conectividad privada de baja latencia entre plantas industriales y Azure, sin atravesar internet público, para cumplir los requisitos de los sistemas OT
  • Fase 3 — Red Hat OpenShift en Azure: modernización progresiva de nuevas aplicaciones a contenedores, con pipeline CI/CD y despliegue automatizado para el equipo de desarrollo
−40%TCO en 24 meses: eliminación de costes de hardware, datacenters propios y contratos de mantenimiento legacy
0 interrupcionesde producción durante toda la migración de 3 años en 3 países y 3 fases tecnológicas
Meses → Semanastime-to-market de nuevas aplicaciones y entornos, gracias a automatización e infraestructura como código
Escalabilidad elásticaCapacidad de escalar recursos de producción según la demanda estacional sin inversión CapEx adicional
// ARCH 06
Cloud-Native Modernisation — Containers & K8s
CI/CD PIPELINE · GitHub Actions · Azure DevOps · Helm · ArgoCD0–6 mesesFASE 1LIFT & SHIFTVMware VMsSAP IaaSAzure VMwareSolution (AVS)HCX Migration6–18 mesesFASE 2REFACTORContainersDocker ImagesHelm ChartsACR RegistryMicroservices18–36 m.FASE 3CLOUD-NATIVEAKS / OpenShiftGitOpsHPA + Cluster ASPrivate APIZone redundancyOBSERVABILIDAD · Azure Monitor · Dynatrace · Prometheus · Grafana

Hoja de ruta de modernización progresiva de legacy a cloud-native: lift & shift inicial con AVS/IaaS, refactoring incremental a microservicios, adopción de Kubernetes/OpenShift y pipelines CI/CD. Sin big bang, sin interrupciones de producción.

AKS / OpenShiftAzure Container RegistryHelm / ArgoCDGitHub ActionsAzure Monitor
// Consideraciones de despliegue · AKS WAF
  1. Estrategia lift-and-shift primero con IaaS — modernizar aplicaciones directamente en cloud es más arriesgado que migrarlas primero y modernizarlas después en entorno cloud estable. Este proyecto usó Azure VMware Solution como trampolín y funcionó.
  2. Clústeres AKS privados con API server allowlist — exponer el API server a internet es un riesgo crítico. El 40% de incidentes en Kubernetes provienen de APIs expuestos o mal configurados.
  3. Node pools dedicados: separar cargas de sistema de aplicación (mínimo 2 nodos por pool). La contaminación de recursos entre workloads afecta la estabilidad del plano de control en producción.
  4. Nodos distribuidos en múltiples Availability Zones — un nodo en zona única es un SPOF para aplicaciones críticas. AZ deployment es gratuito y debería ser obligatorio en producción sin excepción.
  5. Solo imágenes firmadas de registros privados (ACR/Quay) — los ataques de supply chain son el vector de crecimiento más rápido en entornos containerizados a nivel europeo.
  6. Cluster Autoscaler + HPA configurados antes de ir a producción — el escalado manual no es operativamente viable. Sin autoscaling, los picos de tráfico causan indisponibilidad previsible y evitable.
FiabilidadSeguridadRendimientoCoste
Compartir en LinkedIn