Boreon MCP Layer · Migrations
La plupart de nos migrations font passer Tableau Server à Tableau Cloud, à prix fixes, car Tableau est le point d'ancrage de la plupart des équipes. Nous déplaçons aussi un site Tableau Cloud vers un autre, reconstruisons dans Tableau les tableaux de bord AI/BI de Databricks, apportons vos contenus Tableau sur Databricks, Snowflake ou Tableau Next chaque fois que vous les voulez là aussi, et faisons entrer les tableaux de bord Salesforce CRM et CRM Analytics dans Tableau Next. Chaque déplacement est planifié avec vous, répété d'abord et comparé à l'original.
Depuis Tableau ServerLa plupart des équipes commencent ici
Tableau est le point d'ancrage de la plupart des équipes. Nous déplaçons tout votre site Tableau Server vers Tableau Cloud à prix fixes : contenus et extraits, personnes et autorisations, planifications et abonnements.
Voir comment ça marche
Depuis Tableau Cloud
Déplacez du contenu d'un site Tableau Cloud à un autre, ou faites-le passer du développement au test puis à la production, même entre projets d'un même site. Une nouvelle exécution ne reprend que ce qui a changé depuis la dernière.
Voir comment ça marche
Depuis Databricks
Un tableau de bord AI/BI de Databricks devient un classeur Tableau avec son tableau de bord, qui lit les mêmes tables en direct via une source de données Tableau publiée.
Voir comment ça marche
Depuis Tableau Server ou Tableau Cloud
Les tableaux de bord deviennent des tableaux de bord AI/BI avec Genie intégré. Les flux Prep deviennent des vues matérialisées.
Voir comment ça marche
Depuis Tableau Server ou Tableau Cloud
Les tableaux de bord deviennent des applications Streamlit in Snowflake. Les flux Prep deviennent des tables dynamiques.
Voir comment ça marche
Depuis Tableau Server ou Tableau Cloud
Les feuilles de calcul Tableau, les rapports Salesforce CRM et les widgets CRM Analytics deviennent des visualisations Tableau Next, et leurs tableaux de bord des tableaux de bord Tableau Next, dans Salesforce.
Voir comment ça marche
La plupart de nos migrations sont celle-ci. Nous lisons tout votre site Tableau Server, planifions le déplacement avec vous et le répétons entièrement sans rien écrire. Il ne démarre qu'avec votre accord, puis nous relisons les deux sites pour les comparer, et vous recevez un rapport pour votre registre des changements.
Nous lisons votre site
Chaque projet, classeur, source de données et planification, avant tout déplacement.
Vous lisez le plan
Ce qui bouge, où cela arrive, et ce qui a besoin de vous.
Nous le répétons
Un essai à blanc complet qui n'écrit rien.
Vous approuvez
Le déplacement ne démarre que lorsque vous le décidez.
Nous comparons les deux sites
Relus et vérifiés, avec un rapport pour vos archives.
Nous déplaçons du contenu d'un site Tableau Cloud à un autre, ou le faisons passer du développement au test puis à la production, avec le même plan, la même répétition et la même approbation. Chaque vue est comparée à l'originale, et une nouvelle exécution ne reprend que ce qui a changé depuis la dernière.
Certaines équipes veulent montrer leur travail Databricks aux personnes qui vivent dans Tableau. Un tableau de bord AI/BI devient un classeur Tableau avec son tableau de bord, qui lit les mêmes tables en direct via une source de données Tableau publiée. Chaque feuille est comparée à l'originale avant de pouvoir être publiée, et la publication n'a lieu qu'avec l'accord d'un administrateur de votre côté.
| Sur Databricks | Dans Tableau |
|---|---|
| Un tableau de bord AI/BI | Un classeur Tableau avec son tableau de bord |
| Widgets compteur, barres, lignes, aires, secteurs, nuage de points et tableau | Des feuilles Tableau, chacune comparée à l'originale |
| Zones de texte et mise en page en grille | Les mêmes, sur le tableau de bord |
| Les tables du tableau de bord | Une source de données Tableau publiée, lue en direct |
Si vous voulez aussi des tableaux de bord sur Databricks ou Snowflake, voici où atterrit chaque élément.
| Sur Tableau | Sur Databricks | Sur Snowflake |
|---|---|---|
| Tableaux de bord | Tableaux de bord AI/BI, avec Genie intégré | Applications Streamlit in Snowflake |
| Flux Prep (.tfl) | Vues matérialisées | Tables dynamiques, ou vue matérialisée quand Snowflake le permet |
| Sources de données publiées (.tds) | Les tables Unity Catalog où se trouvent déjà les données | Les tables Snowflake où se trouvent déjà les données |
| Mesures, couleurs et formats de nombre | À l'identique, jusqu'aux axes doubles | À l'identique, jusqu'aux repères et à l'ordre de tri |
| Filtres | Les mêmes filtres, sur le tableau de bord | Des sélecteurs dynamiques dans l'application |
| Connexion et rôles | Rôles SSO propagés, sans seconde connexion | Paire de clés, OAuth, ou chaque personne via Snowflake OAuth |
Un classeur et le flux Prep qui l'alimente migrent ensemble. La table ou la vue est d'abord construite et vérifiée, puis le tableau de bord est reconstruit par-dessus. Rien n'est publié tant que chaque feuille n'est pas validée.
Les projets changent, et parfois l'entrepôt aussi. Boreon MCP Layer transfère vos tables, vos vues et votre SQL de Databricks vers Snowflake, ou de Snowflake vers Databricks, et réécrit le SQL pour l'autre dialecte en chemin. Ensuite, la même couche sémantique couvre les deux entrepôts, et vos équipes continuent de poser leurs questions comme elles l'ont toujours fait.
Databricks Tables, vues et SQL Snowflake
Commencez par celui-là. Nous posons la couche dessus et répondons à ses questions en langage naturel, et si un jour vous le voulez aussi sur une autre plateforme, chaque chiffre est d'abord vérifié par rapport à Tableau.