Migrer ou moderniser BusinessObjects : 5 scénarios comparés.

Versions concernées : BI 4.2 → BI 2025 · Temps de lecture : 10 min

En résumé. Quand une organisation se pose la question « que faire de BusinessObjects ? », elle a en réalité cinq options, et non deux. Elles ne s’excluent pas toutes : la plupart des parcs finissent par en combiner deux ou trois. Ce qui les distingue, c’est ce qu’elles conservent (univers, rapports, sécurité, planifications), ce qu’elles coûtent (licences, projet, double run, formation) et ce qu’elles apportent (visuel, mobilité, planification, hébergement). Le point de départ est toujours le même : un audit du parc, parce que la moitié des rapports d’un BO de dix ans ne sont plus lus.

Les cinq scénarios

1. Mettre à jour la plateforme en place

Passer de 4.2 ou 4.3 à BI 2025 (ou BI 2027) sur la même architecture. Une mise à jour BO est une montée de version de plateforme, pas une migration : univers, rapports, utilisateurs, droits et planifications sont repris. Les vrais chantiers sont connus : conversion des UNV en UNX avant BI 2025 (l’outil de conversion y est retiré), remplacement des univers multi-sources et des connexions OLAP MDX, reprise des rapports qui utilisaient des composants abandonnés, mise à niveau de Java et des pilotes. C’est le scénario minimal, obligatoire pour rester en maintenance, et le socle des trois suivants.

Durée typique : 3 à 6 mois. Conserve tout. N’apporte rien de visible aux métiers, sauf les nouveaux éléments Webi pour les rapports que l’on reconstruit.

2. Mettre à jour et moderniser par extensions

Le scénario 1, plus des extensions installées sur la plateforme pour répondre aux trois demandes métier qui alimentent l’idée de migrer : des visualisations modernes, des tableaux de bord partageables hors du Launchpad, et un accès en langage naturel. Les rapports existants sont enrichis sans réécriture, la couche sémantique et la sécurité restent celles des univers, et l’on ne crée aucun flux de données parallèle.

Durée typique : quelques semaines après la mise à jour. Conserve tout. Apporte le visuel et le partage. C’est le scénario le plus fréquent chez les organisations qui ont fait l’audit avant de décider.

3. Hybride BO + SAP Analytics Cloud

BO reste la plateforme de reporting opérationnel et de diffusion ; SAC s’ajoute pour la planification budgétaire, le prédictif et certains tableaux de bord de synthèse, en lisant les univers en direct via Live Data Connect. C’est le scénario officiel SAP, sans migration des univers ni des rapports Webi. Il a du sens quand le besoin de planification est réel, ou quand le SI bascule vers les applications cloud SAP.

Durée typique : scénario 1 + 3 à 9 mois pour SAC. Conserve tout. Ajoute une plateforme, un abonnement et une compétence. Voir notre comparatif BO vs SAC.

4. Passer en Private Cloud Edition

La même plateforme BO, hébergée et exploitée par SAP dans un cloud privé dédié. On change d’hébergement, pas d’outil : le contenu est transféré, les univers pointent vers les bases (restées sur site ou déplacées), l’exploitation d’infrastructure disparaît. Intéressant pour une DSI qui veut sortir de l’exploitation serveur sans renoncer à BO ni accepter le SaaS multi-tenant.

Durée typique : 3 à 6 mois, souvent combiné avec le scénario 1. Conserve tout. Change le modèle de coût (abonnement) et la connectivité aux sources.

5. Migrer vers un autre outil

Remplacer BO par Power BI, Tableau, Qlik ou un autre. Ce scénario est légitime dans certains cas : stratégie groupe imposée, disparition des compétences BO, parc réduit et récent. Mais il faut le chiffrer honnêtement : les univers n’ont pas d’équivalent de migration automatique, les rapports opérationnels paginés et les publications éclatées sont les derniers à trouver un remplaçant, et le double run dure tant que le dernier rapport critique n’est pas reconstruit. Les projets qui « migrent 2 000 rapports » finissent en général par en refaire 300, en archiver 1 500 et à garder BO pour les 200 qui restent.

Durée typique : 18 à 36 mois. Ne conserve rien. Apporte un outil moderne, au prix de la couche sémantique, de la diffusion et de la formation de tous les utilisateurs.

Comparatif

Les durées et coûts relatifs sont des ordres de grandeur issus de projets observés, pas des chiffres SAP ; ils varient avec la taille du parc et l’état des univers.

Avant de choisir : l’audit du parc

1. Inventorier : nombre d’univers (UNV / UNX), de documents, de planifications actives, d’utilisateurs réellement connectés sur les douze derniers mois. L’Auditor et le référentiel donnent tout cela.
2. Trier : rapports consultés, rapports jamais ouverts (à archiver), rapports critiques (réglementaires, financiers, diffusés à l’extérieur). Ce tri réduit typiquement le périmètre de moitié.
3. Lister les besoins non couverts : ce que les métiers demandent et que BO natif ne fait pas. En général : visualisation, partage hors plateforme, mobile, planification, langage naturel.
4. Déduire le scénario : chaque besoin non couvert pointe vers un scénario (visuel et partage → 2 ; planification → 3 ; exploitation → 4). La migration complète (5) ne s’impose que si les besoins non couverts dominent le parc conservé, ce qui est rare.

Questions fréquentes

Faut-il faire la mise à jour avant de décider du reste ?
Oui. Le scénario 1 est le socle de 2, 3 et 4, et il est nécessaire pour rester en maintenance. Même en cas de migration (5), un BO à jour sécurise le double run.

Peut-on combiner les scénarios ?
C’est la norme : 1 + 2 pour la majorité du parc, 3 pour la planification, 4 si l’on veut sortir de l’exploitation. Le seul scénario exclusif est le 5.

Un outil de migration BO → Power BI ou Tableau existe-t-il ?
Des éditeurs proposent des convertisseurs d’univers et de rapports. Ils accélèrent l’inventaire et une partie de la conversion, mais pas la logique métier des variables ni la diffusion ; comptez une reprise manuelle sur les rapports critiques.

Que faire des rapports que personne n’ouvre ?
Les archiver hors production (export BIAR ou LCMBIAR), les retirer du référentiel, et ne pas les migrer, quel que soit le scénario.

Sources et références

• SAP Community — « SAP BusinessObjects BI Future is clarified » (déclaration d’orientation)
• Christian Ah-Soon (SAP), « SAP BI 2025: What’s New In Web Intelligence and Semantic Layer » (composants retirés, conversion UNV)
• SAP Community — « Journey to Cloud » : hybride SAC et Private Cloud Edition
• SAP Community — Webinaire « Best of Both Worlds », Q&A (pas de migration des univers vers SAC)
• Wiiisdom — « SAP BI end of life stages »
• Retours terrain Need4Viz sur des projets de mise à jour, de modernisation et de migration BO