Tableau or Power BI to Looker: the complete migration playbook

BI migrations don't fail in the demo. They fail in the details, three months in: a revenue metric that no longer matches last quarter's board deck, a regional team locked out mid-close, forty dashboards that arrived "migrated" but answer questions nobody asked in the new tool's idiom. The technology is rarely the hard part. The hard part is moving hundreds of users and thousands of business definitions across platforms while everyone keeps working.

We've run this kind of migration at enterprise scale — most recently consolidating two enterprise Looker environments into a single cloud-core platform, with users experiencing little to no disruption and a fallback window held open for roughly 15–20 days after cutover. This playbook is the method behind that outcome, adapted for the two moves we're asked about most: Tableau → Looker and Power BI → Looker.

Two principles before the phases:

1. A migration is a rebuild, not a copy. Tableau workbooks and Power BI reports encode their logic in tool-specific ways (calculated fields, DAX). Looker encodes logic in a governed semantic layer (LookML). Translating idiom-for-idiom produces a worse version of what you had. Translating intent — what the business definition actually is — produces something better.
2. The migration nobody notices is the one that worked. Every phase below exists to make cutover boring: parallel systems, reconciled numbers, a validation window, a fallback plan. Drama in a migration is always the result of a skipped phase.

Why teams make this move (and when they shouldn't)

The usual drivers: consolidating on Google Cloud where the data already lives in BigQuery; ending metric drift by moving definitions out of individual workbooks into one governed model; enabling embedded analytics; or escaping extract-refresh mechanics in favor of live, governed queries.

When not to migrate: if your pain is dashboard speed or warehouse cost, fix that first — performance optimization is a 6–8 week project; a migration is a quarter or more. And if your reporting needs are light, Looker may be more platform than you need (we tell people this in assessments more often than you'd think). A migration should buy you governance and scale you can name, not a new logo on the same problems.

Phase 0 — Discovery and inventory (weeks 1–2)

Everything defensible about a migration quote, timeline, and risk register comes from the inventory. Catalog, exhaustively:

• Content: every workbook/report and dashboard, with usage data. Tableau's repository and Power BI's activity logs tell you what's actually opened. Expect a long tail of dead content — this is where the scope shrinks.
• Business logic: calculated fields (Tableau) and DAX measures (Power BI), deduplicated. Ten workbooks often carry ten slightly different definitions of "active customer." List them all; reconciling them is a business decision you want made before modeling, not during.
• Users, roles, and permissions: who sees what, and why. Row-level security rules especially — they translate structurally, not mechanically.
• Data sources and dependencies: extracts, live connections, gateways, refresh schedules, and everything downstream: scheduled emails, embedded views, API consumers, alerts. The integration nobody documented is the one discovered broken after cutover.

Output: a migration roadmap with content tiers (migrate / consolidate / retire), named risks, and a realistic phase plan. In our enterprise consolidation work, this cataloguing phase — every dashboard, account, role, schedule, model, and dependency — is what made the later "no disruption" outcome possible.

The scope decision that pays for itself: don't migrate everything. Migration is the one moment you can retire dead reports at zero political cost ("it didn't survive the migration" is easier than deprecating it in peacetime). Most clients land with fewer, better dashboards — and a smaller bill to match.

Phase 1 — Foundation (weeks 2–4)

Before any content moves, stand up the platform correctly. Conventions retrofitted later cost ten times more.

• Instance and connections: Looker instance configured, BigQuery connection tuned (including query limits and max_bytes_billed guardrails from day one).
• Core LookML model: the base views and Explores that everything else will build on, with naming conventions, folder structure, and a Git flow (branches, reviews, deploy process) established now.
• Security model: groups, roles, and access grants designed once, centrally — this is where Tableau site/project permissions or Power BI workspace roles get rationalized instead of copied. For row-level security, Looker's access_filter with user attributes replaces Tableau user filters and Power BI RLS roles.
• Warehouse readiness: if tables aren't partitioned and clustered for BI query patterns, fix it now. A migration inherits the warehouse it lands on — this is the cheapest moment to apply the whole BigQuery cost playbook, because you're rebuilding anyway.

Phase 2 — Logic translation (the heart of the project)

This is where Tableau and Power BI migrations differ, and where "rebuild, not copy" matters most.

From Tableau:

From Power BI:

In both cases the pattern is the same: logic that lived scattered across files moves into one governed model. This is the actual payoff of the migration — the moment "monthly recurring revenue" stops having four definitions.

Time-intelligence and formatting caveats: DAX time intelligence (YTD, same-period-last-year) and Tableau table calcs need deliberate LookML patterns (period-over-period measures, dimension_group timeframes), and pixel-perfect report layouts don't port — Looker dashboards have their own layout idiom. Set stakeholder expectations in Phase 0: same numbers, better governance, different (usually cleaner) look.

Phase 3 — Content rebuild and validation (the long middle)

Rebuild dashboards in tiers — business-critical first, by domain, with each domain's stakeholders reviewing as you go rather than in one terrifying final review.

Validation is a formal phase, not a spot check. For every migrated dashboard, reconcile the numbers against the source system: same filters, same date ranges, side by side. Differences fall into three buckets — translation bugs (fix them), source-tool bugs the business never noticed (document the correction and get sign-off), and definitional drift between old duplicated fields (escalate to the owner named in Phase 0). Stakeholders get reconciliation reports, not reassurances. In our consolidation work, a structured pipeline compared pre- and post-migration dashboard outputs, and end-user validation confirmed the migrated dashboards showed the same data — that evidence trail is what preserves trust in analytics through the switch.

Meanwhile, map every integration discovered in Phase 0 to its Looker equivalent: scheduled deliveries → Looker schedules; alert rules → Looker alerts; embedded views → Embed SDK/SSO embedding; API consumers → Looker API. Nothing gets discovered broken after cutover because everything was on the inventory.

Phase 4 — Parallel run, cutover, and fallback (the part everyone skips, and shouldn't)

The cutover pattern from our enterprise consolidation, generalized:

1. Parallel availability. The new Looker environment goes live alongside the old platform. Users are invited in; nothing is taken away.
2. Validation window (~1 week). Users work in the new system while the old one stays fully available. Real usage surfaces the issues no test plan catches — a role edge case, a filter default, a schedule landing at the wrong hour.
3. Cutover in a low-usage window. Access to the legacy platform is disabled and users are redirected — but the old system stays technically alive as a fallback. In our consolidation, that fallback window was roughly 15–20 days: long enough for a monthly cycle of real questions, short enough to keep pressure on completion.
4. Retire. After monitoring and validation, the legacy platform is decommissioned — and its license line item with it.

The fallback is not pessimism; it's what makes the cutover decision easy. Teams with no rollback path delay cutover forever, because the decision feels irreversible. Teams with a 15–20 day safety net cut over on schedule.

Hypercare and enablement close the project: role-based training (business users, analysts, LookML developers — each their own track), documentation and runbooks that live with your team, and a defined support window after go-live, when the real questions surface. The goal of a good migration partner is to hand over a platform your team can extend, not a dependency.

Timeline and cost, honestly

• Small migration (~50 dashboards, straightforward model): typically 4–6 weeks.
• Enterprise migration (hundreds of dashboards, complex logic, embedded or RLS requirements): 3–6 months, phased by domain.

Cost drivers, in order: business-logic complexity (the calculated-field/DAX layer, not the dashboard count), integration surface, and validation depth required by your compliance posture. Anyone who quotes a migration before an inventory is guessing with your quarter — which is why our own pricing runs: free 30-minute assessment (high-level scope, risks, timeline range) → $1,500 scoped migration audit (full inventory and detailed roadmap) → fixed-scope SOW for the migration itself, with the parallel-run and fallback plan written into it. Full details on the Looker migration services page, and more context on our broader Looker consulting and Data & Analytics practice.

The playbook, in one checklist

• ☐ Inventory everything: content + usage, logic, users/permissions, sources, downstream dependencies
• ☐ Tier content: migrate / consolidate / retire — and get the retire list signed off
• ☐ Reconcile duplicate business definitions before modeling
• ☐ Stand up foundation: instance, connections, core model, Git flow, security design, warehouse tuning
• ☐ Translate logic by intent (calculated fields / DAX → governed LookML), not idiom
• ☐ Rebuild dashboards in tiers, stakeholders reviewing per domain
• ☐ Reconcile every number; deliver reconciliation reports
• ☐ Map every integration to its Looker equivalent
• ☐ Parallel run with a ~1-week user validation window
• ☐ Cut over in a low-usage window; keep legacy alive as fallback ~15–20 days
• ☐ Train by role, hand over documentation and runbooks, run hypercare
• ☐ Retire the legacy platform — and actually cancel the licenses

Before you commit to anything

The right first step isn't a contract — it's an inventory-level look at what you'd actually be moving. Our free 30-minute migration assessment gives you a high-level roadmap: scope, risks, and a realistic timeline for your environment. If the honest answer is "don't migrate yet" or "you need Looker Studio, not Looker," you'll hear that in the call.

Frequently asked questions about migrating to Looker