Inventory before estimate
We list every LookML view, explore, and dashboard with its owner and last-viewed date. You get a rebuild / merge / retire recommendation for each one before anyone commits to a budget.
Leaving Google Cloud Looker
A Looker to Power BI migration that keeps your BigQuery model and dashboards intact
A senior-led Looker to Power BI migration: we inventory your LookML views and explores, rebuild them as a governed Power BI semantic model with DAX measures, recreate every dashboard and Look, and keep BigQuery exactly where it is.
Representative dashboard — sample data
Why teams move
Looker's per-viewer pricing and LookML dependency add up
Most Looker to Power BI migrations start the same way: a renewal quote arrives, someone totals up the per-viewer and per-developer cost against a Microsoft 365 estate the organization already pays for, and the question becomes whether reporting can move before the next invoice. The other push is people — LookML lives in a Git repo that only a handful of analytics engineers can safely edit, and that single point of failure gets uncomfortable as the team grows.
The work splits into three parts: inventorying what LookML views and explores are actually used, rebuilding them on a governed semantic model, and proving the rebuilt dashboards agree with the originals. BigQuery does not move — only the modeling and visualization layer changes.
What the migration covers
- LookML inventory
- Explore → semantic model
- BigQuery retained
- Measures → DAX
- Dashboard recreation
- Embedded migration
Try us risk-free for 4 hours
Start with a block of prepaid Flex hours and, if you're unhappy within the first 4 hours, we refund you in full — no questions asked. A LookML and explore inventory is a good first task: it tells you the real size of the job before you commit to it.
How we approach it
A migration that ends with trusted numbers
Rebuilding charts is the easy half. The value is in what gets consolidated, what finally gets a single definition, and what stays exactly where it is.
BigQuery stays your source
The migration replaces Looker's semantic and visualization layer, not the warehouse. Power BI connects to BigQuery natively, so pipelines and access controls stay untouched.
A model, not scattered explores
LookML lets logic live per-view and per-explore, which is why two dashboards can quietly disagree. We rebuild onto one governed semantic model so a measure is defined once and reused everywhere.
Reconciled before sign-off
Every rebuilt Look and dashboard is compared to its Looker original on the same date range. Differences get explained, not hand-waved — and some of them turn out to be fixes.
Embedded analytics carried over
If your app embeds Looker dashboards for customers, the Embed SDK integration is rebuilt against Power BI Embedded's REST API and embed tokens, tested in staging first.
Sequenced around your renewal
High-value explores and dashboards move first so the Looker instance can be switched off on schedule rather than extended for one straggler nobody triaged.
What actually has to be rebuilt?
LookML and Power BI solve the same modeling problem with different architecture, so this is a rebuild with a known map, not a file conversion. Looker separates concerns across view files, model files, and explores; Power BI folds all of that into one semantic model with tables, relationships, and DAX measures. The concepts transfer; the syntax and where the logic lives do not.
Scope note: this page covers Google Cloud Looker, the enterprise LookML-based BI platform — not Looker Studio (formerly Google Data Studio), which is a different, free reporting tool with no LookML layer. If what you're actually running is Looker Studio connected to Google Analytics, see our Google Analytics Power BI dashboard guide instead.
BigQuery is worth stating plainly: it does not move. Power BI's native BigQuery connector reads the same datasets your LookML models already point to, over DirectQuery or Import mode, so the migration is scoped to the modeling and visualization layer — not a warehouse re-platform.
How do LookML and Looker concepts map to Power BI?
Here is the practical mapping we work from. It is deliberately unglamorous — the point of a migration is that nothing surprising happens in week three.
| Looker / LookML | Power BI equivalent | What changes in practice |
|---|---|---|
| View file | Table (Power Query query) | A view's underlying SQL table or derived table becomes a query bound into the model |
| Explore (joins & relationships) | Model relationships (star schema) | join_on and relationship type declarations are rebuilt as explicit table relationships |
| Dimension / dimension_group | Column, plus a proper date table | Time-based dimension groups become a dedicated date table with real time intelligence |
| Measure (sum, count, average, etc.) | DAX measure | Aggregation logic is rewritten in DAX; filtered measures typically need CALCULATE |
| Derived table (SQL or LookML-based) | Power Query transformation or dataflow | Complex derived-table SQL is rebuilt as M steps, or pushed to a Dataflow for reuse |
| Access filter / permission set / user attribute | Row-level security role | User-attribute-based filtering becomes a governed, testable RLS role |
| Look / dashboard tile | Report visual / report page | Looks become individual visuals; dashboards become report pages with the same slicers |
| Embed SDK / signed embed URL | Power BI Embedded (REST API + embed token) | The surrounding app integration is rebuilt; the end-user experience doesn't have to change |
| BigQuery connection | Power BI BigQuery connector (Import or DirectQuery) | The warehouse stays BigQuery; only the semantic and visualization layer changes |
Row-level security rebuilds deserve their own scoped task rather than being folded into a report migration — our guide to Power BI row level security setup covers how we test it. For the storage-mode decision behind the BigQuery connection, see DirectQuery vs Import mode and Microsoft's own Power BI BigQuery connector documentation (opens in new tab). The rebuild itself draws on our Power BI data modeling and DAX work.
How much does a Looker migration cost?
Work runs on prepaid Flex hours that never expire: Starter 20 hours at $125/hr ($2,500), Growth 40 hours at $115/hr ($4,600), or Power 80 hours at $100/hr ($8,000). A LookML and explore inventory typically fits inside a Starter block, and it is the task we recommend buying first because it tells you the size of everything that follows.
After that, cost tracks how many explores and dashboards survive triage and how much logic they carry — a straightforward explore is a different job from one built on nested derived tables and nine joined views. You get an estimate in hours per dashboard, approve what you want built, and unused hours stay banked.
How long does the move take?
Individual dashboards usually ship within 3–5 business days of approval, and a phased migration runs as a sequence of those tasks rather than one long project with a big-bang cutover. Larger estates get a clear timeline once the inventory shows what's really there.
Running Looker and Power BI in parallel for one reporting cycle is worth the overlap cost — users compare old and new outputs on live BigQuery data, trust builds quickly, and you retire the Looker instance knowing nothing was left behind.
Who this is for
Teams running Google Cloud Looker on BigQuery, with an existing Microsoft 365 or Azure estate and dashboards people genuinely depend on. It is not for organizations wanting a lift-and-shift with no decisions made — that produces a more expensive copy of the problem you already have. Mixed estates are common: our core Power BI migration service covers the Excel route, Tableau to Power BI migration is the same page family for teams also leaving Tableau, Qlik to Power BI migration covers Qlik Sense and QlikView, and Domo to Power BI migration covers Domo. The nearest relative to this page is search-first analytics: our ThoughtSpot to Power BI migration page works from exported TML in the same way this one works from LookML, and adds the question Looker never raises — what business users do once the search bar is gone.
What you get
- LookML inventory with usage data
- Rebuild / merge / retire recommendation
- A governed semantic model on BigQuery
- Reconciliation against the Looker originals
- Handover docs and a user walkthrough
3–5
business days per dashboard
Phased
not big-bang
You
own everything
Start with the LookML inventory task and decide the rest once you can see the real scope. See Flex pricing.
How it works
From LookML estate to trusted Power BI reporting
- 1
Inventory and triage
We catalogue every LookML view, explore, and dashboard with owner, usage, and BigQuery sources, then recommend what to rebuild, merge, or retire. You approve the list before anything is built.
- 2
Rebuild on a semantic model
Surviving explores are rebuilt on one governed Power BI semantic model connected to BigQuery, with LookML measures and derived tables reconstructed as tested DAX and Power Query.
- 3
Reconcile and hand over
We compare rebuilt dashboards to the Looker originals, explain every difference, publish to your workspace, migrate any embedded integration, and walk the users through where things moved.
Representative perspective
The explore inventory was the eye-opener — half our explores hadn't been opened in months, and the ones that mattered had logic scattered across three view files.Analytics lead, mid-market SaaS company
Representative perspective
Keeping BigQuery in place made the internal conversation easier — this was a reporting-layer change, not a data-platform migration, and IT signed off quickly.Director of data, e-commerce brand
Find out what your Looker migration actually involves
Tell us roughly how many explores and dashboards you have and when your Looker renewal lands. We'll scope the inventory task in hours so you know the real size before committing.
FAQ
Migration questions, answered
No. There is no reliable one-click converter, because LookML separates logic across view files, explores, and model files in a way Power BI's unified semantic model does not. Each view, join, dimension, and measure is inventoried and rebuilt by hand, then reconciled against the Looker output before it counts as done.
An explore's base view and joined views become fact and dimension tables linked by explicit relationships, replacing join_on and relationship type declarations. LookML dimensions become columns, and measures are rewritten as DAX so the same aggregation logic runs inside Power BI's engine instead of Looker's.
No. BigQuery stays exactly where it is. Power BI connects to it natively over DirectQuery or Import mode, so the migration replaces the semantic and visualization layer that Looker provided, not the warehouse underneath it. Your existing BigQuery pipelines, datasets, and access controls are untouched.
Yes, though the surrounding integration code changes even when the end-user experience doesn't have to. Signed embed URLs from the Looker Embed SDK are replaced with Power BI Embedded's REST API and embed tokens, and we test the swap against a staging build before it touches your production app.
User-attribute-based access filters and permission sets are rebuilt as Power BI row-level security roles, then tested by viewing the report as each role. It is a governed, testable equivalent rather than a like-for-like copy, which is usually an improvement over scattered per-explore access filters.
Related work
This page covers the Google Cloud Looker path specifically — mixed-estate links for Tableau, Qlik, and Domo are above. The semantic model rebuild itself draws on Power BI data modeling and DAX work, and once the estate is live, a Power BI health check keeps refresh and performance honest. Every task is scoped from your prepaid block of senior-led hours — no project minimums, no change-order surprises, and hours are deducted only for work you approve.
Book a free demo
Get senior Power BI help, on demand
Tell us the task. We scope it, you approve, and a senior consultant delivers — typically in 3–5 business days. Prepaid hours that never expire.
- Prepaid hours from $100/hour — and they never expire
- Senior-led delivery — 20+ years on the Microsoft platform
- Typical 3–5 business day turnaround
- Full refund if you’re unhappy in your first 4 hours
The fastest way to reach us is the form — tell us the task and we'll reply within one business day.