Análisis de estrategias para migrar sistemas SAP a Microsoft Azure

Completado

La mayoría de los clientes que consideran implementar cargas de trabajo de SAP en Azure tienen ya una implementación de SAP local existente. El número de implementaciones nuevas es relativamente pequeño.

Normalmente, las empresas tienen sistemas de SAP para funciones de negocios como la planeación de recursos empresariales (ERP), el comercio global y la inteligencia empresarial (BI) entre otros elementos. En esos sistemas existen entornos como el espacio aislado, el desarrollo, las opciones de prueba y la producción.

Diagrama que muestra entornos de ejemplo.

Cada fila horizontal de la ilustración anterior es un entorno. Cada columna es un sistema SAP relacionado con una función de negocios (por ejemplo, ERP y BI).

Las filas o capas de la parte inferior son entornos de bajo riesgo y son menos críticos. En cambio, los que van hacia la parte superior son de mayor riesgo y más críticos. A medida que sube por la pila, existe más riesgo en el proceso de migración. Por lo tanto, la producción es el entorno más crítico y el entorno de pruebas de aceptación de usuario (prueba) que también se usa para la continuidad empresarial, es el segundo entorno más crítico.

Los sistemas de la parte inferior son más pequeños, ya que tienen menos recursos informáticos, menos requisitos de tamaño y disponibilidad y menos rendimiento. Sin embargo, tienen la misma cantidad de almacenamiento que la base de datos de producción.

Estrategia horizontal

Si decide usar una estrategia horizontal, debe comenzar desde la parte inferior de la pila, ya que es la forma más segura de experimentar y obtener experiencia con Azure. También es una buena estrategia a tener en cuenta mientras redefine los procesos operativos, de implementación y de aprobación. Estos procesos cambiarán cuando realice la migración a Azure. Así es como funciona la estrategia:

  • Para limitar el riesgo, empiece con un espacio aislado o sistemas de entrenamiento de bajo impacto. Así si algo va mal, hay muy poco riesgo de que el proceso afecte a muchos usuarios o funciones empresariales críticas.
  • A continuación, a medida que obtiene experiencia en la ejecución, el hospedaje y la administración de sistemas de SAP en Azure, aplique lo que haya aprendido a la siguiente capa de sistemas de la pila.
  • En cada capa debe calcular los costos, el ahorro potencial de dinero, el rendimiento y la optimización posible y ajustar estos parámetros si es necesario.

Estrategia vertical

Para obtener experiencia con los sistemas de producción en Azure, puede usar una estrategia vertical con sistemas de bajo riesgo en paralelo a la estrategia horizontal. Esta opción también le ofrece la posibilidad de ajustar los procesos internos de Azure y entrenar a los miembros del equipo. Es una excelente manera de detectar cualquier problema de la producción a tiempo. Así es como funciona la estrategia:

  • Consulte el impacto en el costo, los clientes, los acuerdos de nivel de servicio (SLA) y los requisitos legales. En primer lugar, mueva los sistemas (desde el espacio aislado hasta el entorno de producción) que tengan el menor riesgo; es decir, el sistema de gobernanza, de riesgo y de cumplimiento y, a continuación, mueva el sistema del repositorio de eventos de objetos (OER). A continuación, vaya a los que representan un riesgo más alto, como BI y ERP.
  • Cuando tenga un nuevo sistema de SAP, empiece en Azure de forma predeterminada en lugar de colocarlo en el entorno local y moverlo más adelante. En el diagrama, OER es un ejemplo de esto. OER es un nuevo sistema de bajo riesgo. Después de mover algunos de nuestros otros sistemas a Azure con la estrategia horizontal, puede implementar toda la pila vertical de OER en Azure, de un extremo a otro y desde el espacio aislado hasta el entorno de producción.
  • No mueva primero el sistema más crítico. El último sistema que debe mover es el de mayor riesgo; el sistema más crítico es el sistema de producción ERP. Recuerde que necesita las SKU de máquina virtual de mayor rendimiento y el almacenamiento más grande.
  • Mueva primero los sistemas independientes. Algunos sistemas están estrechamente unidos a otros sistemas; por ejemplo, los sistemas ERP y GTS. Existe una gran cantidad de tráfico sincrónico en tiempo real entre los dos. Si traslada ERP a Azure, pero mantiene GTS en el entorno local, el rendimiento se verá afectado debido a la latencia de la red, por lo que debe trasladarlos juntos.
  • Si tiene varios sistemas de SAP, busque las dependencias ascendentes y descendentes de un sistema de SAP a otro, o de SAP a aplicaciones que estén fuera del ecosistema de SAP. Examine los patrones de tráfico y las áreas con alta sensibilidad a la latencia.
  • Si tiene sistemas conectados estrechamente, realice un análisis de rendimiento para ver el efecto que tendrá esta opción. Si no hay mucho impacto, muévalos por separado a Azure (por ejemplo, a un almacén de negocios independiente de ERP). De lo contrario, cree grupos de migración y muévalos a la vez.
  • En algunos casos, esto puede esperar. Es posible que no quiera trasladar algunos sistemas a Azure de inmediato. Esto podría estar relacionado con los requisitos de ajuste de tamaño; es decir, cuando los requisitos de procesamiento son tan elevados que las máquinas virtuales no son lo suficientemente grandes. Ejecute pruebas para asegurarse de que el traslado de estos sistemas no afecte a los Acuerdo de Nivel de Servicio con los clientes.