Les coûts de migration entre outils BI dépendent principalement de l’endroit où vivent les définitions de métriques. Les outils qui possèdent la couche sémantique accumulent une dette de migration proportionnelle à la durée d’utilisation. Les outils qui lisent depuis une couche sémantique externe — ou qui n’en ont pas — sont plus faciles à remplacer.
L’Axe de Portabilité
Il existe un spectre de portabilité des outils BI, qui correspond étroitement à la question de propriété de la couche sémantique :
Coût de migration le plus élevé : LookML (Looker). Vos définitions sémantiques vivent dans un langage de modélisation propriétaire que seul Looker lit. Des années de développement LookML produisent des tables dérivées complexes, des autorisations d’accès et des hiérarchies de dimensions qui n’ont pas d’équivalent direct ailleurs. Quitter Looker signifie soit réécrire tout cela de zéro, soit accepter que le nouvel outil dispose d’une version appauvrie de votre travail de modélisation.
Coût de migration moyen : Les définitions par question de Metabase. Les métriques dans Metabase ne sont pas gouvernées de manière centralisée — elles sont intégrées dans des questions et des dashboards individuels. Cela rend les définitions individuelles faciles à recréer (ce sont généralement de simples fragments SQL), mais cela signifie qu’il n’y a rien à « exporter » de manière structurée. Vous recommencez de zéro dans le nouvel outil, mais de zéro sans le poids de la syntaxe propriétaire accumulée.
Coût de migration le plus faible : dbt YAML. Si vos métriques sont définies dans votre projet dbt via MetricFlow, ces définitions sont agnostiques à l’entrepôt, agnostiques aux outils et lisibles par des humains. Lightdash les lit. Evidence les lit. Omni les lit. Tout outil se connectant à l’API de la couche sémantique dbt les lit. Changer de frontend BI devient uniquement une question de frontend — vos définitions sémantiques ne bougent pas.
Migrer depuis Looker
La migration depuis Looker attire le plus d’attention car c’est le scénario « nous avons dépassé notre budget » le plus courant. Quelques observations d’équipes qui l’ont fait :
Passer à Lightdash est le chemin le plus fréquenté si dbt existe déjà aux côtés de Looker. Lightdash propose un service de migration en un clic qui traduit le contenu LookML en format compatible Lightdash. Le bémol : les fonctionnalités LookML qui n’ont pas d’équivalent Lightdash nécessitent une réimplémentation. Les tables dérivées — le mécanisme de Looker pour définir une requête SQL qui produit une table virtuelle utilisée comme dimension ou mesure — doivent être converties en vrais modèles dbt ou en SQL personnalisé Lightdash. Les autorisations d’accès complexes avec des attributs utilisateur doivent être traduites dans le modèle de permissions de Lightdash.
La bonne nouvelle : si votre équipe a utilisé dbt aux côtés de Looker (comme beaucoup d’équipes data matures le font), la modélisation centrale est déjà dans dbt. LookML était une couche de présentation et de gouvernance par-dessus. L’effort de migration consiste à supprimer la couche LookML, pas à reconstruire la couche de transformation.
Passer à tout autre outil est plus difficile sans dbt comme intermédiaire. Si LookML a été votre seule couche de modélisation, vous migrez à la fois les définitions sémantiques et vous re-découvrez la logique métier intégrée dedans — car les tables dérivées LookML et la génération SQL dynamique encodent souvent une logique qui n’est pas évidente à reconstruire.
Gartner estime que les organisations dépensent 40 à 60% de leur investissement total Looker en développement et maintenance LookML. Quand ces équipes décident de migrer, le LookML accumulé représente un investissement correspondant dans quelque chose qu’elles ne peuvent plus facilement déplacer.
Migrer depuis Metabase
La migration depuis Metabase est structurellement différente. Il y a moins à déplacer — mais c’est précisément le problème.
L’absence de couche sémantique centrale dans Metabase signifie que vos « métriques » sont des fragments SQL par question dispersés à travers des centaines de questions et dashboards. Il n’existe pas de définition canonique de revenue à exporter ; il y a cinquante requêtes différentes qui calculent chacune quelque chose appelé « revenue » de manières légèrement différentes. Avant de migrer, vous devez décider : laquelle est correcte ? C’est moins un problème de migration qu’un problème de gouvernance des métriques que la migration vous force enfin à résoudre.
Si vous passez à Lightdash, c’est en réalité la direction la plus difficile. Construire une couche de modélisation dbt de zéro — définir tous les modèles sémantiques, mesures et métriques dans le YAML MetricFlow — est le travail préalable que les utilisateurs de Metabase n’ont souvent pas fait. La migration ne consiste pas à déplacer du contenu ; elle consiste à construire une infrastructure.
# Ce que vous construisez pour la première fois en migrant Metabase → Lightdashsemantic_models: - name: orders defaults: agg_time_dimension: order_date entities: - name: order_id type: primary measures: - name: order_total agg: sum expr: amount
metrics: - name: revenue type: simple type_params: measure: order_total filter: | {{ Dimension('order_id__status') }} = 'completed'Chaque métrique qui était auparavant définie de manière ad hoc dans les questions Metabase doit devenir une définition YAML explicite, révisée, versionnée. Pour les équipes avec 50+ dashboards, c’est un projet significatif — mais aussi une opportunité d’éliminer des années d’incohérence accumulée dans les métriques.
L’Avantage de l’Écosystème dbt YAML
L’argument de portabilité pour les métriques-as-code centré sur dbt est le plus fort quand vous considérez combien d’outils peuvent lire le YAML dbt :
- Lightdash — lit directement depuis le YAML du projet dbt
- Evidence — rapports SQL + Markdown déployés comme sites statiques, avec dbt comme couche de données
- Omni — modélisation de type YAML alignée sur les workflows dbt
- Steep — s’intègre avec la couche sémantique dbt Cloud
- Tout outil se connectant à l’API de la couche sémantique dbt Cloud via JDBC, GraphQL ou REST
Quand vos métriques vivent dans le YAML dbt, changer de frontend BI est une décision de frontend. Vous choisissez une couche de visualisation et d’exploration différente, pas de reconstruire vos définitions sémantiques. La métrique pour le « revenu récurrent mensuel » ne change pas ; seule la façon dont les utilisateurs la voient change.
C’est la position architecturale des équipes centré sur dbt : investir dans la couche sémantique une fois, dans un format portable, et traiter les outils BI comme des frontends interchangeables.
La Réalité Hybride
La plupart des organisations ne font pas de migrations propres. Elles ajoutent des outils aux côtés des existants, et la « migration » se produit sur 2 à 3 ans à mesure que le nouvel outil gagne en confiance et que l’ancien est de moins en moins utilisé.
Un pattern qui fonctionne : conserver l’outil legacy (ou Metabase) pour le reporting financier et les présentations au board où le formatage et le workflow sont établis. Ajouter Lightdash ou un autre outil natif dbt pour les 80% de questions ad hoc que les analytics engineers traitent quotidiennement. Faire tourner les deux en parallèle. Laisser le nouvel outil faire ses preuves sur des travaux moins critiques avant d’essayer de migrer le dashboard trimestriel du DAF.
Cette approche hybride a un avantage souvent sous-estimé : elle force la standardisation des métriques qui rend éventuellement la migration possible. Quand Lightdash et Metabase ont tous deux besoin d’afficher les « revenus », et que les deux consomment la même définition MetricFlow, vous avez résolu le problème de cohérence comme effet secondaire du fait de faire tourner deux outils.
Ce qu’il Faut Évaluer Avant de S’Engager
Avant de signer un contrat BI enterprise pluriannuel, trois questions réduisent la douleur future de migration :
Où vivent les définitions de métriques ? Si la réponse est « dans le format propriétaire de l’outil BI », vous accumulez de la dette de migration dès le premier jour. Si la réponse est « dans le YAML dbt ou un autre format ouvert », vous construisez une infrastructure portable.
Quel est le scénario d’export ? La plupart des outils BI offrent une forme d’accès API ou d’export. Le LookML de Looker est des fichiers texte qui peuvent être extraits. Metabase dispose d’une API REST qui retourne les définitions de questions en JSON. Les définitions Lightdash/Evidence ne sont que des fichiers dans votre dépôt Git. La qualité de l’export détermine combien de votre travail de modélisation survit à une migration.
Combien de temps prendrait une migration ? Pour un déploiement Looker de 3 ans avec 2 000 champs LookML, une estimation réaliste de migration est de 6 à 18 mois d’effort d’ingénierie. Pour un déploiement Metabase sans couche sémantique, le temps de migration est le temps de construire la couche sémantique de zéro — très variable selon le nombre de métriques à standardiser. Pour un déploiement Lightdash, passer à un autre outil natif dbt pourrait prendre quelques semaines.
L’endroit où vit la logique métier détermine le coût d’une migration future.