Migrate from Looker to Metabase

Migrate from Looker to Metabase: what the move involves

Metabase replaces the dashboard and self-service layer of Looker, not the LookML modeling layer. Explores, measures and joins do not convert automatically, so the move is a rebuild of the logic in Metabase models and metrics, with shared calculations pushed into the warehouse or dbt where they belong. Teams usually arrive here for one of three reasons: a Looker renewal that is coming up, a need to run BI outside Google Cloud, or a wish to stop maintaining a LookML layer for every question the business asks. Looker (Google Cloud core) instances are hosted by Google in Google Cloud and are not offered for customer-hosted or multicloud environments, so for teams that must keep analytics inside their own network, self-hosting is often the deciding factor.

The work is usually done by the internal analytics engineers who already know the warehouse and the business definitions, supported by an implementation partner for hosting, hardening and the migration plan. The effort depends less on the number of dashboards than on how much business logic lives in LookML. Start by inventorying the LookML repository, the Explores that people use, the persistent derived tables and the access rules, then sort each item into three groups: logic to move into dbt or warehouse views, metrics to rebuild as Metabase metrics, and dashboards to retire. Ask your partner to confirm how they will validate totals against Looker results before users switch, and plan for a parallel run in which both tools answer the same questions.

Plan the platform decisions early, because they shape the rest of the project. Metabase's free Open Source edition covers self-hosting with unlimited users and dashboards, but SSO, row and column level permissions and usage auditing sit in the paid Pro and Enterprise plans, so confirm which of your Looker access controls must carry over before you choose an edition. For the application database, Metabase recommends PostgreSQL for production rather than its embedded H2 database. Confirm the current pricing and plan details directly on the Metabase pricing page before you build a budget, because the feature split between editions decides whether your identity and permission model can be reproduced.

Which Looker capabilities map to Metabase and which need rework

This table compares the main Looker capabilities with their closest Metabase equivalents and labels each one as clean, needs rework or gap. Read the rework and gap rows first, since they set the migration effort, and confirm any feature the supplied sources do not cover against the current Metabase documentation and your own test instance.

Looker capability	Metabase equivalent	Status and notes
LookML views and explores	Models and metrics in the Metabase data model layer	Needs rework. Joins and field definitions must be rebuilt by hand, and LookML logic must be split between Metabase and the warehouse or dbt.
Looks and dashboards	Saved questions and dashboards	Clean for simple charts. Rework for dashboards that depend on LookML filters or parameters.
Git-based LookML version control	No equivalent LookML repository in Metabase	Gap. Keep model definitions in dbt or SQL in Git, and confirm how Metabase object changes are tracked in your environment.
Looker IAM roles and groups	Metabase groups and collection permissions	Clean for group-level access. Needs rework where Looker model-level access is in use.
Row and column level permissions	Row and column level permissions on Pro or Enterprise plans	Needs rework. These controls require Metabase Pro or Enterprise, so budget the plan before porting access rules.
SSO sign-in	Google sign-in and LDAP on Open Source, SAML and OIDC on Pro or Enterprise	Needs rework. Confirm your identity provider setup against the current Metabase people and groups documentation.
Scheduled deliveries	Dashboard subscriptions and alerts	Confirm. Check frequency, recipients and attachment formats against your current Looker schedules before cutover.

Deciding which LookML logic moves into the warehouse or dbt

Decide before the Metabase build which LookML logic moves into the warehouse as views or dbt models, because derived tables, multi-table joins and business metric definitions should not live only inside a BI tool. Once a metric such as net revenue or active customer exists only as a LookML measure, every downstream tool, notebook and export has to re-derive it, and Metabase models and metrics then become a second copy that drifts. Move the logic that other consumers depend on into versioned SQL in the warehouse, and keep Metabase for presentation, exploration and access control. Persistent derived tables are the clearest candidates, since they are already materialized and typically have a refresh schedule that can be reproduced in dbt or a warehouse job.

Start the inventory from the LookML Git repository rather than from the Looker interface. Each LookML project corresponds to one Git repository, and Looker connects to remote providers such as GitHub, GitLab or Bitbucket over HTTPS or SSH, so you can clone the project and read its .model.lkml, .view.lkml and .explore.lkml files directly. Confirm with your Looker administrator which branch is production, because the deployed version can differ from the default branch. For each view, record whether it is a plain table reference, a derived table, a join or a measure with business logic, and who owns it. Measures with filters, case statements or custom currency or date conversions usually need a warehouse equivalent before the Metabase build begins.

Use the inventory to sort every item into one of three destinations: a warehouse view or dbt model for shared logic, a Metabase model for curated, joined datasets that analysts explore, or a Metabase question for one-off logic that no one else reuses. Test each moved definition by comparing its output with the same Explore query in Looker for a fixed date range and a few known segments, and record the result in the migration log. Ask your data team which tool owns the dbt project, how tests run in CI, and whether the warehouse grants let the Metabase service account read the new views without access to raw personal data. Those answers set the cost of this step, which depends on the number of views and the team's existing dbt skills.

Exports and integrations to move from Looker

Migrating off Looker touches four flows: the LookML definitions in Git, the query results and dashboards users pull out, the Metabase application database that holds your configuration, and the identity provider that signs people in. Each card below names one of these and the documented path to it.

LookML model definitions in Git

Each LookML project maps to a Git repository, and Looker connects to GitHub, GitLab or Bitbucket over HTTPS or SSH. Clone that repository before any renewal decision so the view, explore and model files survive whatever Looker contract follows. Plan to read these files as a specification: Metabase does not import LookML, so each explore join and measure must be rebuilt as a Metabase model or metric or moved into dbt or warehouse views first.

Looks, explores and dashboard downloads

Business users pull query results and dashboard PDFs or CSVs from Looker, and those downloads are often the only copy of a figure that finance or operations relies on. Inventory the most-used Looks and dashboards, then export representative result sets so you can compare Metabase output against them during parallel running. Row limits that depend on user permissions can make a Looker export incomplete, so confirm who runs the extraction and under which account.

Metabase application database

Metabase stores dashboards, questions, collections and permissions in its own application database. The embedded H2 database is meant for demos, so production needs PostgreSQL or MySQL 8.4.0 or MariaDB 10.6.0 or later with utf8mb4. If a trial instance already ran on H2, Metabase documents a one-time load-from-h2 command, which must run with the same Metabase version that last wrote the H2 file. Back up this database before every upgrade.

Google sign-in and LDAP

The open source edition and the Starter plan support Google sign-in and LDAP, which covers many small and mid-sized teams without an extra license. Confirm which directory groups must map to Metabase groups, since group-based permissions depend on that mapping. Test sign-in with a user from each group and verify that deprovisioning a leaver in the directory blocks access in Metabase, because without SCIM that step may be manual.

SAML, OIDC and SCIM provisioning

JWT, OIDC, SAML and advanced LDAP group and attribute sync are documented on the Pro and Enterprise plans, with setup guides for Auth0, Entra ID, Google, Keycloak and Okta. SCIM provisioning is also limited to those plans. Before you buy, check which identity provider your bank or public body requires, whether SCIM must automate joiners and leavers, and whether you need row-level permissions tied to attributes, which also sit on Pro or Enterprise.

Warehouse connection and service accounts

Metabase queries your warehouse directly, so every data source needs a connection that uses a dedicated service account with read-only grants. Looker used its own connection credentials, and those rarely transfer cleanly. Map each Looker connection to a Metabase database entry, record which schemas each group may see, and confirm that the service account cannot write, because Metabase users can run native SQL against any table the account can read.

Migration sequence from inventory to decommission

This sequence moves Looker content into Metabase in an order that keeps governed logic in one place, proves the numbers match, and ends with Looker switched off only after the parallel run is signed off. Each step produces a written artifact that the next step depends on.

Inventory Looks, dashboards, explores and schedules
Export the full catalog of Looker content: dashboards, Looks, Explores, scheduled deliveries, and the users and groups that can see each item. Pull the LookML models and views from the project's Git repository, since each LookML project corresponds to a Git repository, so the definitions are captured under version control rather than only in the Looker UI. Record which dashboards are used, who owns them, and which scheduled deliveries feed other teams. The output is a single inventory sheet with one row per asset, a usage column, an owner, and a keep, merge or retire decision. Confirm the inventory with the business owners before anything is rebuilt.
Move shared logic into the warehouse or dbt
Review the LookML measures, dimensions and derived tables in the inventory and sort them into three groups: logic that belongs in the warehouse as views or persistent tables, logic that belongs in dbt models and tests, and logic that is presentation-only and can be rebuilt as a Metabase question or model. Metrics that several dashboards depend on should be defined once in dbt or SQL so that Metabase reads a governed definition instead of a copy. The output is a versioned set of warehouse objects and dbt definitions, each with a short note naming the LookML source it replaces and the test that checks it.
Build Metabase models and metrics for a pilot
Install Metabase in your own infrastructure with PostgreSQL as the application database, which Metabase recommends for production. Connect the warehouse, then build Metabase models and metrics for a small pilot set: a few high-use dashboards and the users who depend on them. Set up people and groups to match the Looker access model, noting that SSO, row and column level permissions and usage analytics need Pro or Enterprise. The output is a signed-off pilot: named pilot users have confirmed that each rebuilt dashboard answers the same questions as its Looker source, and the open items are logged.
Run Looker and Metabase in parallel
Keep both tools live for the same reporting periods and compare the results for each rebuilt dashboard. Check row counts, totals, filters and date boundaries against Looker output, and record every difference with its cause, such as a timezone setting, a null-handling rule or a filter that was not carried over. Ask finance or operations owners to confirm the figures they rely on most. The output is a reconciliation log with each metric marked as matched, explained or fixed, and a list of dashboards cleared for cutover.
Cut over with a verified application database backup
Before moving users, take a backup of the Metabase application database. Metabase recommends backing up the application database before upgrades, and if you started on the embedded H2 database for testing, move it to PostgreSQL first with the documented load-from-h2 command, run with the same Metabase version that last updated the H2 file. Restore the backup into a test instance and confirm it opens and the dashboards render. Then redirect users, publish the cleared dashboards and communicate the new links. The output is a documented cutover record with the backup location, the restore test result and the list of live dashboards.
Decommission Looker at renewal
Keep Looker read-only for the agreed period after cutover so users can look up historical answers, and confirm with Google Cloud or your reseller which renewal date and notice terms apply to your contract. Retain the exported LookML repository, the inventory, and the reconciliation log as the record of what was migrated. Stop scheduled deliveries, remove user access and cancel the subscription only after those records are archived. The output is a closeout memo that lists the archived artifacts, the final access revocation date and the confirmed end of the Looker contract.

How the migration changes by starting point

A small team with a few dozen dashboards and little or no LookML usually has most of its logic in Explores and simple measures. The migration is mainly a rebuild in Metabase: you recreate the important Explores as models, define the few measures people actually reuse as metrics, and rebuild dashboards with the query builder. Because there is little logic to move, the main decisions are about naming and scope rather than architecture.

Model inventory: List every dashboard and Look, then mark which ones are still used. Retiring unused content often removes more work than any conversion.
Models over raw tables: Wrap the joins people rely on in Metabase models so end users see clean, named columns.
Metrics for shared measures: Move the handful of measures that appear across dashboards into metrics so definitions stay consistent.
Collections and permissions: Recreate the folder structure and group permissions in the Open Source edition, where Google sign-in and LDAP are available.
Plan check: SSO, row and column level permissions and usage analytics need Pro or Enterprise, so decide early whether those features are required.

Confirm with your team which dashboards drive decisions before you start rebuilding, since that list sets the acceptance criteria.

What drives cost and duration in this migration

This table lists the factors that change the effort and total cost of moving from Looker to Metabase, and how to keep each one under control. Read the rows as the levers you can shape before work starts, and separate the one-time migration work from the costs that continue after cutover.

Driver	Why it changes cost or effort	How to keep it down
Number of explores and LookML views	Each explore must be rebuilt as a Metabase model or question, and each view's joins and fields must be mapped by hand, so count grows the conversion work directly.	Retire unused explores before conversion and consolidate near-duplicate views into shared models.
Derived tables and persistent logic	LookML derived tables and PDTs have no direct Metabase equivalent, so their SQL must move into the warehouse or dbt, which needs data engineering time and warehouse scheduling.	Inventory every PDT first, then decide per table whether it becomes a dbt model, a view or a scheduled table.
Dashboard count and filters	Each dashboard, tile and cross-filter is rebuilt and checked against Looker output, so the number of visuals and filter interactions sets validation time.	Rebuild only dashboards with active viewers and map filters to Metabase dashboard filters once in a shared pattern.
Permissions and row-level rules	Looker access grants and access filters must be recreated in Metabase groups and, on Pro or Enterprise, row and column level permissions, and every rule needs testing with real user profiles.	Document the current access matrix and collapse it into a small set of groups before rebuilding.
Identity integration	Google sign-in and LDAP are available in the open source edition, while SAML, OIDC, JWT and SCIM provisioning require Pro or Enterprise, so the sign-in method determines the plan you need.	Confirm your identity provider and required sync features early, and confirm with Metabase which plan includes them.
Data volume and warehouse query cost	Metabase queries the warehouse directly, so dashboard refresh frequency, caching and large raw tables drive warehouse compute spend that recurs after migration.	Add aggregated tables or dbt models for heavy dashboards and set caching and refresh schedules deliberately.
Metabase version upgrade path	Upgrades run application database migrations automatically, and older installs must move release by release, so a stale starting version adds upgrade steps and test cycles.	Install the current supported release and back up the application database before any upgrade.
One-time costs	Conversion of explores, PDT rewrites, dashboard rebuilds, permission mapping, validation and user training are paid once, usually to internal staff, a partner or both.	Ask any quote to itemize conversion, validation and training separately so you can compare scope.
Recurring costs	Hosting, the Metabase plan (Open Source is free, Starter and Pro are priced per month with user allowances per the Metabase pricing page), support, warehouse compute and staff time to maintain models continue every month.	Compare plan features against the access and identity needs you actually have, and confirm plan prices on the Metabase pricing page at the time of purchase.

What usually goes wrong and how to prevent it

Most Looker to Metabase migrations stall for the same few reasons: definitions drift, access changes without anyone deciding it should, and cutover happens before the numbers are checked. Each card below names one of these failure points and the step that prevents it.

Metric definitions drift from LookML

A measure written in LookML may filter nulls, apply a case expression or count distinct on a different key than the Metabase metric someone rebuilds by hand. Two dashboards then show different revenue for the same month. Before cutover, write each governed measure as a single SQL definition in the warehouse or dbt, then point the Metabase metric at it. Compare results for at least one closed period.

Permissions become looser or tighter

Looker access is set through roles, model-level access and row-level filters, and those rules rarely map one to one onto Metabase groups and data permissions. Some users gain access to tables they never saw, and others lose a filter they depended on. Export the Looker role matrix, map each role to a Metabase group, and test with a sample account from each group. Row and column level permissions require Metabase Pro or Enterprise, so confirm that licensing before you promise them.

Dashboards that need Looker-only features

Some Looker dashboards depend on features with no direct Metabase equivalent, such as particular custom fields, table calculations or embedded content that a Looker dashboard relies on. Inventory every dashboard and tile before you start, and mark each one as rebuild, simplify or retire. Agree the list with the owners so no report disappears silently at cutover.

Upgrades run migrations automatically

Metabase applies application database migrations on startup, so an upgrade changes the application database without a manual step. A failed migration on a production database can leave the instance unusable. Take a backup of the application database before every upgrade, and for major upgrades reduce a cluster to a single node because of the migration lock. Upgrade release by release if you start from a version older than 40.

H2 left in production

The embedded H2 database is meant for demos. Teams that launch a Metabase instance with defaults and keep it running store dashboards, users and settings in a file that is not built for production load. Move the application database to PostgreSQL or MySQL before users arrive, using the load-from-h2 command with the same Metabase version that last wrote the H2 file. Confirm the move in a staging copy first.

Numbers not validated at cutover

A migration can look complete while figures are wrong, and the first people to notice are often executives reading a board pack. Define a reconciliation set of key metrics, run Looker and Metabase side by side for an agreed period, and record every variance with its cause. Sign-off should come from the metric owners, not only from the BI team. Keep Looker read access until that sign-off is recorded.

Questions buyers ask before moving from Looker to Metabase

How much does it cost to move from Looker to Metabase?

The cost depends on the size of your LookML inventory, how much logic moves into the warehouse or dbt, and how much validation you need before switching off Looker. Self-hosted Metabase Open Source has no license fee, so the recurring costs are infrastructure, the application database, staff time and any paid Metabase plan you choose. The Metabase pricing page lists Starter at $100 per month or $90 per month billed yearly, Pro at $575 per month or $517.50 per month billed yearly, and Enterprise priced by quote starting at $20,000 per year. Ask any provider for a fixed-scope quote that separates one-time migration work from recurring hosting and support.

How long does a Looker to Metabase migration take?

Duration depends mainly on how many Explores, dashboards and scheduled deliveries you have, how many LookML definitions need rewriting as warehouse views or dbt models, and how long side-by-side validation takes with the business owners who sign off on numbers. No supplied figure gives a standard duration, so ask for a timeline tied to a written inventory. A small set of dashboards on clean warehouse tables moves far faster than a large LookML project with custom derived tables and many permission groups.

What does our team need to provide during the migration?

You need three kinds of people. Analytics engineers rebuild LookML logic as warehouse views or dbt models and set up Metabase models and metrics. A platform owner manages hosting, the PostgreSQL or MySQL application database, upgrades and access. A data owner for each metric confirms that the new definition produces the same result as the Looker version. Without named owners for the key metrics, validation tends to stall, so confirm these roles before the work starts.

Can our own team migrate from Looker to Metabase without outside help?

Yes, an experienced internal team can do it, provided it has SQL and dbt skills, time for validation and someone who owns the Metabase deployment. Metabase upgrades run application database migrations automatically, and its documentation recommends backing up the application database first. Outside help is most useful for a fixed-scope inventory, a repeatable deployment, validation against Looker outputs and handover documentation. Compare the cost of your staff time against a written quote before deciding.

Which Metabase plan gives SSO and row-level permissions?

Row and column level permissions, SSO, multi-tenant data segregation and usage analytics and auditing are included in the Pro and Enterprise plans, not in Open Source or Starter. According to the Metabase pricing page, Starter is $100 per month or $90 per month billed yearly with the first 5 users included, and Pro is $575 per month or $517.50 per month billed yearly with the first 10 users included. Google sign-in and LDAP are available in Open Source and Starter, while SAML, OIDC, JWT and SCIM provisioning need Pro or Enterprise. Confirm the plan against your identity provider and access model before you commit.

What happens to LookML logic that does not map to Metabase?

Metabase works from models, metrics and the query builder, so complex LookML logic such as persistent derived tables, custom joins and filtered measures usually needs to move into the warehouse or dbt before the dashboards are rebuilt. Document each definition, decide which layer owns it and confirm the result matches Looker output on the same data. Confirm with your team which features you rely on, since behavior can differ and no single mapping applies to every project.

How do we ask for a fixed-scope quote for this migration?

Send a written inventory that lists the LookML projects and their Git repositories, the Explores, dashboards, scheduled deliveries and user groups in scope, the warehouse platform, and your identity provider and Metabase plan. Ask for scope, deliverables, validation criteria, acceptance steps and the timeline in writing before work begins. Ask the provider to separate the one-time migration, the hosting and backup setup, handover and any recurring support or upgrade retainer. DeployOpen does not publish a price list and provides a quote from the written scope.

How DeployOpen scopes and runs the migration

DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted Metabase inside your own infrastructure, whether that is your cloud account, a data center or an air-gapped network. The work starts with a written scope that names the Explores, dashboards, data sources, identity provider and permission groups in play, and the deliverables that close each phase. Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before any work begins. Before that conversation, confirm which Metabase edition you need, because the features that matter most to Looker teams, such as SSO and row and column level permissions, sit in the Pro and Enterprise plans on Metabase's pricing page. A quote follows from the written scope. DeployOpen does not publish a price list, so ask for a quote that separates the one-time build from any recurring items.

Expect the scope to cover several kinds of work that carry different costs. Platform work includes installing Metabase from the open-source metabase/metabase image or the enterprise image, choosing the application database (PostgreSQL is the production recommendation in Metabase's documentation), and planning the backup and restore path for that database. Integration work covers connecting Metabase to your warehouse, wiring Google sign-in, LDAP or an SSO provider, and rebuilding groups and collections so they match your Looker folders and access model. Migration work covers the Explores and dashboards rebuilt as models and metrics, plus the logic moved into the warehouse or dbt. The effort in each area depends on how many LookML views, persistent derived tables and dashboards you have, and how much of your access control depends on user attributes. Ask the proposal to name each area and its exit criteria.

After go-live, the recurring costs are the hosting you already pay for, the staff time that keeps Metabase current, and any retainer you choose. Metabase's version support page describes non-LTS releases that usually reach end of life after 2 months and LTS releases supported for 14 months, so a retainer or an internal upgrade rota should be part of the plan from the start. Upgrades run application database migrations automatically, and Metabase recommends backing up the application database first and reducing a cluster to a single node for major upgrades. Ask DeployOpen to document that runbook, the backup tests and the rollback steps, and ask what support is included in the retainer compared with the fixed-scope build. Confirm the response expectations in writing rather than relying on general descriptions.

Migrate from Looker to Metabase