Azure se encuentra con SAP: SAP en Azure explicado para Microsoft Teams

By Mirko Peters · 2026-11-05

Qué significa realmente ejecutar SAP en Microsoft Azure: máquinas virtuales y almacenamiento certificados, la landing zone que construyes primero, la conectividad híbrida, los tres caminos de despliegue y los errores que convierten un sistema SAP soportado en uno no soportado.

Automatically translated with AI from the original post. Read the English original

Como Microsoft MVP, paso la mayor parte de mi tiempo con personas que conocen Azure, Entra ID y Microsoft 365 a fondo, y que de repente reciben el encargo de "dar soporte a la migración de SAP". Para muchas de ellas, SAP parece un universo aparte, con vocabulario propio. La buena noticia es que SAP en Azure es mucho más corriente de lo que parece. Se reduce a dos reglas: mantente dentro de configuraciones certificadas y construye la base antes de que llegue el primer sistema SAP. Este artículo recorre ambas, en el orden en que realmente trabajarías.

Qué significa realmente SAP en Azure

SAP en Azure significa que tus sistemas SAP se ejecutan en Microsoft Azure. La base de datos SAP HANA, los servidores de aplicaciones y los servicios centrales residen en máquinas virtuales de Azure y utilizan el almacenamiento y la red de Azure. El software SAP en sí no cambia: SAP S/4HANA sigue siendo S/4HANA y SAP NetWeaver sigue siendo NetWeaver. Solo cambia la base sobre la que se ejecutan.

Esa división te indica quién es responsable de cada cosa. Microsoft proporciona la plataforma: máquinas virtuales, discos, redes, identidad y monitorización. SAP proporciona la aplicación y la base de datos, y tú las operas como SAP espera. El punto donde se encuentran ambos es la infraestructura certificada que hay en medio.

Conviene separar esto de un segundo tema relacionado. Copiar datos de SAP a Azure para generar informes en Power BI o Microsoft Fabric es integración de datos, un trabajo útil pero distinto. Ejecutar SAP en Azure significa que el sistema de producción en sí vive allí, procesa sus transacciones allí y da servicio a sus usuarios desde allí.

Si primero quieres la visión general de la familia de productos SAP, la página de temas de SAP en M365.FM reúne nuestro contenido relacionado.

Por qué "certificado" lo decide todo

En el mundo SAP, "se ejecuta en Azure" significa realmente "se ejecuta en Azure certificado". SAP y Microsoft prueban tipos concretos de máquinas virtuales y opciones de almacenamiento frente a productos y escenarios SAP específicos, y solo se soportan esas combinaciones. Microsoft documenta las certificaciones y configuraciones de SAP para Azure y el software SAP soportado en Azure. Para SAP HANA, el propio HANA Hardware Directory de SAP es la lista de referencia; para sistemas basados en NetWeaver, la nota SAP 1928533 enumera los tipos de máquina virtual de Azure soportados.

La certificación no es una propiedad de Azure en su conjunto. Es una propiedad de una máquina virtual concreta, una opción de almacenamiento concreta y un escenario SAP específico, alineados entre sí. Una máquina virtual generosa que es perfecta para una aplicación web puede sencillamente no estar en la lista para HANA. Si la eliges igualmente, no has ahorrado dinero: has construido un sistema que ninguno de los dos proveedores está dispuesto a respaldar.

El almacenamiento sigue la misma lógica. Los discos administrados de Azure son el componente básico del día a día, Azure NetApp Files proporciona almacenamiento NFS que se usa en varias arquitecturas de SAP, y Azure Files con almacenamiento premium (SSD) puede alojar directorios compartidos. El nivel estándar, más barato, de Azure Files no es compatible con los recursos compartidos de alta disponibilidad de los servicios centrales de SAP, así que la opción barata es la incorrecta en ese caso. Microsoft recoge estos límites en sus escenarios admitidos para cargas de trabajo de SAP en máquinas virtuales de Azure.

El hábito que evita la mayoría de los problemas: antes de dimensionar una sola máquina, consulta la lista certificada de tu producto y escenario de SAP y diseña a partir de ella.

La zona de aterrizaje que construyes primero

Una zona de aterrizaje de Azure es la base que proporciona a cada carga de trabajo identidad, red, seguridad y gobernanza antes de desplegar nada en ella. El Cloud Adoption Framework de Microsoft la divide en dos partes:

• Zona de aterrizaje de la plataforma: la base compartida, con grupos de administración, conectividad central, identidad, seguridad y servicios de administración.
• Zonas de aterrizaje de aplicaciones (cargas de trabajo): los entornos individuales, normalmente desarrollo, pruebas y producción, formados por suscripciones que heredan las barreras de protección de la plataforma.

Para SAP esto importa más que para la mayoría de las cargas de trabajo, porque SAP gestiona finanzas, cadena de suministro y operaciones. Las directivas, las reglas de red y la identidad deberían existir antes de que llegue el primer sistema SAP. Añadirlas después implica mover recursos dentro de un sistema de negocio en producción.

Microsoft ofrece una zona de aterrizaje de SAP en Azure como acelerador, con diseños de referencia basados en una topología de red hub-and-spoke o Azure Virtual WAN. Azure Policy y la jerarquía de grupos de administración establecen las barreras de protección, y cada sistema SAP se despliega dentro de ellas. Así, el segundo y el tercer sistema SAP llegan sin volver a debatir la nomenclatura, el acceso y las reglas de red.

Mantener SAP conectado a tu centro de datos

Trasladar SAP a Azure rara vez implica dejarlo todo atrás. La mayoría de los paisajes de sistemas siguen siendo híbridos durante mucho tiempo, así que la conectividad es el puente que los mantiene unidos.

La opción privada principal es Azure ExpressRoute, una conexión privada dedicada entre tu centro de datos y Azure, en lugar de tráfico por internet público. Cuando ExpressRoute no está disponible, la alternativa es una VPN de sitio a sitio. En cualquier caso, la conexión suele terminar en el hub central o en Virtual WAN, y la red virtual de SAP accede a ella desde ahí. Dentro de Azure, un diseño típico de SAP separa las capas de aplicación y de base de datos en subredes propias, protegidas con grupos de seguridad de red, tablas de rutas y un firewall.

La identidad merece una mirada atenta, porque aquí es donde los equipos de Microsoft suelen hacer suposiciones. Microsoft Entra ID es excelente para el inicio de sesión único en las aplicaciones SAP. Pero los sistemas SAP NetWeaver y S/4HANA que se ejecutan en Windows no usan cuentas de Entra ID para la aplicación SAP en sí. Siguen necesitando Active Directory Domain Services, ampliado desde el entorno local o proporcionado por Microsoft Entra Domain Services. El inicio de sesión y el directorio del sistema operativo son dos historias distintas.

Tus tres opciones de despliegue

No existe una única forma correcta de desplegar SAP en Azure. Elige la vía que encaje con la forma en que tu equipo opera.

1. Máquinas virtuales de Azure básicas. Tú gestionas el sistema operativo, la instalación de SAP, los parches y la monitorización. Control máximo, trabajo máximo. Encaja bien cuando las habilidades de SAP y de Azure están en casa.
2. Azure Center for SAP solutions. Un servicio de Azure que convierte SAP en una carga de trabajo de primer nivel. Puede crear la infraestructura e instalar el software de SAP para sistemas de un solo servidor, distribuidos y distribuidos de alta disponibilidad, o registrar sistemas SAP que ya se ejecutan en Azure. Cada sistema se convierte en una Virtual Instance for SAP solutions, una vista lógica del SID, los servicios centrales y los servidores de base de datos y de aplicaciones. Desde ahí puedes ver el estado y la situación de salud, iniciar y detener el sistema, ejecutar comprobaciones de calidad basadas en las mejores prácticas y consultar los datos de supervisión. Los detalles están en la descripción general de Azure Center for SAP solutions.
3. SAP on Azure deployment automation framework. Un enfoque de infraestructura como código de código abierto para equipos que quieren implementaciones repetibles, controladas por versiones y un flujo de trabajo DevOps.

Una regla de decisión sencilla: el control total y las habilidades sólidas apuntan a las máquinas virtuales estándar; una configuración guiada con un único punto para gestionar el sistema apunta a Azure Center for SAP solutions; muchos sistemas desplegados de la misma forma apuntan al framework de automatización.

Errores habituales

La mayoría de las primeras migraciones complicadas comparten un patrón: un paso que parecía opcional.

• Tratar la certificación como un mero trámite. Una máquina virtual o un tipo de almacenamiento sin certificar convierte un sistema compatible en uno no compatible, y normalmente te enteras en el peor momento.
• Saltarse la landing zone. "Añadiremos la gobernanza más adelante" rara vez ocurre, y reconfigurar las reglas de identidad y red alrededor de un sistema SAP en producción es lento y arriesgado.
• Suponer que Entra ID sustituye a Active Directory en sistemas SAP basados en Windows. No es así.
• Diseñar la conectividad al final. Dividir la capa de aplicaciones de SAP y la capa de base de datos entre on-premises y Azure, o entre regiones de Azure, no está soportado.
• Suponer que todo se ejecuta en Azure. Azure VMware Solution generalmente no es una plataforma compatible para alojar cargas de trabajo de SAP, y las SAP HANA Large Instances ya no se ofrecen a nuevos clientes.
• Usar Azure Site Recovery para la base de datos. Azure Site Recovery no es compatible con la capa de base de datos de SAP; para la recuperación ante desastres, usa la replicación nativa de la base de datos, como SAP HANA System Replication.

Cada uno de estos puntos es donde los límites de soporte de Microsoft y SAP dejan de coincidir. Los límites no están ahí para frenarte; marcan la zona en la que ambos fabricantes respaldarán tu sistema.

Conclusión: el orden de las operaciones

Si recuerdas una sola cosa, recuerda la secuencia. Define lo que necesita el sistema SAP en rendimiento, disponibilidad y recuperación. Construye la landing zone. Conecta la red y el directorio de vuelta a tu centro de datos. Elige cuánto quieres que esté gestionado: máquinas virtuales estándar, Azure Center for SAP solutions o el framework de automatización. Escoge proceso y almacenamiento certificados. Después diseña la alta disponibilidad y la recuperación ante desastres en torno a las propias capacidades de la base de datos.

No tienes que moverlo todo a la vez. Empezar con un solo sistema te muestra dónde tu landing zone es débil y dónde tu equipo necesita apoyo, mientras lo que está en juego sigue siendo pequeño. Para los profesionales de Microsoft, SAP en Azure no es un mundo extraño. Es un conjunto de decisiones de ingeniería normales, con la certificación como la única regla que nunca se negocia.