Solution Manager arrive en fin de vie : la migration vers l'ALM dans le cloud n'est pas un projet de grande envergure

Le tenant est provisionné en quelques minutes, les clients éligibles ne paient aucun coût de licence supplémentaire et la mise en place opérationnelle ne nécessite qu'environ deux jours-personnes. Ceux qui se lancent dès maintenant peuvent décider en toute tranquillité des fonctionnalités de Solution Manager dont ils ont encore réellement besoin.

Les choses ne se passent pas comme prévu

La maintenance standard de SAP Solution Manager 7.2 prendra fin le 31 décembre 2027. SAP recommande à tous ses clients d'avoir achevé la migration vers SAP Cloud ALM avant cette date. C'est ce que l'on sait à ce jour. Cependant, une idée reçue largement répandue est erronée : nous avons jusqu’en 2030. La maintenance étendue jusqu’à fin 2030 est liée à la maintenance étendue de SAP Business Suite 7 et n’est donc pas accessible à tous les clients. Les entreprises qui ne bénéficient pas de la maintenance étendue pour SAP Business Suite 7 passeront, après 2027, à la maintenance spécifique au client pour les fonctionnalités SolMan non couvertes. Le délai dépend donc du statut ECC de l’entreprise, et non d’une indication générale figurant dans la feuille de route.

Pour le DSI et la direction informatique, il s'agit d'une question de gouvernance, et non d'une question technique. Elle devrait trouver une réponse avant que les équipes opérationnelles n'y soient confrontées. Un effet secondaire est rarement pris en compte dans ce contexte. Dans de nombreuses PME, Solution Manager est le dernier système utilisant la pile AS-Java. Les équipes sont ravies de se débarrasser de ce composant, car elles ne disposent de toute façon pas du savoir-faire nécessaire pour le gérer.

Trois erreurs qui retardent le démarrage

La véritable raison de cette hésitation ne réside pas dans la technique. Il s'agit de trois hypothèses qui s'avèrent régulièrement erronées dans le cadre des projets.

Premièrement : les coûts. SAP Cloud ALM est accessible aux clients SAP éligibles sans frais de licence supplémentaires. Il suffit de quelques clics dans SAP for Me pour vérifier cette éligibilité. Une grande partie des clients l'ignore et prévoit mentalement un budget qui n'est en réalité pas nécessaire.

Deuxièmement : la limite de mémoire. SAP a porté la mémoire de base à 24 Go dans le cadre de la politique d'utilisation équitable. Dans la pratique, cette limite est rarement atteinte. Un client disposant d’environ 18 environnements connectés et d’un large portefeuille de services cloud utilise environ 6 Go de mémoire HANA, sans avoir procédé à aucune opération de maintenance. Cela représente un quart de la limite d’utilisation équitable.

Troisièmement : l’effort requis. Le tenant est provisionné en quelques minutes, tandis que la connexion des différents systèmes prend des heures. Le déploiement d’agents, comme c’est le cas avec Solution Manager, n’est absolument pas nécessaire. L’exploitation existante se poursuit en parallèle ; SAP Cloud ALM n’interfère pas avec les processus en cours. Un schéma récurrent montre à quel point la barrière à franchir est en réalité faible : certains clients ont provisionné le tenant et connecté un premier système de test, mais se sont ensuite arrêtés là, craignant un effort d’apprentissage trop important. La décision est donc généralement prise au niveau de la direction d’équipe, et non au sein du comité d’investissement.

Ce que SolMan n'a jamais pu faire

Ceux qui considèrent cette transition comme une simple formalité passent à côté de l’essentiel. SAP Cloud ALM surveille les services cloud et les systèmes sur site depuis une seule interface, y compris les certificats et les clés API, notamment pour le SAP Cloud Connector et l’Integration Suite. Cette dimension « cloud » n’était pas prise en charge par Solution Manager, et c’est précisément là que les environnements se développent. Les clés API expirées d’un sous-compte constituent un exemple classique de panne silencieuse. Rien ne plante, rien ne déclenche d’alerte, l’interface cesse simplement de fonctionner. On s’en rend compte lorsque le service métier appelle. SAP Cloud ALM envoie des alertes configurables, par exemple 90 jours avant l’expiration, suivies d’un rappel critique 30 jours avant. L’alerte est transmise là où le travail s’effectue : sur le canal Teams, vers Jira ou ServiceNow, plutôt que dans une boîte de réception qui déborde de toute façon. Ce n’est pas une simple question de confort. Certains clients existants ont justement opté pour ce changement en raison de cette fonctionnalité, car les clés expirées leur causaient régulièrement des problèmes opérationnels.

Le deuxième domaine concerne la gestion centralisée des déploiements pour le développement sur site et dans le cloud, avec une interface Fiori et sans étapes manuelles d'exportation et d'importation. Dans la pratique, on commence presque toujours par les opérations, tandis que le domaine de la mise en œuvre est laissé de côté. Cela tient généralement à la formulation de la documentation, et non à la réalité : les techniciens y ont moins de tâches liées aux processus qu’ils ne le pensent.

Le chemin pour y parvenir, sans Big Bang

La migration vers SAP Cloud ALM se déroule par étapes : vérification de l'état de préparation dans Solution Manager, puis systèmes de développement et de test, puis production. Les deux outils peuvent fonctionner en parallèle et être comparés entre eux au niveau de la surveillance. Deux écueils justifient un travail préparatoire. La gestion des identités doit être rattachée dès le départ au tenant IAS en production, sinon des tenants parallèles sans synchronisation apparaissent. De plus, certaines métriques, comme la surveillance du système de fichiers, génèrent surtout de fausses alertes si elles ne sont pas configurées au préalable. Ces deux problèmes peuvent être corrigés a posteriori, mais cela entraîne des coûts inutiles. Point important pour l’évaluation des risques : SAP Cloud ALM est une couche d’orchestration, et non un point de défaillance unique. En cas de panne du service, les transports via le TMS restent possibles manuellement, contrairement à ChaRM ou Focus Build. La migration est ainsi maîtrisable et réversible à tout moment. À ce jour, rares sont les clients SAP existants qui auraient regretté de s’être lancés dans cette aventure. L’accompagnement va d’une session de formation, au cours de laquelle l’équipe effectue elle-même le déploiement tout en apprenant, à la mise en place complète du tenant, de la connexion au système et des services cloud par Entplexit.

Conclusion

Le délai est compté, mais l'effort à fournir est prévisible. En attendant, on ne perd pas en termes de technologie, mais en marge de manœuvre. L'erreur la plus coûteuse lors de la migration vers SAP Cloud ALM, c'est d'attendre. En s'y prenant tôt, on décide soi-même des fonctionnalités de Solution Manager dont on a encore besoin, au lieu de devoir les recréer dans l'urgence. (Source : Entplexit)