Looker to Power BI Migration Services

Looker to Power BI migration services cover two different jobs. Moving off Looker means translating a LookML project — views, explores, derived tables, access filters — into a Power BI semantic model, then rebuilding the Looks and dashboards on top of it. Moving off Looker Studio means turning report-scoped data sources, blends and calculated fields into one shared model, which is often the first real model the team has ever had. In both cases there is no converter: nothing in Power BI reads a .lkml file or a Looker Studio report, so the semantic model is rebuilt deliberately and every number is reconciled against the original before the old platform is switched off.

If your estate is on another platform, the same discipline applies with different translation work: Tableau to Power BI migration services covers workbooks, extracts and LOD expressions, and Qlik to Power BI migration services covers load scripts and set analysis. For migrations off spreadsheets or older on-premises reporting tools, business intelligence migration services is the general engagement.

What migrates and what does not

What carries across from Looker is the logic, not the files. The SQL inside each dimension and measure, the join conditions in each explore, the definitions behind derived tables and the user attributes behind access filters are all the specification for the Power BI model. Read as a specification, a well-kept LookML project is an unusually good starting point, because the business logic is written down in one version-controlled place instead of scattered across workbooks.

What does not carry across is everything Looker generates at query time. Looker writes SQL on the fly for each query, applies symmetric aggregates to protect measures from join fan-out, and resolves Liquid templating inside the SQL. Power BI works differently — a model of tables and relationships, measures written in DAX, and filter context instead of generated SQL — so those behaviours have to be re-created by design, not copied. Dashboard layouts, tile arrangements and conditional formatting are rebuilt by hand, and schedules, alerts and delivery destinations are set up again in the Power BI service.

Inventory comes first. Looker's System Activity explores show which dashboards and Looks are actually viewed, by whom and how recently, which turns a migration into a ranked list rather than a full copy. Content nobody has opened in months is a retire candidate, signed off by its owner, and every hour not spent rebuilding it goes into reconciling the reports people do use.

• Migrates as specification: dimension and measure SQL, explore joins, derived table definitions, access filters and user attributes
• Rebuilt by design: the semantic model, relationships, DAX measures and row-level security roles
• Rebuilt by hand: dashboards, Looks, tile layouts and formatting
• Recreated in the service: schedules, data alerts, sharing and workspace permissions
• Not carried across at all: Liquid templating, symmetric aggregates and Looker's query-time SQL generation

LookML to DAX: the translation layer

Each LookML view becomes a table in the model. Plain dimensions become columns, usually computed upstream in SQL or Power Query rather than as DAX calculated columns. A dimension_group of type time becomes a relationship to a proper date table, which gives every report the same calendar instead of each timeframe being generated separately. Measures become DAX measures: a type: sum or type: count_distinct maps directly, a filtered measure becomes a CALCULATE with an explicit filter, and a type: number measure that references other measures becomes a DAX measure that references measures.

Explores become relationships. A Looker explore joins views with relationship: many_to_one and sql_on clauses at query time; in Power BI the same joins are declared once as one-to-many relationships in a star schema. This is where symmetric aggregates matter. Looker quietly prevents a one-to-many join from double-counting a sum; Power BI prevents it through model shape, so an explore that joins two fact tables directly usually has to be redesigned around shared dimension tables rather than translated line by line.

Derived tables have three common destinations. A SQL derived table that does real transformation is best moved into the warehouse as a view or a scheduled table, where it can be tested and reused. A persistent derived table rebuilt on a datagroup trigger becomes a table maintained by your existing pipeline or a dataflow. Light reshaping that only exists to serve one report can live in Power Query. Access filters and sql_always_where conditions driven by user attributes become row-level security roles using USERPRINCIPALNAME() against a security table mapped to Microsoft Entra ID users and groups.

Version control does not have to be lost. LookML lives in Git, and teams used to pull requests on their metric definitions should keep that habit: a Power BI Project (PBIP) stores the model as TMDL text files that can be diffed, reviewed and committed like any other code.

Looker Studio (the free one) to Power BI

Looker Studio has no central model to translate. Each report owns its data sources, each chart can carry its own blend, and the same revenue figure is often defined three slightly different ways across three reports. The migration therefore starts by collecting every data source and calculated field into one list, agreeing which definition is correct, and building a single Power BI semantic model that every report then shares.

Blends become relationships. A Looker Studio blend joins up to five data sources on chosen keys, scoped to the charts that use it; in Power BI the join becomes a relationship in the model, or a merge in Power Query when the result really is a new table. Calculated fields split two ways: row-level formulas such as CASE statements and REGEXP_EXTRACT become columns in Power Query or the source query, while aggregate formulas become DAX measures. Chart-level calculated fields that nobody documented are found by opening every chart, which is why the inventory takes longer than expected.

Connectors are the other half of the work. BigQuery and Google Sheets have native Power BI connectors, although a sheet that is really acting as a database is usually better moved into one. Marketing sources are where most Looker Studio estates differ: Google Analytics 4 data is generally more dependable through its BigQuery export than through an API connector, and sources with no native Power BI connector, such as Google Ads, typically land in BigQuery through the BigQuery Data Transfer Service or a third-party connector first. Extracted data sources become import-mode tables with a scheduled refresh.

Number-by-number reconciliation

Nothing is signed off on appearance. Each rebuilt report is compared against its Looker or Looker Studio original with the same filters and the same date range, at the total and at the grain the business actually slices on — by month, by region, by campaign. Visual differences are acceptable and often deliberate; numerical differences are defects until someone can explain them.

The usual sources of a mismatch are predictable, which is why they are checked deliberately. Fan-out that Looker's symmetric aggregates were silently correcting, a time zone setting applied in Looker but not in the new model, a blend's join type that dropped rows nobody noticed were missing, and a count_distinct that behaves differently once relationships replace explicit joins. Finding one of these in testing is a ten-minute conversation; finding it after cutover is a credibility problem.

Both platforms then run in parallel for at least one full reporting cycle, month-end close included, with the old platform remaining authoritative until a named business owner signs off each report. The renewal or cancellation date is set at the start and the parallel run is planned backwards from it, because a parallel run with no end date is just paying for two BI tools.

• Same filters, same date range, same numbers — at total and at working grain
• Fan-out, time zone, join type and distinct-count checks on every model
• Row-level security verified role by role with View as role, in Desktop and in the service
• Named business owner sign-off per report, recorded
• A bounded parallel run with the decommission date fixed up front

What a migration costs

There is no honest flat price for a Looker migration, because the effort is set by what survives the inventory. A handful of Looker Studio reports on two or three clean sources is a small project. A LookML project with dozens of explores, chains of persistent derived tables and user-attribute security is a substantial one, and pretending otherwise produces an estimate that is wrong by the second week. The inventory is the first deliverable precisely so the estimate is built on your estate rather than on a guess.

Most migrations are scoped as fixed projects once the inventory is done. Teams that have already planned the move and need senior hands for the model, the DAX translation or the security work can use Power BI Flex Support, which starts at $2,500 for 20 hours at $100–$125 per hour, in prepaid blocks whose hours do not expire.

Budget for licensing on the Power BI side as well. Looker Studio viewers only need a Google account, while Power BI viewers need a Pro or Premium Per User licence unless the content sits on a large enough capacity. For a team moving off free Looker Studio, that line belongs in the business case from the start.

Why small teams migrate

Off Looker, the reason is usually cost relative to size. Looker is sold by quote as a platform edition plus per-user licences, a model built for enterprises with a dedicated data team maintaining LookML. A small company that inherited a Looker instance — often from a former analyst or an acquisition — can end up paying enterprise rates for a few dozen dashboards that nobody on staff can modify. Power BI's per-user licensing and its fit with Microsoft 365, Excel and Teams make it the more natural home when the business already runs on Microsoft.

Off Looker Studio, the reason is usually limits rather than cost. Reports slow down as Google Sheets sources grow, blends cap out at five data sources, extracted data sources have size ceilings, every report redefines its own metrics, and there is no real semantic model or row-level security to hand to a finance team. Looker Studio Pro adds team workspaces and administration but not a modelling layer, so teams that have outgrown the free tool generally need a different kind of tool rather than a paid version of the same one.

Not every team should move. If a Looker deployment is well maintained, heavily used and fairly priced for what it delivers, the disruption may not be worth it this year. Bring the renewal date and a rough count of dashboards to a first call and you will get a plain answer either way. Engagements are led by Edward Pinela, MBA, a principal consultant with more than twenty years in business intelligence — the person who scopes the migration is the person who runs it.

Further reading: Microsoft Learn — Power BI migration overview.