SAP BW → Databricks · Snowflake · Datasphere · Fabric · BigQuery
Migravo cartographie l'existant décisionnel de vos systèmes SAP — BW 7.x, BW/4HANA, S/4HANA (exposition ODP) et ECC (rapports Z, queries SQ00) — à partir de simples extractions de tables. Vous chiffrez le périmètre réel — usages, dépendances, règles métier — pas le catalogue théorique d'objets, et repartez avec des recommandations concrètes : migrer, remplacer par le standard, ou décommissionner.
Aucune connexion à votre SAP. Uniquement des exports de metadata.
Vos systèmes
Le même produit, la même méthode et le même barème — l'analyse s'adapte à ce que chaque système sait dire de lui-même.
Modèle classique — InfoCubes, MultiProviders, DSO. Lineage complet depuis les queries actives, routines ABAP décortiquées, chaînes de traitement, Open Hub, autorisations d'analyse.
Paysages mixtes — objets classiques et ADSO / CompositeProviders côte à côte, avec l'analyse du runtime HANA : ce qui s'exécute en SQLScript, ce qu'une routine ABAP ramène côté serveur d'application.
Modèle moderne — ADSO, CompositeProviders, AMDP. Verdict de traduisibilité du code SQLScript (direct, partiel, réécriture) pour chiffrer la migration sans angle mort.
Ce que votre S/4 expose au reste du SI : DataSources SAPI, vues CDS extractibles (delta, CDC), souscriptions ODQ et consommateurs réels — avec la conversion vers les vues standard du VDM quand elle existe.
L'existant décisionnel de l'ERP : rapports Z consommés par transaction, tables réellement lues, DataSources activées, queries SQ00 et leurs InfoSets — chacun assorti d'une recommandation standard S/4 (vues CDS, applications Fiori) : remplaçable, partiel, spécifique ou à qualifier.
Les profils se combinent : un BW alimenté par un ECC en cours de conversion S/4 se cartographie des deux côtés — ce qui doit être migré, ce que le standard couvre déjà, ce qui peut être décommissionné.
Méthode
Le processus est séquentiel : vous savez toujours ce que la suite coûtera avant de la lancer.
Votre équipe exporte une courte liste de tables de référentiel — la liste exacte dépend de votre système (BW 7.x, BW 7.4/7.5, BW/4HANA, S/4HANA ou ECC) et l'application l'affiche, requises et optionnelles, avec leur description. Formats d'export standard acceptés tels quels (tabulé, CSV).
La pré-discovery inventorie l'existant — providers, flux et queries côté BW ; sources ODP et vues CDS côté S/4 ; rapports Z, DataSources et queries SQ00 côté ECC — et calcule le nombre exact de crédits nécessaires pour couvrir tout le système. Pas de forfait opaque : le barème est public et le devis, déterministe.
La discovery part de chaque racine réellement utilisée — provider requêté, vue CDS de tête, transaction custom — et descend : compositions, transformations, dépendances cachées dans le code, jusqu'aux sources. Vous choisissez votre périmètre — tout, une sélection de flux, ou uniquement les master data — et ne payez que ce que vous analysez. Résultat : lineage complet, score de complexité, verdicts et recommandations — un inventaire exploitable dans vos arbitrages.
Sur BW, Migravo reconstruit vos données dans la plateforme cible en architecture médaillon — Raw, Bronze, Silver (vos règles métier), Gold — code généré et orchestration calée sur vos fréquences réelles. Sur S/4 et ECC, le livrable est la feuille de route : quoi raccorder, quoi remplacer par les objets standard, quoi reconstruire.
Pourquoi Migravo
Cartographier un paysage BI SAP à la main, c'est des semaines de rétro-ingénierie, des oublis inévitables et un chiffrage qui repose sur des dires d'experts. Migravo remplace ce travail par une analyse automatisée, exhaustive et reproductible.
De l'inventaire à la recommandation, sans intervention manuelle. Vous importez vos extractions, l'outil reconstruit le lineage, détecte les dépendances cachées dans l'ABAP et le SQLScript, et qualifie chaque objet — sur BW, il génère même les pipelines cibles. Ce qu'une équipe fait en semaines, Migravo le produit en minutes.
Une discovery complète en une session, pas en un trimestre. La pré-discovery chiffre le périmètre immédiatement ; la discovery livre lineage, verdicts et recommandations dans la foulée. Vous arbitrez le jour même, chiffres en main.
Un modèle à crédits, sans forfait opaque ni régie ouverte. Vous choisissez le périmètre à la carte — tous vos flux, une sélection, ou uniquement vos master data — et ne payez que ce que vous analysez, sur un barème public affiché ci-dessous. Le devis est connu avant de lancer quoi que ce soit.
L'analyse lit ce que l'œil humain manque : les lookups enfouis dans les routines, les objets partagés entre plusieurs flux, les chaînes qui ne tournent plus, le référentiel master data et son data flow, jusqu'à la couche de restitution. Elle déduit même des routines les tables qui portent vos règles métier — celles qu'une migration devrait reconstruire. Vous chiffrez le système réel, pas une vue partielle.
Chaque objet ressort qualifié : couvert par le standard S/4, couverture partielle (le reste est nommé), spécifique à reconstruire, ou à qualifier quand la donnée manque — rien n'est inventé. C'est ce qui transforme une cartographie en décision.
Aucune connexion à votre système, aucun agent, aucune donnée de gestion qui sort. Migravo travaille sur des exports de metadata que vos équipes produisent et relisent. Conçu pour passer votre revue sécurité.
Extractions
Le service ne se connecte jamais à votre système. Vos équipes exportent une courte liste de tables de référentiel — la liste précise vous est fournie selon votre version. Aucune donnée de gestion ne quitte votre SAP.
Queries, providers, compositions et flux de chargement : de quoi reconstruire l'arbre complet depuis le reporting jusqu'aux sources.
Clés, modes delta et code des routines — pour comprendre la sémantique réelle de vos flux, pas seulement leur forme, et savoir ce qu'une migration devrait rejouer.
Caractéristiques porteuses d'attributs, de textes et de hiérarchies, avec leur data flow complet : DataSources d'alimentation, DTP et chaînes de traitement. Le référentiel n'est pas oublié — il est cartographié comme le reste.
Usage des queries et statistiques des chaînes de traitement : fréquence, durée, fiabilité. On chiffre ce qui tourne vraiment, à la cadence où ça tourne.
Sécurité des données · nouveau
À partir des tables d'autorisation d'analyse de BW (RSECADMIN), Migravo cartographie qui accède à quelles données sur chaque InfoProvider : caractéristiques sensibles restreintes, autorisations qui les couvrent, utilisateurs concernés. Surtout, il révèle les angles morts — les caractéristiques sensibles qu'aucune autorisation ne protège. Vous décidez de votre modèle de sécurité cible en connaissance de cause, au lieu de le redécouvrir en production.
Adapté à SAP BW 7.0 / 7.3, 7.4 / 7.5, BW/4HANA, S/4HANA (catalogues ODP, DDL des vues CDS, dictionnaire) et ECC (transactions, références croisées de programmes, catalogues SAP Query). La liste exacte est affichée dans l'application, par profil.
Recommandations
Une discovery n'a de valeur que si elle débouche sur des décisions. Pour chaque objet analysé, Migravo instruit l'une des trois issues — avec les éléments pour arbitrer.
Ce qui porte une logique métier propre et un usage réel. Sur BW, la migration est outillée de bout en bout : architecture médaillon, code généré, orchestration calée sur vos fréquences — détaillée ci-dessous.
Ce que S/4 couvre déjà : vues CDS du VDM et applications Fiori associées à vos tables, DataSources et rapports Z — verdict par objet (couvert, partiel, spécifique), équivalence fonctionnelle à valider, jamais présumée.
Ce que l'usage réel condamne : queries sans exécution, chaînes qui ne tournent plus, objets qu'aucune restitution ne porte. La discovery part des usages — ce qui n'est porté par rien sort du périmètre, et du chiffrage.
Migration — systèmes BW
La discovery n'est pas une fin en soi : à partir d'elle, Migravo reconstruit vos flux dans la plateforme cible en architecture médaillon. On ne repart pas d'une page blanche — on rejoue la sémantique éprouvée de votre BW, couche par couche.
Équivalent de la PSA : les données arrivent telles quelles, en ajout seul, jamais modifiées, horodatées et traçables. Vous pouvez paramétrer une landing zone façon replication flow SAP Datasphere — fichiers Parquet ou CSV dans votre object store, répertoires init/ et delta/ — que la couche Raw consomme telle quelle.
La première persistance après la PSA : gestion du delta et une seule ligne par clé, exactement comme votre couche d'acquisition BW la définit. Vos clés métier, vos modes delta — respectés, pas réinventés. Les tables Raw et Bronze sont nommées d'après la DataSource et son système source, pour une traçabilité sans ambiguïté.
Migravo analyse chaque routine ABAP (start, end, field) et en déduit quelles tables doivent exister en Silver pour y réintégrer la logique métier : calculs, lookups, règles de gestion. Vous savez exactement quoi reconstruire, où, et à quel niveau de complexité — la logique enfouie n'est plus une surprise en fin de projet.
Chaque InfoProvider requêté devient une cible Gold en schéma en étoile : table de faits, dimensions, et la logique des Restricted et Calculated Key Figures (restrictions, formules) décrite pour être reconstruite. La sémantique de reporting n'est pas oubliée — elle est documentée.
Pour les couches Raw et Bronze, Migravo génère le code prêt à déployer — notebooks d'ingestion, gestion du delta, orchestration calée sur la fréquence réelle de vos chaînes. Pour la couche Silver, il déduit des routines les tables porteuses de règles métier et les qualifie ; pour la couche Gold, il cartographie le modèle en étoile et décrit la logique des Key Figures à reconstruire. Le tout conforme au standard LSA++ : quand un flux historique déviait, la cible le remet d'aplomb et chaque adaptation est tracée. Un point de départ robuste, gouvernable, et compréhensible par vos équipes parce qu'il suit la logique qu'elles connaissent déjà.
Tarification
La pré-discovery calcule le coût exact avant tout engagement. Vous créditez le projet du montant estimé, la discovery consomme précisément ce montant. Le même barème s'applique aux cinq profils : une source ODP ou un rapport Z se facture comme un flux, une query SQ00 comme une query, une souscription ODQ comme une dépendance.
| Prestation | Élément facturé | Crédits |
|---|---|---|
| Discovery | Provider requêté (racine) | — |
| Flux — transformation ou DTP | — | |
| Dépendance ABAP détectée | — | |
| Query active | — | |
| Élément Gold — RKF / CKF analysé | — | |
| Table Silver — règle métier à intégrer | — | |
| Master data — par caractéristique analysée | — | |
| Migration | Flux migré — génération Raw + Bronze | — |
| Master data migrée — par caractéristique | — |
Plateformes cibles couvertes par les livrables :
Sécurité
Pas de RFC, pas de connexion directe, pas d'agent. Vous restez maîtres de ce qui sort : des fichiers de metadata que vos équipes ont produits et relus.
Noms d'objets, compositions, flux et statistiques d'usage. Jamais de données transactionnelles ni de données personnelles.
Service opéré sur infrastructure IONOS en Union européenne, chiffrement TLS de bout en bout, suppression des imports sur demande.
Importez vos extractions et obtenez la réponse en quelques minutes. L'estimation est gratuite et n'engage à rien.
Démarrer la pré-discovery