Fiche concept

Fin de support SAP BW — ce qui s'arrête réellement, et les quatre chemins de migration

À jour au 2026-08-02T21:40:00Z

Qu'est-ce que Fin de support SAP BW — ce qui s'arrête réellement, et les quatre chemins de migration ?

Cherchez « fin de support SAP BW 2027 » et vous trouverez une douzaine de dates affirmées.

Cherchez « fin de support SAP BW 2027 » et vous trouverez une douzaine de dates affirmées. Méfiez-vous de toutes, y compris de celle de la requête : votre date de fin de maintenance dépend du produit BW que vous exploitez, de la release et de ce que dit votre contrat — et la seule réponse qui fasse autorité est le calendrier de maintenance de SAP pour votre version précise. Cette page n'inventera pas de date. Elle vous dit ce qui se passe réellement et quelle est la décision.

Ce qui se passe réellement

SAP a fixé un horizon de maintenance sur BW classique et sur BW/4HANA, et a fait de Business Data Cloud la plateforme cible de l'analytique d'entreprise. Cette combinaison — une fenêtre qui se referme sur l'ancienne plateforme plus une destination nommée — est ce qui a déclenché le plus grand cycle de migration de l'écosystème analytique SAP depuis le passage de BW sur base quelconque à BW sur HANA.

L'échelle explique pourquoi cela compte commercialement autant que techniquement : environ quatre mille clients BW sur le principal marché européen, plus quelque dix-sept mille clients ECC, composent la population adressable, et la demande de conseil qui en découle se compte en milliards d'ici 2028.

Vous êtes dans l'une de quatre cohortes, et elles ne partagent pas la même échéance

Les clients encore sur BW classique en maintenance étendue affrontent la date la plus dure et doivent décider en premier.

Les clients exploitant ECC à côté de BW sont entraînés dans la conversation au titre d'une transformation S/4HANA plus large — leur décision BW est une subordonnée dans un programme plus vaste, pas un projet autonome.

Les clients déjà sur BW/4HANA se demandent s'il faut rebouger si tôt : c'est une conversation réellement différente, ils ont modernisé récemment et l'argument de retour sur investissement doit franchir une barre plus haute.

Les clients ayant contourné l'entrepôt SAP — Snowflake, Databricks — sont courtisés au retour via la couche sémantique SAP-native de BDC ; pour eux c'est une évaluation, pas une échéance.

Chaque cohorte a son déclencheur, son calendrier et son appétit au risque. Le consultant qui attaque par un « BW s'arrête » générique parle à la mauvaise cohorte trois fois sur quatre.

Les quatre chemins, et comment les plaider

« Migrer vers BDC » n'est pas un geste unique. La décision pratique est de recommander l'un de quatre chemins, plaidé sur des arbitrages plutôt que choisi par défaut selon ce que le consultant maîtrise.

Lift-and-shift conserve le modèle BW existant et le réhéberge. Le bon choix quand le modèle est en état correct et que le moteur est la pression d'infrastructure ou de licence, pas la modernisation. L'arbitrage est explicite : cela achète du temps sans acheter de capacité — vous héritez du coût et du modèle d'exploitation de BDC tout en conservant chaque dette de modélisation accumulée. À présenter comme une étape de transition, jamais comme un état cible.

Migration sélective déplace ce qui mérite de l'être et retire le reste. C'est généralement la réponse honnête, et généralement celle qui demande le plus de couverture politique, parce que « retirer » signifie que le rapport de quelqu'un disparaît.

Reconstruction traite la migration comme le moment de refaire correctement la couche sémantique dans Datasphere. Coût le plus élevé, plafond le plus haut, défendable seulement quand le modèle existant est réellement le problème.

Rester et fédérer laisse BW en place et l'expose via BDC Connect. Légitime pour les clients dont le parc BW fonctionne et dont le besoin réel est la portée, pas le remplacement.

Le BW Data Product Generator mérite d'être connu ici : il transforme des objets BW existants en Data Products consommables par BDC, ce qui change nettement l'arithmétique des deux premiers chemins.

Pièges

Citer une date que vous n'avez pas vérifiée dans le calendrier de maintenance de SAP pour la version exacte du client. C'est la façon la plus rapide de perdre une salle, et la correction vient toujours de l'équipe basis du client.

Vendre la vague plutôt que la cohorte. Quatre cohortes, quatre déclencheurs ; le discours d'urgence générique tombe le plus souvent sur la mauvaise.

Présenter le lift-and-shift comme terminé. C'est une étape de transition avec une dette attachée, et le client à qui on a dit le contraire découvre la dette à la première facture BDC.

Traiter « retirer ce rapport » comme une décision technique. C'est une décision politique, et c'est le vrai chemin critique d'une migration sélective.

Pourquoi c'est important

C'est la vague de migration qui redessine quels cabinets tiennent quels comptes pour la décennie — et la façon la plus rapide de perdre la salle est de citer une date non vérifiée pour la release exacte du client.

Sources

Ouvrir dans l'application →