让BI迁移不那么痛苦

说实话，从一个 BI 工具迁移到另一个 BI 工具可能会很痛苦。工作量很大，涉及很多环节，而且很快就会让人不堪重负。我参与过几次 BI 迁移，也见过它们如何迅速演变成横跨几十甚至几百个仪表板、多个数据源和众多利益相关者的数月工作量。我想分享一下我在这过程中学到的东西。

在迁移任何东西之前，先审计你的仪表板

假设你正在使用像 Tableau、Power BI 或 Looker 这样的工具，并且你想把仪表板迁移到一个新的 BI 工具，比如 Metabase。与其把所有东西都复制过去，现在正是审计哪些内容真正在被使用、哪些内容真正在为业务提供价值的好时机。

看着 250 个仪表板然后想“我们得把所有这些都迁移过去”，可能会让人有点不堪重负。所以我喜欢按业务职能来拆解工作。也许你从高管仪表板开始。你看到 25 个仪表板，但只有 3 个在被积极使用。你需要定义什么算“活跃”，但也许这意味着在过去 30 天内被打开过。突然间，范围看起来就 manageable 多了。

对财务、市场、销售以及业务的其他部分做同样的练习。你可能会发现，在这 250 个仪表板中，只有 75 个在被积极使用，其余很多都是一次性需求。

先别发疯开始把所有东西都删掉。我喜欢把这些不活跃的仪表板归档。你很快就会发现，你归档的东西里是否有仍然在被使用的。另外，在归档任何东西之前，一定要检查订阅。一个仪表板可能看起来不活跃，但它可能仍在后台做着某些重要的事情。

如果你归档的某个仪表板最终被证明很重要，那就进一步了解它实际是如何被使用的。如果某人只是每月打开一次来看一个指标，也许那个指标应该归入你已经确定为重要的那 3 个仪表板之一。

现在，你原本 250 个仪表板和数月迁移工作的范围应该会大幅缩减。

附注：即使你不做迁移，也应该这么做。仪表板蔓延随处可见。在 Metabase 中，你可以使用 Collection cleanup 来清理未使用的项目。每季度一次是个不错的频率。

在重建任何东西之前，先清理你的数据层

这是一个清理的好机会。

你可能会发现多个仪表板在使用非常相似的表、自定义查询或计算。可能有人需要快速把一个仪表板推出去，所以他们擅自行动，创建了一个新表，或者硬编码了一个计算，而没有花时间看看已经存在什么。随着时间推移，这些小决定会累积起来，突然间你就有一堆逻辑略有不同的仪表板。

例如，财务团队的某个人需要向董事会报告一个数字，但两个仪表板里的数字对不上。哪个才是正确的？现在你正手忙脚乱地试图弄清楚人们应该相信哪个数字，而信任已经开始受到侵蚀。我讨厌那些 Slack 消息。它们总是很紧急，而且通常会变成一场高压的追查。

这是清理这些问题的好时机。把硬编码逻辑从仪表板中移出，放进 dbt、Metabase Data Studio，或者你们团队管理数据层的任何地方。目标是就逻辑达成一次一致，而不是在每个仪表板里用不同方式重建它。

这也是你创建一个更强大的 语义层 的机会，其中包含每个人都可以使用的可信指标和定义。另一个主要好处是，随着数据世界转向 agentic analytics，以及通过 MCP 之类东西实现的自助服务，如果你的基础扎实，你的 AI 会返回更好的结果。如果你的数据很烂，你得到的答案也会很烂。我会把这当作真正的优先事项，因为它会让你以后的生活轻松很多。

重建你的仪表板（并让 AI 完成大部分工作）

这一直是我在迁移中最喜欢的部分。

在完成审计、与利益相关者沟通、标准化定义并创建语义层之后，你终于能看到这些辛苦工作得到回报。

在我那个年代，我会在左边显示器上打开一个仪表板，然后在右边显示器上重新创建它。这行得通，但它是手动过程，要花时间。

如果我今天做这件事，我可能会截取仪表板的屏幕截图，把它放进像 Claude 这样的工具里，并使用像 Metabase MCP 这样的东西来帮助重新创建它。你甚至可以更进一步，使用 Metabase CLI 来自动化这个过程，并让所有东西都保持 版本控制。

AI 绝对可能出错，但如果它能在你花一两个小时内完成 75% 的工作，那就是巨大的时间节省。在你宣布一个仪表板完成之前，与实际使用它们的人一起把重要指标和旧仪表板进行比较。这有助于建立信任，并让利益相关者对整个迁移这件事感到放心。

在整个迁移过程中让利益相关者保持知情

沟通应该在你开始迁移之前就开始，而不是等它已经完成之后。

让利益相关者知道迁移正在进行、你为什么这么做、时间线大概是什么样，以及这对他们意味着什么。这让人们有时间提出顾虑、告诉你可能遗漏的仪表板，并让他们觉得自己是过程的一部分，而不是某天突然被一个新工具打个措手不及。

在迁移期间，随着他们的仪表板变得可用，持续向利益相关者更新进展。与他们见面，看看他们是否有问题，并确保他们拥有所需的东西。

迁移完成后，告诉所有人你将在什么时候停用旧工具。我还喜欢在过渡期间监控旧工具，看看人们是否还在登录，如果还在登录，就找出原因。另一方面，你可以使用像 Metabase 的使用分析 这样的东西，来确保人们确实在使用和采用新工具。

有时候人们很难接受变化，所以一定要让他们知道你在帮助他们成功。

在最后期限来临前，我想再发最后一次提醒，告诉他们即将无法访问旧工具，并附上新工具的 URL。

总结

BI 迁移远不止是把仪表盘从一个工具搬到另一个工具。它是一个绝佳的机会，可以清理杂乱内容、整理不一致的逻辑，并确保你的数据基础比开始时好得多。

分阶段进行迁移，审查真正重要的内容，并与利益相关者清晰沟通，整个过程就会轻松得多。

如果你正在考虑迁移，或者刚刚开始迁移，不要独自进行。我们已经帮助过很多团队完成这件事，也很乐意和你一起理清思路。联系我们。

相关资源

• 从 Power BI 迁移到 Metabase
• 从 Tableau 迁移到 Metabase
• 从 Looker 迁移到 Metabase