Background
A company-wide tooling change meant our team's Power BI dashboards (SKU maintenance KPIs, an Amazon Order-to-Cash compliance tracker, a Stord monthly transaction report) needed a new home in Looker Studio. I led that migration, then ran an internal session teaching the rest of the team how to do it for their own dashboards.
My first instinct was to treat it as a reskin: open the old dashboard, recreate every visual one-to-one in the new tool, done. That instinct cost me time twice. Once doing the pointless 1:1 recreation, and again a bit later when I hit a wall because the two tools don't actually work the same way underneath. The visuals should be the last thing you touch. The data model is the first.
Model View vs. Blend
Power BI builds a semantic model. You import or DirectQuery a handful of tables, wire up relationships in Model View, and from then on a DAX measure can reach across any table connected to that model. Total Sales doesn't care whether you're slicing by product, region, or a table three joins away, the model handles it.
Looker Studio doesn't keep a persistent model like that. Each chart draws from a data source, and if a chart needs fields from two sources, you either pre-join them upstream (a view or query does the join before the data reaches Looker Studio) or Blend them at the chart level, which is a runtime join scoped to that one chart and limited to whatever fields you explicitly key on.
Everything else in this post follows from that one difference.
DAX vs. Lexp
Take a measure as simple as Total Sales = SUM(Sales[Amount]). In Power BI it's reusable anywhere the model reaches. Drop it on a matrix sliced by warehouse, by SKU, by month, it resolves correctly through the relationships without you doing anything extra.
The Looker Studio calculated field that does the same job lives inside one specific data source or blend. If the dimension you want to slice by isn't already a field there, the calculated field can't see it. It's not a matter of finding the right setting, it's structurally not there until you add it to the blend.
Which means the planning has to happen earlier than it would in Power BI. Figure out every dimension you'll want to slice by before you build the blend. Adding one later in Power BI is a new relationship. Adding one later in Looker Studio means going back into the blend editor and reworking it, and if you've already got four charts built on top, that's a worse afternoon than it sounds like.
Pre-join or Blend
Once the "no persistent model" part sinks in, you still have to decide, relationship by relationship, whether to resolve it upstream or at chart time.
Pre-join upstream when the relationship is large, stable, and gets reused across a lot of charts. A view in the warehouse or a formula column in the source sheet keeps that join logic versioned somewhere sane instead of clicked together in a UI, and every chart built on it stays fast because the join already happened before Looker Studio saw the data.
Blend at chart time when it's one-off or exploratory or specific to a single chart. Pre-joining every possible combination "just in case" gets you a pile of near-identical source views that end up harder to maintain than the blends they were supposed to replace.
It's the same call as materialized views vs. ad hoc joins in a warehouse. It just shows up inside a BI tool instead of a pipeline, which makes it easy to forget it's the same decision you already know how to make.
| Power BI concept | Looker Studio equivalent | What changes |
|---|---|---|
| Model View (relationships) | Blend (or a pre-joined source) | Relationships aren't persistent: rebuild the join per blend, or push it upstream |
| DAX measure | Calculated field (Lexp) | Scoped to one source/blend, not the whole model |
| Edit Interactions | Cross-filter (on by default) | Looker Studio ships chart-to-chart filtering by default; Power BI needs it set per visual |
| Import / DirectQuery | Native connectors (Sheets, BigQuery, …) | Fewer steps if your source already lives where Looker Studio connects natively |
The connector turned out to matter
A chunk of our source data was already staged in Google Sheets, the output of a Snowflake extraction pipeline and a couple of Apps Script consolidation jobs. Looker Studio's native Sheets connector meant those dashboards could point straight at that data. Getting the same Sheet into Power BI usually meant an export step or a less direct connector. Small detail on paper, but it turned "where does this dashboard actually get its data" from a multi-step answer into a one-step one, and that matters when you're trying to get a teammate to trust a dashboard enough to own it themselves.
The training mattered more than the migration
The dashboards were the easy part, honestly. The bigger problem sat upstream: dashboard-building had been gate-kept behind a dedicated BI team that treated small departmental requests as low priority, so our team had no visibility into its own KPIs and no way to get any without waiting in a queue.
So the migration turned into an excuse for a training session, walking through Model View → Blend, DAX → Lexp, and the pre-join-vs-blend call, using our own dashboards as the examples the whole way through. I wasn't trying to show off how I'd done it. I wanted people to leave able to do it themselves. A few teammates built their own Looker Studio dashboards afterward and took over KPI tracking for their own areas without routing through me or a BI team queue.