BI tool switching costs depend primarily on where metric definitions live. Tools that own the semantic layer accumulate migration debt proportional to usage duration. Tools that read from an external semantic layer — or that have no semantic layer — are easier to replace.
The Portability Axis
There’s a spectrum of BI tool portability, and it maps closely to the semantic layer ownership question:
Highest switching cost: LookML (Looker). Your semantic definitions live in a proprietary modeling language that only Looker reads. Years of LookML development produce complex derived tables, access grants, and dimension hierarchies that have no direct equivalent elsewhere. Moving away from Looker means either rewriting all of this from scratch or accepting that the new tool gets a stripped-down version of your modeling work.
Medium switching cost: Metabase per-question definitions. Metrics in Metabase aren’t centrally governed — they’re embedded in individual questions and dashboards. This actually makes individual definitions easy to recreate (they’re usually simple SQL fragments), but it means there’s nothing to “export” in a structured way. You’re starting from scratch in the new tool, but from scratch without the weight of accumulated proprietary syntax.
Lowest switching cost: dbt YAML. If your metrics are defined in your dbt project via MetricFlow, those definitions are warehouse-agnostic, tool-agnostic, and human-readable. Lightdash reads them. Evidence reads them. Omni reads them. Any tool connecting to the dbt Semantic Layer API reads them. Switching BI frontends becomes a frontend concern only — your semantic definitions don’t move.
Migrating Away from Looker
Looker migration attracts the most attention because it’s the most common “we outgrew our budget” scenario. A few observations from teams that have done it:
Moving to Lightdash is the most well-worn path if dbt already exists alongside Looker. Lightdash offers a one-click migration service that translates LookML content into Lightdash-compatible format. The catch: LookML features that have no Lightdash equivalent need reimplementation. Derived tables — Looker’s mechanism for defining a SQL query that produces a virtual table used as a dimension or measure — require converting into actual dbt models or Lightdash custom SQL. Complex access grants with user attributes need translation into Lightdash’s permission model.
The good news: if your team has been using dbt alongside Looker (as many mature data teams do), the core modeling is already in dbt. LookML was a presentation and governance layer on top. The migration effort is removing the LookML layer, not rebuilding the transformation layer.
Moving to any other tool is harder without dbt as an intermediate. If LookML has been your only modeling layer, you’re migrating both the semantic definitions and rediscovering the business logic embedded in them — because LookML’s derived tables and dynamic SQL generation often encode logic that isn’t obvious to reconstruct.
Gartner estimates that organizations spend 40-60% of their total Looker investment on LookML development and maintenance. When those teams decide to migrate, the accumulated LookML represents a corresponding investment in something they can no longer easily move.
Migrating Away from Metabase
Migration from Metabase is structurally different. There’s less to move — but that’s the problem.
Metabase’s lack of a central semantic layer means your “metrics” are per-question SQL fragments scattered across hundreds of questions and dashboards. There’s no canonical revenue definition to export; there are fifty different queries that each calculate something called “revenue” in slightly different ways. Before migrating, you have to decide: which one is correct? This is less a migration problem and more a metric governance problem that the migration forces you to finally solve.
If you’re moving to Lightdash, this is actually the harder direction. Building a dbt modeling layer from scratch — defining all the semantic models, measures, and metrics in MetricFlow YAML — is the prerequisite work that Metabase users often haven’t done. The migration isn’t moving content; it’s building infrastructure.
# What you're building for the first time when migrating 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'Every metric that was previously defined ad-hoc in Metabase questions needs to become an explicit, reviewed, version-controlled YAML definition. For teams with 50+ dashboards, this is a meaningful project — but also an opportunity to eliminate years of accumulated metric inconsistency.
The dbt YAML Ecosystem Advantage
The portability argument for dbt-centric metrics-as-code is strongest when you consider how many tools can read dbt YAML:
- Lightdash — reads directly from dbt project YAML
- Evidence — SQL + Markdown reports deployed as static sites, with dbt as the data layer
- Omni — YAML-like modeling aligned with dbt workflows
- Steep — integrates with dbt Cloud semantic layer
- Any tool connecting to the dbt Cloud Semantic Layer API via JDBC, GraphQL, or REST
When your metrics live in dbt YAML, switching BI frontends is a frontend decision. You’re choosing a different visualization and exploration layer, not rebuilding your semantic definitions. The metric for “monthly recurring revenue” doesn’t change; only how users see it changes.
This is the architectural position of dbt-centric teams: invest in the semantic layer once, in a portable format, and treat BI tools as commodity frontends.
The Hybrid Reality
Most organizations don’t actually do clean migrations. They add tools alongside existing ones, and the “migration” happens over 2-3 years as the new tool earns trust and the old one gets used less.
A pattern that works: keep the legacy tool (or Metabase) for financial reporting and board decks where the formatting and workflow are established. Add Lightdash or another dbt-native tool for the 80% of ad-hoc questions that analytics engineers field daily. Run both in parallel. Let the new tool prove itself on lower-stakes work before you attempt to migrate the CFO’s quarterly dashboard.
This hybrid approach has an often-underappreciated benefit: it forces the metric standardization that makes eventual migration possible. When Lightdash and Metabase both need to show “revenue,” and both consume the same MetricFlow definition, you’ve solved the consistency problem as a side effect of running two tools.
What to Evaluate Before Committing
Before signing a multi-year enterprise BI contract, three questions reduce future migration pain:
Where do metric definitions live? If the answer is “inside the BI tool’s proprietary format,” you’re accumulating migration debt from day one. If the answer is “in dbt YAML or another open format,” you’re building portable infrastructure.
What’s the export story? Most BI tools offer some form of API access or export. Looker’s LookML is text files that can be extracted. Metabase has a REST API that returns question definitions as JSON. Lightdash/Evidence definitions are just files in your Git repo. The quality of the export determines how much of your modeling work survives a migration.
How long would a migration take? For a 3-year Looker deployment with 2,000 LookML fields, a realistic migration estimate is 6-18 months of engineering effort. For a Metabase deployment with no semantic layer, the migration time is the time to build the semantic layer from scratch — highly variable depending on how many metrics need to be standardized. For a Lightdash deployment, switching to another dbt-native tool could take weeks.
Where business logic lives determines how expensive a future migration will be.