Analytics Legends La plateforme de connaissance SAP Analytics
Guide

Migration SAP BW Datasphere — quel chemin choisir, et sur quels arbitrages

À jour au 2026-08-14

« Migrer BW vers Datasphere » n'est pas un geste unique : c'est le choix entre quatre chemins qui n'engagent ni le même budget, ni le même risque, ni la même capacité obtenue à l'arrivée. Le chemin ne se choisit pas selon ce que le consultant maîtrise, mais selon l'état réel du modèle BW existant, le moteur du projet et la personne qui accepte de retirer des rapports. Et depuis que SAP a repoussé la maintenance étendue de SAP BW 7.5 au 31 décembre 2030, l'échéance ne tranche plus à votre place.

Chemin 1 — le lift-and-shift, et sa dette

Le lift-and-shift conserve le modèle BW existant et le réhéberge. C'est 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 doit être dit à voix haute : cela achète du temps sans acheter de capacité. Le client hérite du coût et du modèle d'exploitation de la plateforme cible tout en conservant chaque contournement accumulé sur la durée de vie du modèle BW. Présenté comme un état cible, c'est une promesse qui se retourne à la première facture ; présenté comme une étape de transition avec un registre de dette nommé, c'est une décision défendable — et l'absence de ce registre est le signal qu'aucun arbitrage n'a eu lieu.

Chemin 2 — la migration sélective via BW Bridge

BW Bridge est un runtime BW/4HANA exécuté à l'intérieur d'un tenant SAP Datasphere. Le contenu BW/4HANA existant — InfoObjects, aDSO, CompositeProviders, transformations, code ABAP — est repris tel quel via le cockpit de migration fourni par SAP, les extracteurs ECC et S/4 continuent d'alimenter par les mêmes Source Systems, et chaque CompositeProvider s'expose ensuite à la couche sémantique Datasphere sous forme de Remote Table.

C'est le défaut pragmatique des grands parcs : il expose l'existant sans imposer une ré-ingénierie complète, au prix d'un plafond sur la dette réellement résolue — vous héritez de la sémantique, verrues comprises — en échange d'un calendrier plus court et d'un risque de livraison plus faible.

Deux conditions rendent ce chemin sain. Une date de sunset écrite dans la décision d'architecture au lancement, pas plus tard : c'est la différence entre un pont de deux ans et un meuble permanent de sept ans. Et une cadence tenue — un sprint trimestriel de cinq à dix objets vers du Datasphere natif, séquencé par valeur métier et complexité. Un junior provisionne le pont et le laisse vivre ; un senior le fait décroître.

Chemin 3 — la reconstruction native, et son seul bon motif

Reconstruire la couche sémantique dans Datasphere est le coût le plus élevé et le plafond le plus haut. Ce chemin ne se défend que sur un motif : le modèle existant EST le problème.

La question de diagnostic est inconfortable à entendre : voulons-nous préserver cette logique, ou cette migration est-elle l'occasion de réparer ce que BW a mal construit ? Requêtes avec exits ABAP non documentés, InfoCubes portant dix ans de contournements, définitions de reporting que la finance n'a jamais validées — dans ces cas, tout outil de conversion reproduit fidèlement une logique fausse et déplace la dette intacte au lieu de l'éliminer.

L'anti-pattern symétrique existe, et les acheteurs expérimentés le filtrent désormais explicitement : vendre une reconstruction alors que le modèle est récupérable, parce que la mission est plus grosse.

Chemin 4 — rester et fédérer

Le quatrième chemin est le moins vendu et parfois le plus juste : laisser BW là où il est et l'exposer par la couche de fédération, sans le remplacer. Il est légitime pour un client dont le parc fonctionne et dont le besoin réel est la portée. Le repousser d'office parce qu'il ne produit pas de programme de migration est exactement le comportement que le marché a appris à repérer.

À noter : la coexistence prolongée est de toute façon la description honnête de ce qui se passe sur la plupart des grands programmes, quel que soit le chemin choisi sur le papier. Ce qui distingue une coexistence pilotée d'un parc à deux plateformes subi, c'est un plan de sunset explicite du côté hérité.

Ce que l'outillage change dans l'arithmétique

Le BW Data Product Generator lit les objets BW existants et produit des Data Products consommables, en préservant la couche sémantique. Chaque objet scanné reçoit un score de complexité de 1 à 5 : 1 et 2 se génèrent automatiquement avec moins de 5 % de retouche, 3 avec 20 à 40 % de reprise manuelle attendue, 4 et 5 sont signalés pour refonte manuelle. Sur un parc de premier rang, 70 à 80 % des objets tombent dans la bande automatisable ; les 20 à 30 % restants sont exactement là où le jugement d'un consultant se paie.

L'effet sur un programme de premier rang : un calendrier qui passe de 12-18 mois de conversion manuelle à 6-9 mois, et des honoraires qui passent de 1 à 1,8 M€ à 500-900 k€. Ce sont nos propres chiffres d'engagement, et ce sont eux qui doivent désormais porter la décision — l'échéance ne le fait plus.

Le tableau de décision

Modèle en état correct, moteur infrastructure ou licence → lift-and-shift, présenté comme transitoire, avec son registre de dette.

Grand parc (centaines d'InfoProviders, milliers de requêtes), aucun gel du reporting tolérable, modernisation financée sur trois à cinq ans → migration sélective via BW Bridge, date de sunset et cadence trimestrielle.

Petit parc (moins de cinquante InfoProviders actifs, moins de cent requêtes) ou bien documenté → remodélisation directe en Datasphere natif : plus rapide et plus propre qu'un pont.

Le modèle lui-même est le problème — exits ABAP non documentés, logique à laquelle personne ne fait confiance → reconstruction native ; tout le reste réhéberge le défaut.

Le parc fonctionne, le besoin réel est la portée → rester et fédérer.

Personne n'est nommé pour décider du retrait des rapports → aucun chemin ne tiendra le calendrier. Réglez le parrainage avant de cadrer le périmètre : le retrait est une décision politique, et c'est le vrai chemin critique.

Ce que nous ne pouvons pas affirmer

Nous ne publions pas de durée ni de budget applicables à votre parc : les fourchettes citées décrivent des programmes de premier rang observés dans nos engagements, pas votre estimation. Le nombre d'InfoProviders, la part de code ABAP personnalisé et l'état du parrainage métier déplacent ces chiffres davantage que le choix du chemin lui-même.

Questions fréquentes

BW Bridge est-il une destination ?

Non, c'est une étape. C'est un runtime BW/4HANA hébergé dans un tenant Datasphere pour faire atterrir du contenu existant, pas un endroit où construire de nouveaux modèles. Sans date de sunset écrite dans la décision d'architecture, il devient un parc permanent à deux plateformes.

Faut-il passer par BW/4HANA avant Datasphere ?

Ce n'est pas un passage obligé. BW/4HANA est le successeur dans la lignée BW ; Datasphere est un service cloud avec un autre modèle de modélisation, et BDC la couche de produits de données au-dessus. Choisir l'un ne tranche pas l'autre.

Quelle part du parc se convertit automatiquement ?

Sur un parc de premier rang, 70 à 80 % des objets se situent dans la bande automatisable. Les 20 à 30 % restants — transformations ABAP personnalisées, unions complexes de CompositeProviders, chaînes de processus — demandent une remodélisation manuelle et remontent en avertissements de conversion.

Que devient l'historique BW ?

Chaque chemin doit trancher : archiver sur place, porter sélectivement, ou laisser froid. Traiter cette question tardivement fait dériver calendrier et budget au dernier trimestre du programme.

Sur quoi cette page s'appuie

À lire ensuite