Migrate from Looker Studio to Looker: When, How, How Much

Migrating from Looker Studio to Looker is justified when your reports contradict each other, when you need per-user data filtering, or when the BigQuery bill behind the reports can no longer be steered. It is not a file conversion: you model the metrics in LookML first, then rebuild the handful of dashboards that matter. For a well-scoped perimeter, plan on six to twelve weeks; the consulting budget is quoted after the inventory, Looker licences excluded.

Naming note: Google renamed Looker Studio to Data Studio in April 2026. The product and your reports are unchanged; this guide keeps the name you searched for.

Should you migrate at all?

Before planning anything, check that the problem is the tool. Three common cases where migration is not the answer.

Your reports are slow because they query raw tables. The fix is an aggregated BigQuery table, possibly a dbt layer, not Looker. Cost: a few days.

Your reports are scattered across personal Drives. Data Studio Pro ($9 per user, per project, per month) brings team workspaces. Cost: almost nothing.

One person builds every report and nobody disputes the numbers. Looker would add a model to maintain with no benefit.

Migration is the right answer when at least two of these hold: several teams publish diverging metrics, you need row-level security that would survive an audit, you want history and review on changes, or you are preparing conversational agents that must answer correctly.

What the migration is not

There is no tool that converts a Looker Studio report into a Looker dashboard, and that is good news. The two products start from opposite ends: Looker Studio starts from a chart and attaches data to it; Looker starts from a model and attaches charts to it. Reproducing sixty Looker Studio reports one-for-one in Looker imports the mess along with the data.

A successful migration looks like this instead: an inventory, a ruthless cull, a LookML model for the metrics that survive, and a dozen dashboards rebuilt cleanly.

The steps

Week 1: inventory and triage

List every Looker Studio report with its owner, its real audience (Looker Studio's view statistics help), its sources and its calculated fields. The usual result: 20 percent of reports account for 90 percent of views, and half have not been opened in three months.

For each report you keep, extract the metrics and their formulas. This is where the divergences surface: marketing's "conversion rate" and sales' "conversion rate" share neither numerator nor denominator. These must be settled by the business before a line of LookML is written.

Weeks 2 and 3: prepare BigQuery

Looker assumes clean tables underneath. If your Looker Studio reports read GA4, Google Ads or Sheets directly, those sources first need to land in BigQuery (native BigQuery Data Transfer for Google Ads and GA4, connectors for the rest), then be shaped into fact and dimension tables at the right grain, ideally with dbt.

This step is routinely underestimated. It is half the effort, and it is what makes everything after it simple.

Weeks 3 to 6: model in LookML

Start with a single Explore, the one carrying the most disputed metric, usually revenue or orders. One fact view, two or three dimensions (date, customer, product), the measures settled in week 1, and a datagroup aligned with your daily load.

explore: orders {
  persist_with: daily_load
  join: customers {
    sql_on: ${orders.customer_id} = ${customers.customer_id} ;;
    relationship: many_to_one
  }
}

Validate this Explore with the people who disputed the numbers, until they get the same result as their old report, or understand why the old one was wrong. Only then expand to other domains.

From the first Explore, lay the foundations that are expensive to retrofit: primary_key on every view, label and description on every field, access_filter if you have multi-entity data, and a Git repository with mandatory pull requests.

Weeks 6 to 9: rebuild the dashboards

Rebuild the ten to fifteen surviving dashboards from scratch rather than imitating the old ones. Fewer tiles, shared filters, drill links into Explores instead of separate detail reports. For executive dashboards aim for under twelve tiles and under ten seconds to open.

Run old and new side by side for two to four weeks. Publish the retirement date for the old reports and hold it.

Weeks 9 to 12: open up, train, decommission

Train analysts on exploration (two hours covers the essentials) and developers on LookML and the Git flow. Switch the old Looker Studio reports to read-only, then archive them. If teams want to keep building quick visuals, the Looker connector for Looker Studio gives them governed Explores without touching the model.

What to model first

Order matters because the first Explore sets the conventions.

Priority	Domain	Why first
1	Revenue and orders	The most disputed metric, the most visible to leadership
2	Customers and segments	Needed for any cohort analysis, feeds the filters
3	Acquisition (GA4, Ads)	Large volume of existing reports, often the source of divergences
4	Operations, inventory, support	More stable domains, migrated last

Do not model reports "just in case". If a metric appears on none of the surviving dashboards, it waits.

The pitfalls

Migrating reports one by one, as-is. You get a Looker as messy as the old Looker Studio, plus an annual licence.

Pointing Looker at raw tables. Explores will be slow, PDTs will multiply to compensate, and the BigQuery bill will climb. Modelling belongs in dbt or prepared tables; Looker is the semantic layer.

Skipping the business arbitration. If finance and sales do not agree on the revenue definition before the migration, you will have two measures in LookML and the same problem as before, at a higher price.

Underestimating licences. Every Looker viewer needs a licence. A Looker Studio report shared by link with two hundred people does not transfer for free. Count real readers and plan Viewer licences, or keep Looker Studio (through the Looker connector) for broad distribution.

Not naming a model owner. Without one person responsible for the LookML, in-house or external, the model degrades within six months.

Realistic timeline and budget

The ranges below reflect projects delivered remotely and asynchronously, with a business contact available two hours per week.

Scope	Timeline	Consulting (excl. licences)
One domain (revenue, orders), 3 to 5 dashboards	4 to 6 weeks	quoted after the inventory
Two or three domains, 10 to 15 dashboards	8 to 12 weeks	quoted, split into lots
Multi-entity scope with row-level security and a full dbt layer	3 to 5 months	quoted

Add to that: Looker licences (annual commitment, quote from Google, ten Standard users and two Developer users included in every edition), BigQuery costs, and internal validation time. Two to three days of maintenance per month after delivery keeps the model from decaying.

What we see in production: in a large industrial group, the Looker semantic layer on BigQuery has served the executive dashboards for several years. What lasted was not the number of dashboards delivered but the decision to start with one Explore validated by the people who disputed the numbers.

FAQ

Can we keep Looker Studio after the migration?

Yes, and it is often the right setup. The Looker connector for Looker Studio reads governed Explores; marketing teams keep their tool, definitions stay in LookML. Looker (Google Cloud core) customers can claim complimentary Pro licences.

Do we need dbt to migrate to Looker?

Not strictly, but strongly recommended as soon as you have more than two sources. dbt carries transformations and tests; Looker carries semantics. Without dbt, transformation logic ends up in Looker derived tables that are hard to test.

How long should the old reports stay open?

Two to four weeks in parallel, with a retirement date announced from the start. Beyond that users do not switch and you maintain two systems.

Can a small business afford Looker?

The Standard edition targets organisations under 50 users, but the commitment is annual and consulting comes on top. Under twenty readers with no governance requirement, a clean dbt layer under Looker Studio delivers 80 percent of the benefit for a fraction of the price.

Next step

If you recognised your reports in the opening lines, start with the inventory: one spreadsheet, the reports, their audiences, the metrics and their formulas. On its own it shows whether the migration is justified, and in what order.

See the BigQuery, dbt, Looker semantic layer service, and read next: Looker vs Looker Studio and Looker pricing in 2026.

Sources

• Looker Studio is Data Studio, Google Cloud Blog, April 2026
• Looker pricing, platform editions
• Data Studio product page, Pro pricing