Good and bad reasons to migrate
BI migrations are expensive and disruptive, so the reason matters. Sound reasons: consolidating onto one platform after an acquisition, moving to a governed semantic layer because metric definitions have fragmented across hundreds of reports, licensing economics changing at your user count, or a warehouse move that makes the current tool a poor fit.
Weaker reasons: a preference for a different visual style, or a belief that a new tool will fix data quality. It will not. If the underlying model is inconsistent, a migration relocates the inconsistency and adds a change-management problem on top.
The core difference: where logic lives
This is the fact that shapes the whole project. Power BI encourages logic inside each report — DAX measures, Power Query steps and relationships defined per dataset (or in shared semantic models, if you have been disciplined). Looker pushes logic into LookML: a version-controlled, centrally defined model that every explore and dashboard consumes.
So a migration is not a translation of visuals. It is a consolidation of business logic that has accumulated in hundreds of places into one governed model. That is why the effort estimate almost always lands higher than the initial visual-count-based guess — and why the result is worth having.
Step 1 — Inventory, and be ruthless
Pull usage telemetry before you plan anything. In most estates a minority of reports carry nearly all the views, and a long tail has not been opened in a year. Migrating that tail is pure waste.
- Every report and dashboard, with view counts and distinct users over the last 6–12 months.
- Owner and business process for each survivor — anything without an owner is a retirement candidate.
- Every DAX measure, deduplicated. Near-identical measures are the clearest evidence of fragmented definitions.
- Data sources, refresh schedules and any gateway dependencies.
- Row-level security rules and who they apply to — these are frequently undocumented.
- Embedded reports and anything consumed via API or subscription email, which users notice immediately when it breaks.
Step 2 — Design the LookML model before converting anything
Resist a report-by-report conversion. Build the model first: views over warehouse tables, explores that reflect how the business asks questions, and a single definition per metric agreed with the people who own the number.
This is the moment to settle the arguments — three definitions of "active customer" become one, in code, with the reasoning in the commit message. Every dashboard built afterwards inherits that consistency for free.
Step 3 — Translating DAX
Most measures convert cleanly; a minority need real thought. The awkward cases are predictable:
- Time intelligence (year-to-date, prior year, rolling periods) — Looker handles these differently and generally wants a proper date dimension in the warehouse.
- CALCULATE with complex filter context, which has no direct equivalent and needs restating as a dimension, a filtered measure or a derived table.
- Iterators such as SUMX over large tables — usually better pushed into the warehouse as a transformation.
- Row-level security: Power BI roles become Looker access filters driven by user attributes. Test these first and hardest; a mistake here exposes data.
- Measures referencing other measures several layers deep — flatten and document them rather than transcribing the chain.
Step 4 — Phase the delivery
Pick one business domain — finance, sales, operations — and take it all the way through: model, explores, dashboards, security, users trained, old reports retired. A complete vertical slice proves the approach and gives sceptics something real to look at. Then repeat.
Horizontal phasing (all models, then all dashboards, then all users) delays value until the very end and leaves no opportunity to correct course.
Step 5 — Parallel run and sign-off
Both platforms run against the same data for at least one full reporting cycle, and the numbers are compared line by line. Differences are expected early — the usual causes are null handling, timezone treatment, date-boundary definitions, and filters that were silently applied in the old report.
Every difference is either explained or fixed before sign-off. Reaching identical figures is not the objective; understanding every gap is. Have the business owner sign off in writing, then decommission the old report — not before.
Step 6 — Adoption is the actual risk
The technical work is tractable. The failure mode is users quietly continuing to use the old platform, or exporting everything to spreadsheets. Budget for it: training sessions per team rather than one all-hands, a short internal guide written in your own business language, a visible date when the old platform becomes read-only, and a named person to answer questions in the first month.
A migration that finishes on time and leaves half the business on the old tool has not finished.
Decisions to settle before week one
Migrations drift when these questions are answered gradually, in different meetings, by different people. Settle them at the start and write the answers down:
- Who owns a metric definition when two departments disagree? Name the person, not the process.
- What is the retirement policy for old reports — read-only for a fixed window, or deleted at cutover?
- Does self-service continue, and if so within what guardrails? Unlimited ad-hoc modelling recreates the fragmentation you are migrating away from.
- Which reports are genuinely business-critical, in the sense that being wrong for a day is a serious problem? Those get the deepest validation.
- How long will both platforms run in parallel, and who pays for the overlap?
- What is the definition of done for a migrated report — visually identical, or numerically correct and fit for purpose? These are not the same, and assuming the first is expensive.
What drives the cost
- Number of surviving reports — which is why the inventory cull pays for itself immediately.
- Number of distinct metrics, not visuals. Fifty dashboards over twenty clean metrics is a smaller job than ten dashboards over two hundred ad-hoc measures.
- Warehouse readiness: if the data model needs work first, that work is the larger part of the project.
- Row-level security complexity.
- Licensing overlap during the parallel run — you pay for both platforms for a period, and it should be planned for rather than discovered.
Frequently asked questions
For a mid-sized estate — roughly 50–150 active reports — expect 3–6 months including parallel running and training. Discovery and the semantic model take the first third; report conversion is faster than most teams expect once the model is right.
Partially. Simple aggregations translate mechanically, but anything using filter context, time intelligence or nested measures needs human judgement. Treat automated conversion as a first draft that must be validated, never as output you can ship.
Almost certainly not. Usage data usually shows a large share of reports with effectively no audience. Migrate what is used, retire the rest, and keep the old platform read-only for a defined window in case something was missed.
It becomes Looker access filters driven by user attributes. The logic is portable but the implementation is different, and it should be tested before anything else — an error here is a data exposure, not an inconvenience.
Often, yes — at least partly. Looker pushes queries down to the warehouse, so transformations previously done inside Power Query typically move into warehouse models. Plan that work explicitly rather than discovering it mid-project.
You can, but it reintroduces exactly the fragmentation most migrations are trying to end, and you pay twice. If both must stay, define a clear boundary — for example one platform for governed reporting, the other for exploratory analysis — and enforce it.
How we can help
BI platform moves and legacy re-platforming, delivered incrementally with parallel-run validation.
Data Architecture & EngineeringThe warehouse modelling that a governed semantic layer depends on.