Analyser les stratégies de migration des systèmes SAP vers Microsoft Azure
La majorité des clients qui envisagent de déployer des charges de travail SAP sur Azure disposent d’une implémentation SAP locale existante. Le nombre de déploiements à partir de rien est relativement faible.
En règle générale, les entreprises ont des systèmes SAP pour les fonctions métier, comme la planification des ressources d’entreprise (ERP, Enterprise Resource Planning), le commerce international, le décisionnel (BI, Business Intelligence), etc. Au sein de ces systèmes se trouvent des environnements de bac à sable, de développement, de test et de production.
Chaque ligne horizontale de la figure ci-dessus est un environnement. Chaque colonne est un système SAP pour une fonction métier (par exemple ERP et BI).
Les lignes ou les couches du bas sont des environnements à risque faible et sont moins critiques. Ceux qui se trouvent en haut sont à risque plus élevé et plus critiques. À mesure que vous montez dans la pile, les risques augmentent dans le processus de migration. Ainsi, la production est l’environnement le plus critique, et l’environnement pour les tests d’acceptation des utilisateurs (Test), qui est également utilisé pour la continuité d’activité, vient en deuxième position.
Les systèmes du bas sont plus petits, car ils ont moins de ressources informatiques, des exigences moindres de disponibilité et de taille, et un débit moins élevé. Cependant, ils ont la même quantité de stockage que la base de données de production.
Stratégie horizontale
Avec une stratégie horizontale, vous commencez à partir du bas de la pile, car c’est un moyen sûr d’expérimenter et de gagner en expérience avec Azure. C’est aussi d’une bonne stratégie à utiliser quand vous redéfinissez vos processus opérationnels, de déploiement et d’approbation. Ces processus vont changer dès lors que vous passez à Azure. Voici comment la stratégie fonctionne :
- Pour limiter les risques, commencez avec des systèmes ayant un impact faible, de type bac à sable (sandbox) ou destinés à la formation. Si quelque chose se passe mal, il y a très peu de risques d’affecter de nombreux utilisateurs ou des fonctions critiques de l’entreprise.
- Ensuite, à mesure que vous gagnez en expérience avec l’exécution, l’hébergement et l’administration des systèmes SAP dans Azure, appliquez ce que vous avez appris à la couche de systèmes suivante dans la pile.
- Pour chaque couche, estimez les coûts, les économies potentielles, les performances et le potentiel d’optimisation, et ajustez-les si nécessaire.
Stratégie verticale
Pour gagner en expérience avec les systèmes de production sur Azure, vous pouvez utiliser une stratégie verticale avec des systèmes à faible risque, parallèlement à la stratégie horizontale. Ceci offre également la possibilité d’ajuster les processus internes pour Azure et de former les membres de l’équipe. C’est un excellent moyen de détecter au plus tôt les problèmes en production. Voici comment la stratégie fonctionne :
- Examinez l’impact sur les coûts, les clients, les contrats de niveau de service (SLA) et les conditions légales. Tout d’abord, déplacez les systèmes, du bac à sable jusqu’à la production, qui présentent le risque le plus faible : le système de gouvernance, des risques et de la conformité, puis le système de référentiel d’événements d’objet (OER, Object Event Repository). Déplacez ensuite les systèmes avec des risques plus élevés, comme BI et ERP.
- Si vous avez un nouveau système SAP, commencez dans Azure par défaut, au lieu de l’installer en local et de le déplacer plus tard. Dans le diagramme, OER en est un exemple. OER est un nouveau système à faible risque. Après avoir déplacé certains de nos autres systèmes dans Azure avec la stratégie horizontale, vous pouvez déployer l’ensemble de la pile verticale OER sur Azure, de bout en bout, depuis le bac à sable (sandbox) jusqu’à la production.
- Ne déplacez en premier le système le plus critique. Le dernier système que vous déplacez est le plus à risque et le plus critique : le système de production ERP. Vous avez besoin des références SKU de machines virtuelles les plus performantes et avec le plus grand stockage.
- Commencez par déplacer les systèmes autonomes. Certains systèmes sont étroitement liés à d’autres systèmes, par exemple nos systèmes ERP et GTS. Il y a beaucoup de trafic synchrone en temps réel entre les deux. Si vous déplacez le système ERP vers Azure mais que vous conservez GTS localement, cela affecte les performances en raison de la latence réseau ; déplacez-les donc ensemble.
- Si vous avez plusieurs systèmes SAP, recherchez des dépendances en amont et en aval entre deux systèmes SAP, ou entre SAP et des applications qui sont en dehors de l’écosystème SAP. Examinez les modèles et les zones de trafic ayant une haute sensibilité à la latence.
- Si vous avez des systèmes étroitement connectés, faites une analyse des performances pour voir l’effet de leur déplacement. Si l’impact n’est pas très important, déplacez-les séparément vers Azure (par exemple Business Warehouse indépendamment d’ERP). Dans le cas contraire, créez des groupes de migration et déplacez-les ensemble.
- Dans certains cas, envisagez d’attendre avant de migrer. Parfois, vous ne voulez pas déplacer immédiatement certains systèmes vers Azure. Ce peut être lié à des exigences de dimensionnement, quand les exigences de traitement sont tellement élevées que les machines virtuelles ne sont pas encore assez grandes. Exécutez des tests pour vérifier que le déplacement de ces systèmes ne va pas affecter les contrats SLA avec les clients.