Situación del cliente
Uno de los principales grupos energéticos españoles —con actividades en generación, distribución y comercialización— operaba su landscape SAP (HANA, BW y S/4HANA) sobre infraestructura on-premise en equipamiento propio con contratos de mantenimiento de hardware en proceso de renovación. El coste total de propiedad del entorno SAP crecía año a año sin mejoras equivalentes en capacidades analíticas o velocidad de desarrollo.
La dirección TI necesitaba una decisión fundamentada sobre si migrar a Azure representaba una oportunidad real de reducción de costes y ganancia de agilidad, o si existían restricciones técnicas o regulatorias que lo desaconsejaran para las cargas de mayor criticidad operativa del grupo.
Retos
- Analizar el entorno SAP completo (HANA, BW, S/4HANA) con inventario exhaustivo de sistemas, integraciones, personalizaciones y dependencias técnicas con sistemas no-SAP
- Realizar el sizing correcto en Azure, determinando qué cargas requieren Azure Large Instances (HANA scale-up/scale-out) y cuáles pueden ejecutarse sobre VMs estándar optimizadas para memoria
- Cuantificar el TCO comparativo real entre el modelo legacy on-premise y las opciones de Azure, incluyendo costes ocultos (actualizaciones de hardware, licencias, personal de operaciones)
- Definir la estrategia de datos para los volúmenes históricos de BW y la gestión de datos activos vs. archivo en Azure Data Lake durante y después de la migración
- Identificar el impacto de la migración en las integraciones con los sistemas de control operacional (SCADA, EMS) del grupo, que tienen requisitos de latencia muy exigentes
Solución implementada
- Assessment de infraestructura SAP: inventario completo de sistemas, análisis de utilización de recursos (CPU, memoria, IOPS) durante 90 días, identificación de personalizaciones críticas y dependencias de integración
- Sizing en Azure Large Instances: dimensionado de cargas HANA scale-up sobre Azure Large Instances (M-series) con análisis de coste por hora vs. reservas de 1 y 3 años, comparado con alternativas de escala horizontal
- Análisis TCO comparativo: modelo financiero a 5 años que comparaba el coste total (hardware, licencias, CPD, personal) del modelo actual frente a tres escenarios Azure: lift-and-shift, optimización en nube y modernización a S/4HANA
- Estrategia de datos para migración BW: definición del modelo de datos históricos (Azure Data Lake Storage Gen2 + Synapse Analytics) para mantener accesibilidad a históricos sin migrar el volumen completo a HANA en Azure
- Plan de transición de operaciones: diseño de la nueva organización operativa SAP en Azure, herramientas de monitorización (Azure Monitor + SAP Solution Manager) y plan de formación para el equipo de basis
Ventajas para el cliente
−30% TCOpotencial de reducción de coste total de propiedad identificado respecto al modelo legacy, gracias al rightsizing, reservas Azure y eliminación de renovaciones de hardware
Assessment completoinventario técnico exhaustivo del landscape SAP que sirvió también como activo de conocimiento para el equipo interno y base para negociar con SAP la renovación de licencias
Decisión fundamentadael Comité Ejecutivo dispuso de un análisis comparativo objetivo con tres escenarios cuantificados para tomar la decisión de migración con base financiera y técnica sólida
Plan de transiciónhoja de ruta detallada de migración por fases, minimizando el riesgo operativo en los sistemas de liquidación del mercado eléctrico durante la transición
Patrón de arquitectura
// ARCH 15 · Azure · SAP
SAP HANA on Azure — RISE with SAP + Large Instances
Arquitectura de referencia para migración SAP HANA a Azure en sector energético: HANA Large Instances (BareMetal Azure) para cargas críticas de análisis energético, S/4HANA en M-series con Proximity Placement Groups, HSR multi-AZ para alta disponibilidad, Azure NetApp Files para HANA volumes y blueprint de migración RISE with SAP con potencial de reducción de TCO del 30%.
HANA Large InstancesM-series VMsAzure NetApp FilesRISE with SAPAzure Monitor
// Consideraciones de despliegue · SAP on Azure WAF
- Proximity Placement Groups son obligatorios para S/4HANA + app tier — la latencia entre la capa de aplicación SAP y HANA Large Instances es crítica. Sin PPG, los workloads de cierre contable en energía fallan con timeouts de RFC en horas punta.
- Sizing de HANA Large Instances basado en carga real, no en hardware on-prem — el hardware on-prem de SAP en energía suele estar sobredimensionado 40-60%. En este assessment identificamos que el Type II equivalente era el tipo correcto para el perfil de carga real de HANA BW.
- Azure NetApp Files Ultra para volúmenes HANA — la latencia de ANF Ultra (<1ms) es la única opción certificada por SAP para HANA data y log volumes en Azure. Premium tier no cumple los requisitos de latencia de HANA en cargas de energía con grandes volúmenes de series temporales.
- HANA System Replication + Azure Load Balancer para HA — la configuración de HSR en modo SYNC dentro de la misma región Azure con ILB para virtualización de IP de HANA es el patrón certificado. No usar ILB floating IP con HANA LI directamente.
- Backup con Azure Backup for SAP HANA, no snapshot-based — los snapshots de VM no son una solución de backup válida para HANA. Azure Backup for SAP HANA usa Backint y garantiza consistencia a nivel de base de datos con punto de recuperación definible.
- RISE with SAP requiere assessment de integraciones antes de comprometerse — en este sector energético, los sistemas LIMS y SCADA tienen integraciones con SAP PI/PO que no son directamente compatibles con BTP Integration Suite. El assessment de interfaces fue la parte más larga del proyecto.
RendimientoFiabilidadCosteExcelencia Operacional