# Migrating Tableau, Metabase and Data Studio Reports to Looker using AI, Wire & Rittman Analytics URL: https://rittmananalytics.com/blog/2026/10/11/migrating-tableau-metabase-and-data-studio-reports-to-looker-using-ai-wire-rittman-analytics Description: One of the most-common requests we get from clients is to help them move from legacy BI tools such as Metabase, Tableau or Power BI to a modern data analytics… Author: Mark Rittman Published: 2026-10-12T00:13:42+01:00 Modified: 2026-10-12T00:13:42+01:00 --- ![Migrating Tableau, Metabase and Data Studio Reports to Looker using AI, Wire & Rittman Analytics](https://rittmananalytics.com/api/public/og-image?src=https%3A%2F%2Fdtdtemp8.wpcomstaging.com%2Fwp-content%2Fuploads%2F2026%2F10%2F1b-bl4zdtAyHn0ArbdDr7A.png) One of the most-common requests we get from clients is to help them move from legacy BI tools such as Metabase, Tableau or Power BI to a modern data analytics platform and semantic layer using Looker. ![A series of analytical dashboards showcasing web analytics, report creation, and customer cohort performance using data visualisations and charts.](https://rittmananalytics.com/api/public/og-image?src=https%3A%2F%2Fi0.wp.com%2Fdtdtemp8.wpcomstaging.com%2Fwp-content%2Fuploads%2F2026%2F10%2F1b-bl4zdtAyHn0ArbdDr7A.png%3Fresize%3D1400%252C481%26ssl%3D1) Another, related type of request is to help a team move from a standalone reporting tool such as Google Data Studio (formerly, Looker Studio) to full Looker and its semantic layer, with the common goal being to provide better self-service analytics to users and do so with a single, integrated view of metric definitions and slice-and-dice dimensions. In many cases, moving to a new BI platform is part of a wider data transformation project where the tools for data extraction and transformation, along with the underlying data warehouse are all being upgraded and the BI tooling layer then becomes a re-implementation, often many months after the start of the project and with everything having to be re-built from scratch. But if the underlying data warehouse is fine right now and urgency is to get users off of those legacy BI tools and onto Looker before the next renewal date, refactoring those ‘like-for-like’ Looker reports later-on, our BI tool migration service enabled by AI automation can get this migration out-of-the way quickly and efficiently without tying-up all of your data team resources for months on-end. ## Using AI to help automate Legacy BI Tool Migration In [our blog last week](https://blog.rittmananalytics.com/whats-new-in-wire-4-x-multi-agent-development-dbt-charts-agents-schema-more-7d07acb467a7) I talked about the new release of [Wire](https://rittmananalytics.com/services/wire-framework), our AI delivery toolkit used by consultants at Rittman Analytics to safely accelerate the delivery of our client consulting projects using AI. By combining agentic coding tools such as Claude Code with our project delivery blueprints and “human-in-the-loop” judgement calls, our approach enables clients to reap the benefits of AI in their BI project delivery whilst retaining the benefits of our experienced, best-practices approaches. We also make Wire available as a [Claude Code plugin](https://github.com/rittmananalytics/wire-plugin) for non-competing use, and publish full documentation at [docs.rittmananalytics.com](https://docs.rittmananalytics.com/en/latest/docs/release-types/bi-migration) One of Wire’s capabilities is to assist us with BI tool migrations, and the 4.2.5 release of Wire introduces three new “migration pairs” for migrating two legacy and one standalone BI tool to Looker: 1. **Tableau to Looker** (4.2.4): Tableau Cloud, Server or Desktop workbooks become LookML views, explores and LookML dashboards. 2. **Metabase to Looker** (4.2.5): Metabase questions, models, metrics and dashboards become LookML views, explores, measures and LookML dashboards. 3. **Looker Studio to Looker** (4.2.5): Looker Studio (formerly Data Studio) reports become LookML, with each metric’s definition agreed first in a metric catalogue. Note that all three pairs are experimental in this release. Check out the [Release Notes](https://docs.rittmananalytics.com/en/latest/docs/reference/release-notes) for more details on this and other new features in Wire 4.x. ## How BI Tool Migration to Looker Works Though Tableau, Metabase, Data Studio (and in the near-future, Power BI and Oracle BI) all have their own way of defining and storing report definitions, most (though not all) provide APIs that expose those definitions and are well-suited to agentic processes that can introspect those definitions and then store them in a common format ready for conversion into a semantic layer and the equivalent reports in Looker. The diagram below shows the overall technical architecture our process follows, from the source tools on the left to Looker on the right and with a “parity loop” underneath. ![A flowchart illustrating a data migration process from various sources like Tableau, Metabase, and Looker Studio to Looker. The diagram includes steps for snapshot and audit, wire processing, conversion scripts, and deployment to Looker, with highlighted tools and components involved.](https://rittmananalytics.com/api/public/og-image?src=https%3A%2F%2Fi0.wp.com%2Fdtdtemp8.wpcomstaging.com%2Fwp-content%2Fuploads%2F2026%2F10%2F0jDnk3JrVxSQ0x29g.png%3Fresize%3D1400%252C746%26ssl%3D1) A tool-specific means of extraction is used for each of the legacy BI tool sources, via public APIs where available: - for **Tableau Cloud or Server**, we use their REST API with a personal access token. - for **Metabase**, again we use their API with an API key. - for **Google Data Studio**, which has no API for report definitions, we use Claude Code’s Chrome browser automation to introspect each report and its data source definitions, along with reading database query logs that Data Studio tags with the unique ID of each report. ### Using Agents to Automate the Migration Process The first job in any migration is getting a complete, pinned copy of what the source tool holds. Whatever the source, Wire’s audit runs the same six steps as shown in the diagram below. ![Diagram illustrating the steps of a data audit process, including stages such as Connect, Snapshot, Classify, Write report, Validate, and Review, along with their associated data outputs and file mentions.](https://rittmananalytics.com/api/public/og-image?src=https%3A%2F%2Fi0.wp.com%2Fdtdtemp8.wpcomstaging.com%2Fwp-content%2Fuploads%2F2026%2F10%2F1KfhsY1iJ6p5ocpT3Vx345w.png%3Fresize%3D1400%252C604%26ssl%3D1) The audit process then catalogues, classifies and flags for review everything the snapshot found, and passes it into Wire as a tool-neutral metric, report or dashboard definition. Once the audit is approved and the plan has your rulings, the converter part of the process turns each source item into its LookML equivalent. ![Diagram illustrating the flow from source items to LookML artifacts, highlighting processes such as joins, calculations, dashboards, and filters, concluding with output validation steps.](https://rittmananalytics.com/api/public/og-image?src=https%3A%2F%2Fi0.wp.com%2Fdtdtemp8.wpcomstaging.com%2Fwp-content%2Fuploads%2F2026%2F10%2F0aJ1engeMZzOinVhS.png%3Fresize%3D1400%252C700%26ssl%3D1) - **Tables or data sources** become `views/*.view.lkml` files, typed, with primary keys. - **Joins and relationships** become explore joins in `models/.model.lkml`. - **Calculations, metrics and aggregations** become measures and dimensions. Tableau LOD expressions and table calculations go to people. - **Native SQL, models and custom SQL** become derived-table views. Simple SQL is also lifted onto the table’s view, as a proposal. - **Dashboards, pages and tabs** become `dashboards/*.dashboard.lookml` files on the 24-column grid. - **Filters and controls** become dashboard filters with `listen`. ### Complementing Automation with Testing and Human Judgement **Human in the loop.** Every step also writes to a file that logs everything the converter cannot translate safely, rather than guessing and potentially changing a key number in a report. Each item goes through a plan ruling and then review so that Wire’s agents do as much mechanical translation as is safely possible, and it then works through the judgment calls with you. Finally, all output we send to Looker has to pass three layers of testing: 1. **Linting**, which for example checks for any source-tool syntax left in the LookML or a field defined twice; 2. **Looker’s validator**, checking the validity of Wire’s generated LookML; 3. **Parity**, which checks that every Looker dashboard tile produces the same results as its source before cutover. ## An Example BI Tool Migration using Wire So what does this look like in-practice? In the following example we’re working with a fictional retailer, Halcyon Outdoor, who has a set of Tableau, Metabase and Google Data Studio reports they want to bring-over to Looker as-is, allowing them to retire their legacy BI tools and refactor the resulting semantic layer at a later date. In this example: - Finance uses **Tableau Cloud**, and wants their revenue report moved over to Looker - the product team uses **Metabase**, and wants their web analytics dashboards and questions moved to Looker - and marketing reads **Data Studio** reports and wants those in Looker too ### Getting Started, and Prerequisites If you already have the Wire plugin installed, run `/reload-plugins` in Claude Code to pick up 4.2.5. If not, install it in three steps: /plugin marketplace add rittmananalytics/wire-plugin /plugin install wire@rittman-analytics /reload-plugins Each source needs one credential, kept in a file under `~/.wire/` outside your repository: - **Tableau**: a personal access token (your site administrator may need to allow token creation). - **Metabase**: an API key in a group that can see the content, with the tables synced. - **Looker Studio**: Chrome on your machine, and a record of who approved read-only access to the reports. ### Interacting with Wire in the 4.x Release Wire 4.x introduced a new “release director” way of working with Wire within Claude Code, where the user sets the session goal and makes key decisions along the way, rather than having to learn and directly type-in the commands that Wire uses to automate project delivery. We start by logging-into Claude Code and setting our overall project goals. ▐▛███▛█ Claude Code v2.1.289 ▝▜██████▀ Opus 5.5 (1M context) · Claude Team ▝▝ ▝▝ ~/github/halcyon-bi-to-looker❯ Halcyon is moving all its reporting to Looker. Three sources: Tableau Cloud (site halcyon, the Finance project), Metabase at halcyon.metabaseapp.com (the Product collection), and the three Looker Studio marketing reports in this list. Same BigQuery warehouse throughout; the LookML project is halcyon\_looker.⏺ Skill(wire:new) ⎿ Successfully loaded skill⏺ One release has one source tool, so I'll open three releases under this engagement, all writing to halcyon\_looker. Each pair is experimental. .wire/releases/02-tableau-to-looker/ bi\_pair: tableau\_to\_looker .wire/releases/03-metabase-to-looker/ bi\_pair: metabase\_to\_looker .wire/releases/04-looker-studio-to-looker/ bi\_pair: looker\_studio\_to\_looker halcyon\_looker already has 212 views, so each release writes to its own folder under its own model: tableau\_migration/, metabase\_migration/, looker\_studio\_migration/. Your existing models are not touched. One thing I need before the Looker Studio capture: who approved automated read-only access to the three reports, and when?❯ The CMO approved it this morning.⏺ Recorded in 04-looker-studio-to-looker/status.md. Ran: new (x3) This first step set-up the project scaffolding within the git repo, and once that setup is confirmed I then instruct Wire to start the audit process for all three BI tools. ❯ Run the audits.⏺ Tableau: signed in with the token, snapshot of the Finance project. 6 workbooks, 41 sheets, 9 dashboards, 11 data sources (4 published) data source fingerprints: 7 embedded copies collapse into 3 groups redesign: 2 LOD expressions, 1 table calculation, 1 extract-only data source file sources: 1 workbook reads an Excel file, not the warehouse Metabase: snapshot of the Product collection through the API. 23 questions (17 query builder, 6 native SQL), 2 models, 3 metrics, 4 dashboards (one with 3 tabs) every query-builder table synced; primary keys from metadata on 9 of 11 tables not converted: 2 questions binned by "number of bins", 1 multi-stage question Looker Studio: opening Chrome. Sign in when the window asks.❯ Done.⏺ Captured 3 reports (14 pages). The data sources are of three kinds: BigQuery tables 8 become LookML views BigQuery custom SQL 2 become views on their SQL Looker Studio's Looker connector 3 the charts already read Looker: they point at the existing explores Search Console, GA4 2 Looker cannot query them: listed for the plan Metric catalogue: 211 calculated fields in 64 groups; 9 metrics are defined two or more ways (conversion rate three ways). Ran: tableau-audit-generate, -validate; metabase-source-audit-generate, -validate; looker-studio-audit-generate, -validate; metric-catalogue-generate, -validate Once this initial audit has completed as much as it can on its own, it then stops as it needs the user to make some decisions where its next steps aren’t clear. ❯ What do you need from me?⏺ Eleven rulings across the three releases. The ones that change numbers first: R-1 Metabase "Weekly signups by channel" and 5 other native SQL questions: views on their SQL are exact but not reusable. I lifted the 2 simple ones onto the sessions view as a proposal. Remodel onto shared views, or keep? R-2 Tableau "Customer lifetime value" is a FIXED LOD expression. Derived table, or drop? R-3 Looker Studio "Conversion rate": three definitions (orders/sessions, orders/users, purchases/sessions). Which one is the company's? R-4 Looker Studio blend "Orders and sessions" (full outer join, no keys recorded): model the join on date and channel, or drop the 2 charts on it? R-5 Tableau "Regional targets" reads an Excel file: load it to the warehouse, or drop? ...❯ R-1 keep the 4 complex ones as views for now; take the lifted fields. R-2 derived table. R-3 orders over sessions. R-4 join on date and channel. R-5 load it as a dbt seed. Accept your proposals for the rest.⏺ Recorded R-1 to R-11 in the three plans and in the metric catalogue review. The plans are ready for your approval.❯ Approved. With the plans approved, the user tells Wire to build it. The three converters write LookML to a branch of the client’s LookML project repository, linting the output however before anything reaches Looker. \> Please build it⏺ Branch wire/bi-to-looker in halcyon\_looker. Converting: Tableau 9 views, 6 explores, 9 dashboards; 3 primary keys proposed from \*\_pk columns; the LOD as a derived table under hand/ (R-2) Metabase 11 views, 8 explores, 6 dashboards (one per tab); joins from Metabase's foreign keys; 3 metrics as measures with their filters; 4 views on native SQL (R-1) Looker Studio 8 views from BigQuery tables, 2 on custom SQL; "Conversion rate" as SAFE\_DIVIDE of orders over sessions (R-3); 14 dashboards. The 4 pages whose charts read the existing analytics model are in dashboards/analytics/: add one include line to that model to show them. Lint: 1 problem. metabase\_migration/views/sessions.view.lkml: field session\_start\_ts\_month is defined twice A field lifted from SQL took a name the session\_start\_ts date group already generates. Renamed it session\_start\_ts\_month\_from\_sql, re-ran: 0 problems. Pushed. Validate it in development mode, merge, and configure the three new models with halcyon\_bq. Ran: looker-target-setup-generate (x3), lookml-model-generate (x3), lookml-model-lint (x3), looker-content-generate (x3) The user validates the branch in Looker, merges and deploys it. Wire then compares every tile with its source. ❯ Deployed, models configured. Please test for equivalency. ⏺ Each source's rows for each tile, against the Looker element's rows, through the same comparator: Source Tiles PASS accepted difference FAIL Tableau (Query View Data) 41 40 0 1 Metabase (question data) 31 31 0 0 Looker Studio (recordings) 58 55 3 0 Tableau FAIL: "Margin by region" differs on every row. The Tableau calculation was a sum of row-level ratios (Tableau sums a row-level field by default); the converter emitted it that way and listed it. Sum of ratios or ratio of sums? Looker Studio accepted differences, for your approval: 2 tiles the chart's range ends today; Looker's nearest filter also counts rows dated later this month (forward-dated invoices). Same values for every closed month. 1 tile a breakdown chart: Looker Studio drew its top 15 series, Looker draws all 47. The 15 it drew match Looker's rows exactly. ❯ Ratio of sums: that was always the intent. Accept the three differences. Changed "Margin by region" to a ratio of sums under hand/; re-ran it against Tableau with the old number shown beside it, which the finance team should see before cutover. Recorded the three accepted differences with you as approver. All 130 tiles satisfy the cutover gate. Ran: bi-equivalency-validate (x3) The “Margin by region” result is the kind of thing a migration should surface as the Tableau number was wrong, the Looker number is right, but the finance team needs to hear that before cutover rather than after. The full session, including cutover planning and drift checks during the parallel run, is in the [terminal session walkthrough](https://docs.rittmananalytics.com/en/latest/docs/tutorials/bi-to-looker-session) in the Wire docs. ## So What Does Our Automated Process Cover? This feature is new and experimental and automation doesn’t cover all scenarios, which of course is where an experienced partner such as ourselves becomes invaluable. ### Tableau to Looker Migration Tableau keeps the model and the content together in one XML document per workbook, plus any published data sources. There is no git repository to read, so Wire takes a snapshot through the REST API (or reads a folder of \`.twb\` and \`.twbx\` files for a Desktop-only estate) and pins each object by its last-updated time and a hash of the file. What the Tableau converter handles: - **Columns and row-level calculations** become dimensions, date dimension groups and measures. `IF ... ELSEIF`, `ZN()`, `DATETRUNC` and `DATEDIFF` translate to BigQuery or Snowflake SQL. - **Aggregate calculations** such as `SUM([profit]) / SUM([sales])` become `` `type: number` `` measures. - **Groups and bins** become `CASE`and `FLOOR` dimensions, including bins sized by a parameter. - **Duplicate data sources** are matched by fingerprint (connection, tables, joins and columns, not names), so seven embedded copies of the same orders data become one shared explore if you agree. - **Primary keys**. Tableau’s relationships record no keys, so Wire proposes each view’s `` `*_pk` `` column as its primary key. Looker then uses symmetric aggregates, and totals stay correct across joins. - **Dashboards** land on Looker’s 24-column grid, with quick filters as dashboard filters. A sheet that is on no dashboard becomes a one-tile dashboard that keeps its sort and filters. - **LOD expressions, table calculations, blends and extracts** are listed for a ruling, never guessed at. As an example, we tested this migration pair on our own Tableau Cloud trial site, with a published BigQuery data source over five tables and a “Revenue by Company” sheet (blank names excluded, totals of £50,000 or more, largest first). ![A data visualisation with two sections: the top section shows a horizontal bar chart representing the revenue by company, featuring various company names along the vertical axis and total GBP amounts on the horizontal axis, and the bottom section displays a table listing the same companies with their corresponding total GBP amounts, using colour coding to highlight different revenue brackets.](https://rittmananalytics.com/api/public/og-image?src=https%3A%2F%2Fi0.wp.com%2Fdtdtemp8.wpcomstaging.com%2Fwp-content%2Fuploads%2F2026%2F10%2F1UWYQQGjws7aB9fr67l3sow.png%3Fresize%3D1400%252C946%26ssl%3D1) Wire converted it into a `tableau_migration` folder and model alongside the existing views in our LookML project, deployed it, and queried the tile through the Looker API. Looker’s 34 rows matched Tableau’s, every company and value, in the same order. Looker’s SQL used the proposed `invoice_pk` key to aggregate correctly over the join. Walkthrough: [Tutorial: Tableau to Looker](https://docs.rittmananalytics.com/en/latest/docs/tutorials/tableau-to-looker). ## Metabase to Looker Metabase keeps typed metadata for every table it has synced including each field’s type and its primary and foreign keys. Questions built in the query builder refer to fields by id, so the converter knows which column each question reads, which LookML view it belongs to and how the tables join. What the Metabase converter handles: - **Tables** become views, typed and keyed from Metabase’s metadata. - **Query-builder questions** become shared explores, with joins taken from Metabase’s foreign keys rather than inferred. - **Metrics** become measures that keep their filters (“Revenue, excluding cancelled orders”). - **Native SQL questions and models** become views on their SQL, with template tags as parameters. Simple single-table SQL is also lifted onto the table’s view, as a proposal for you to accept or reject. - **Relative dates** translate both ways: “previous 12 months” and “the last 12 months including this one” are different filters in Looker, and Wire writes the right one. - **Dashboards** map one-to-one onto Looker’s 24-column layout. Each tab becomes its own LookML dashboard, and dashboard filters keep their field mappings. We tested this converter on a Metabase Cloud instance with a BigQuery database: a “Web Analytics” dashboard with two native SQL questions (sessions by month, bounced session rate by channel), and a second dashboard of two questions built in the query builder, one with a Channel filter. All four tiles matched in Looker, row for row and in the same order. ![Top section displaying web analytics metrics with graphs for bounced session rate by channel and sessions by month.](https://rittmananalytics.com/api/public/og-image?src=https%3A%2F%2Fi0.wp.com%2Fdtdtemp8.wpcomstaging.com%2Fwp-content%2Fuploads%2F2026%2F10%2F1AobXspE1gNYCvdMN57a4Bg.png%3Fresize%3D1400%252C1262%26ssl%3D1) Looker’s validator also caught a fault our test fixtures had missed: a field lifted from SQL took a name that a date dimension group already generates. The converter now avoids every generated name, and Wire’s lint step fails on any field defined twice, so the problem is caught before the LookML reaches Looker. Walkthrough: [Tutorial: Metabase to Looker](https://docs.rittmananalytics.com/en/latest/docs/tutorials/metabase-to-looker). ### Google Data Studio to Looker Looker Studio is the hardest of the three, because it has no shared model at all. Each report has its own data sources and its own calculated fields, so “conversion rate” is often defined three different ways across three reports. Converting them one for one would carry those differences into Looker. So this pair starts with a capture and a metric catalogue. Wire opens each report in the editor and records its definitions, and the values each chart showed. It then groups every calculated field by metric and classes each group as a copy, an alias or a conflict. You (or better, the client’s metric owners) rule on one definition per metric, and the converter writes LookML from those rulings. In this conversion: - **A BigQuery table** becomes a LookML view, with measures for the charts’ aggregations and the agreed calculated fields. - **A BigQuery custom SQL data source** becomes a view on its SQL. - **Looker Studio’s Looker connector** needs no new LookML: the charts already read Looker, so they point at the existing explore. - **Search Console, GA4, Sheets and other connectors** are listed for the plan: load the data to the warehouse first, or drop. Calculated fields become BigQuery SQL, with Looker Studio’s division written as `SAFE_DIVIDE`, because Looker Studio returns null when dividing by zero and BigQuery raises an error. Each report page becomes a LookML dashboard, with the date range and filter controls as dashboard filters. Parity compares each chart’s recorded values with the Looker element’s rows, which works for every connector. We tested this converter it on two of our own reports, one of which reads our existing Looker model through Looker Studio’s Looker connector and the other that read two BigQuery tables and a custom SQL query. For the first report, six of its seven charts matched exactly. On the seventh, the chart’s date range ends today and Looker’s nearest filter also counts invoices dated later this month, so every closed month matched and only the current month differed. A breakdown chart showed another known difference in that Looker Studio drew only its top 15 companies, while Looker draws every row and those 15 matched exactly. For the second report, all four converted charts matched. The fifth chart, built on a blend, was listed for a ruling rather than converted. Walkthrough: [Tutorial: Looker Studio to Looker](https://docs.rittmananalytics.com/en/latest/docs/tutorials/looker-studio-to-looker). ## Interested? Find Out More Rittman Analytics is a boutique data analytics consultancy that helps ambitious, digital-native businesses scale up their approach to data, migrate to Looker from legacy BI tools and accelerate their analytics projects using [Wire](https://rittmananalytics.com/services/wire-framework) and our other AI technologies. We’re authorised delivery partners for Google Cloud along with Oracle, Segment, Cube, Dagster, Preset, dbt Labs and Fivetran, and are experts at helping you design an analytics solution that’s right for your organisation’s needs, use cases and budget, and working with you and your data team to implement it. If you’re looking for help with your migration to Looker, or would just like to talk shop and share ideas on what’s going on in your organisation and the wider data analytics world, [contact us now](https://calendly.com/markrittman/initial-discovery-call-with-mark-rittman) to organise a free, no-obligation call. We’d love to hear from you!