Migrate from Looker to Apache Superset: what the move involves
The move from Looker to Apache Superset is a re-platforming of dashboards and governed definitions, not a file import. Looker's LookML models, measures, explores and permissions do not transfer as a package. Each one has to be rebuilt as a Superset dataset, a metric, a warehouse view or a dbt model, and each dashboard has to be recreated and checked against the numbers Looker produces today. Teams usually start with a Looker renewal date, a hosting requirement that Google Cloud core cannot meet, or a concern about lock-in. Whichever one drives the project, the first deliverable is an inventory of what the Looker instance actually does, not a Superset installation.
The work is usually shared by three groups. The platform team owns the Superset deployment, the metadata database, authentication and upgrades. The data team decides where governed logic lives, usually in the warehouse or dbt, and rebuilds the joins and derived tables that LookML currently handles. The BI owners recreate dashboards, confirm metric definitions with the business users who rely on them and sign off on parity. Superset is licensed under Apache-2.0 and has no paid edition, so the license line in the budget is zero, and the recurring costs are the infrastructure, the people who run the platform and the time spent on modeling. Confirm with your own team whether those people already exist or need to be hired or contracted.
The effort and risk depend mostly on how much logic sits in LookML views and explores. A small project with a few explores and simple measures is largely a matter of moving SQL into the warehouse. A large project with many derived tables, access filters,liquid-templated fields and cross-model joins needs a per-object mapping, a side-by-side validation period and a clear cutover plan. Before committing to a timeline, ask for a count of views, explores, derived tables and dashboards in the LookML project, identify which dashboards carry business-critical numbers, and decide which governed definitions will be kept in dbt or SQL so that Superset does not become the only place they live.
Which Looker capabilities map to Superset, and where the gaps are
This table maps each Looker capability to its closest Apache Superset equivalent and marks it as clean, needs rework or gap. Read the status column first: rows marked gap need a decision on whether the logic moves into the warehouse, dbt or Superset before migration starts. The main takeaway is that Superset covers charts, dashboards, alerting and access control well, but explores and LookML's model-level joins must be rebuilt as datasets or warehouse views.
| Looker capability | Superset equivalent | Status | What to do |
|---|---|---|---|
| LookML views and dimensions | Superset datasets with columns and SQL expressions | Needs rework | Move column logic into warehouse views or dbt models, then register each as a dataset |
| LookML measures | Dataset metrics, defined per dataset | Needs rework | Recreate each measure as a metric; confirm aggregation and filter logic against Looker results |
| Explores and joins | No direct equivalent; joins become datasets or warehouse views | Gap | Model each explore's join path as a view in the warehouse so Superset queries a single dataset |
| Persistent derived tables | Warehouse tables or materialized views, referenced as datasets | Needs rework | Rebuild the PDT as a scheduled transformation in dbt or your warehouse orchestrator |
| Dashboards | Superset dashboards with native filters | Needs rework | Rebuild layouts and cross-filters manually; Superset does not import Looker dashboard files |
| Looks | Saved charts | Clean | Recreate each Look as a chart on the matching dataset and check totals |
| Schedules and alerts | Alerts and reports, which need the caching layer and Celery workers | Needs rework | Stand up Redis and Celery workers before recreating schedules and confirm delivery channels |
| Roles and permissions | Superset RBAC roles, with LDAP or OAuth group mapping | Needs rework | Map Looker groups to Superset roles; confirm row-level rules, which must be built as dataset filters |
| Git-based version control | Your own Git repository holding dbt or SQL definitions | Needs rework | Keep metric definitions in Git outside Superset; Superset stores dashboards in its metadata database |
What data and integrations move, and through which documented paths
A Looker migration to Superset moves four kinds of material: modeling code, content definitions, identity records and warehouse connections. Each one follows a different path, and only some of them have a documented export route. The cards below separate what you can pull out of Looker, what you rebuild by hand in Superset, and what needs confirmation before cutover.
LookML model files from Git
Each LookML project corresponds to a Git repository, and Looker connects to GitHub, GitLab or Bitbucket over HTTPS or SSH. The model, view and explore files already live in version control, so the export is a clone of the repository rather than a Looker download. Check which branch is production, whether unmerged development branches hold logic people still use, and whether any definitions exist only in the Looker IDE. Superset does not read LookML, so these files become reference material for rebuilding measures in dbt or SQL.
Dashboard and Look definitions
Looks and dashboards are Looker content objects, not LookML files, so they do not arrive in the Git repository. Inventory each one with its underlying explore, filters, tiles and owner, then decide which to recreate as Superset charts and dashboards. Expect the rebuild to be manual for most content. Treat the inventory as the scope document for the migration, because it is the only list of what business users rely on.
Users, groups and role assignments
Looker user records, group memberships and permission sets do not transfer into Superset as a data file. Superset stores its own users and roles in the metadata database, and its LDAP or OAuth groups map to roles through AUTH_ROLES_MAPPING. Rebuild this mapping from your identity provider groups, not from a Looker export. Confirm who needs Admin, Alpha or Gamma style access, and which people should lose access on cutover.
Identity integration to rebuild
Superset supports database authentication, LDAP, and OAuth2 providers such as Google and Azure, built on Flask-AppBuilder. Looker sign-in is tied to Google Cloud identity, so this is configuration you write, not a setting you copy. Decide the method first, then test group-to-role mapping with a small set of accounts in staging. Keep database accounts for break-glass access, and confirm with your security team how sessions and MFA will be enforced.
Warehouse connections through SQLAlchemy
Superset reaches any SQL datastore that has a Python DB-API driver and a SQLAlchemy dialect. Install the driver for each warehouse in the Superset image, create a database connection for each one, and test queries against the same schemas Looker used. Confirm network paths, service accounts and credential storage with the warehouse owner. Connections are a one-time setup, but each new warehouse adds driver maintenance to every upgrade.
Dashboard PDF and CSV exports
Dashboard PDF and CSV downloads are produced by Looker itself, so run them from Looker while the instance is still available. Keep the outputs as evidence of the figures business users expected, and use them to compare results in Superset. Do not treat these files as a migration format, because they carry no model definitions, filters or permissions. Exporting data also falls under your own retention and data handling rules.
The migration sequence from inventory to decommission
This sequence moves Looker content to Superset in controlled stages, so each dashboard is inventoried, rebuilt, reconciled against Looker numbers and cut over by group before any Looker contract ends. Each step produces a written artifact that a named owner signs off before the next step starts.
Inventory LookML projects, dashboards and users
Export every LookML project from its Git repository, which Looker connects to over HTTPS or SSH, and pull a list of dashboards, Looks, scheduled deliveries and user groups from the Looker admin console. Record which dashboards are used, who owns them and which warehouse tables and derived tables they read. The output is a dashboard inventory with owner, usage and source tables for each item. The step is done when the business owners have confirmed that the inventory is complete and that unused content is marked for retirement.
Map dashboards to Superset datasets
For each dashboard in scope, document which explore or model it uses, which fields and measures it depends on, and which Superset dataset would serve it. Decide per measure whether it becomes a Superset dataset metric, a warehouse view or a dbt model, since Superset is a general-purpose BI tool and does not carry LookML explores. The output is a dashboard-to-dataset map with a column for the definition location of each measure. The step is done when the data engineering lead and the analytics owner have both reviewed the map.
Build and test a pilot dashboard set
Install Superset in your own infrastructure with PostgreSQL or MySQL as the metadata database, following the production guidance in the architecture documentation rather than the SQLite default. Configure authentication through your identity provider, set a SECRET_KEY, and connect the warehouse using a supported Python DB-API driver. Rebuild a small pilot set of dashboards from the map, prioritizing those with high usage and simple logic. The output is a running pilot environment and a list of rebuilt dashboards. The step is done when each pilot dashboard loads for test users with the expected permissions.
Reconcile metrics in a parallel run
Run Looker and Superset side by side for the pilot set over a defined period of normal use. For each metric, compare the Superset result with the Looker result for the same filters, date ranges and user scope, and record every difference along with its cause, such as null handling, time zone or a join that fans out rows. Keep the reconciliation sheet in version control next to the metric definitions. The output is a metric reconciliation sheet showing matched and unmatched values. The step is done when the analytics owner accepts each remaining difference in writing.
Move governed definitions into dbt or SQL
Before the wider rebuild, move each validated measure into a single definition location, either a dbt model or a version-controlled SQL view in the warehouse, so that Superset datasets reference shared logic rather than copies. Add tests for key measures in the same repository. The output is a governed definitions repository and a list of Superset datasets that point to it. The step is done when a change to a shared measure is made once and appears in every dataset that uses it.
Cut over dashboards by user group
Move users in batches, starting with the group whose dashboards passed reconciliation and ending with the group that relies on scheduled deliveries. For each batch, recreate the alerts and reports that the group receives, confirm that the caching layer and Celery workers are running if those features are used, and announce a date when Looker remains read-only for that group. The output is a signed-off cutover list that records each group, its dashboards, its owner and the date it moved. The step is done when each group owner confirms in writing that their dashboards are in use.
Export Looker content and decommission
Before the Looker subscription ends, export the LookML projects, dashboard definitions and a final usage record, and store them in your own archive so that the logic remains available for audit. Confirm with Google Cloud or your reseller the exact contract end date and data retention terms for your Looker instance, since these are set by your agreement rather than this guide. Then disable user access and retire the instance. The output is an archived export package and a decommission record. The step is done when the archive has been restored or opened by a second team member and the decommission record is signed by the platform owner.
What drives migration cost and duration
This table lists the cost and effort drivers for moving from Looker to self-hosted Apache Superset, with the one-time and recurring components for each. Use it to scope a written quote, since most of the effort sits in modeling and validation rather than in installing Superset. Ask each bidder to price every row separately.
| Cost driver | What it affects | One-time or recurring | What to request in a quote |
|---|---|---|---|
| LookML views and explores | Number of datasets, joins and metric definitions to recreate as Superset datasets or warehouse views | One-time | Inventory counts by view and explore, and which ones map to warehouse views versus Superset virtual datasets |
| Derived tables (PDTs) | Heavy transformation logic that must move into dbt models or warehouse tables before Superset can query it | One-time, then recurring if rebuilds are scheduled | List of persistent derived tables, owner of each, and the refresh schedule to be reproduced |
| Dashboards and complexity | Number of charts, filters, cross-filters and drill paths to rebuild and validate side by side | One-time | Dashboard inventory with chart counts, parameterized filters and any Liquid or custom logic in use |
| Warehouse query cost during parallel runs | Duplicate query load while Looker and Superset run against the same warehouse | Recurring until Looker is cancelled | Warehouse cost estimate for the parallel period, based on your current query volume and billing model |
| dbt or SQL staffing | Hours for writing governed metric definitions, tests and documentation in dbt or SQL | One-time build, then recurring maintenance | Named roles, hours by role and how metric changes are reviewed after go-live |
| Identity integration | Mapping Google, Azure or LDAP groups to Superset roles with AUTH_ROLES_MAPPING and row-level access rules | One-time, then recurring as groups change | Group-to-role mapping plan and how row-level security will be enforced and tested |
| Metadata database and caching layer | PostgreSQL or MySQL for Superset metadata, plus Redis for caching, alerts and async queries | Infrastructure recurring, setup one-time | Sizing for metadata, backup frequency, high availability and who operates the database |
| Celery workers and upgrades | Worker and beat processes for alerts, reports and thumbnails, plus upgrade testing against UPDATING.md | Recurring | Worker sizing, monitoring plan and a staging environment with the upgrade procedure documented |
How the self-hosted Superset stack is built
A self-hosted Superset deployment has four architecture components: the Flask and React application, a metadata database that stores dashboards, charts, datasets and users, an optional caching layer, and optional Celery worker and beat processes. The application and metadata database are the minimum you must run. Plan the metadata database as a managed or supported PostgreSQL or MySQL instance, because the project tests only those two engines for this role. The SQLite default used by Quickstart and PyPI installs, and the PostgreSQL container in the Docker Compose file, are not recommended for production, so do not carry them into a production design. Check the supported version ranges in the Superset configuration documentation before you pick a database version.
The caching layer and Celery workers are not optional for every feature you may need. Alerts and reports, async queries and dashboard thumbnails depend on them, and most installations use Redis as the cache and Celery as the task runner. If the migration plan includes scheduled PDF or email delivery of Looker-style scheduled looks, budget for workers and a cache from the start rather than adding them after go-live. Confirm with your platform team who will operate Redis and the worker processes, how they are monitored, and how they restart after a node failure.
Set a unique SECRET_KEY before the first start. Superset refuses to start without one, a requirement added in version 2.1.0, and the key signs sessions and encrypts stored credentials. Store it in your secrets manager, not in a checked-in config file. When you rotate it, use PREVIOUS_SECRET_KEY so existing data stays readable during the transition. Record the key's owner and rotation procedure in your runbook, since losing or changing it without the previous value can break access to saved database connections.
How the migration differs by starting point
A mature LookML project already lives in a Git repository, because each Looker project corresponds to one repo that Looker connects to over HTTPS or SSH. That makes the model definitions portable, but the hard part is not copying files. Superset has no LookML parser, so each view, dimension and measure must be re-expressed as a Superset dataset metric, a warehouse view, or a dbt model that Superset reads. The effort concentrates in the translation and reconciliation steps.
- Measure translation: Each LookML measure with filters,
sql_always_wherelogic or symmetric aggregates needs an explicit SQL expression or a warehouse view that reproduces it. - Join logic: Explores encode joins and join types. These must move into SQL views or dbt models, since Superset datasets do not reproduce explores.
- Derived tables: Persistent derived tables become warehouse objects that a scheduler refreshes, so their refresh ownership must be assigned.
- Side-by-side validation: Compare query results for the same filters in Looker and Superset before retiring any dashboard.
- Git as source of truth: Keep governed definitions in the repository, whether as dbt YAML or versioned SQL, so the Git history survives the move.
Confirm with your own team which LookML features are in use, since the translation effort depends on that inventory rather than on the number of files.
Many teams have accumulated hundreds of saved Looks and dashboards built by individual analysts, with few governed explores behind them. The content is numerous but shallow, so the migration is mostly an inventory and triage exercise. Much of the old content may no longer be used, and that should be checked against query logs before any rebuild work starts.
- Usage triage: Identify which Looks are viewed, scheduled or embedded, and retire the rest instead of rebuilding them.
- Consolidation: Many near-duplicate Looks can collapse into one Superset chart on a shared dataset with filters.
- Ownership: Assign an owner for each surviving dashboard, since ad hoc content often has no clear maintainer.
- Modeling gap: Without explores, there is no shared model to lean on, so the team must decide which metrics become governed and write them once in SQL or dbt.
- Self-service expectations: Superset's SQL Lab and chart builder suit analysts who write SQL, but business users used to Explores will need training.
Ask for an export or usage report from the Looker admin console early, because the list of content in use shapes the whole plan.
Embedded Looker content is served inside a customer's application through signed embedding, which is part of the Embed edition. Moving it means replacing the signing flow and the embed host, not only the dashboards. Superset offers an embedded SDK with guest tokens, so the application must be changed to request tokens and to pass the right row-level context. Embedding is a product-level change that touches the application team and the security review.
- Authentication change: Replace Looker signed URLs with Superset guest tokens and confirm the token lifetime and scope with the Superset documentation for your version.
- Row-level context: Rebuild per-tenant or per-user filtering as Superset row-level security rules or as warehouse views.
- Application code: Update front-end and back-end code that generates embed links, and test each embedded view.
- Operational load: The Superset instance now serves end users directly, so capacity, caching and uptime become part of the application's service level.
- Hosting boundary: Looker Embed content is Google-hosted, so self-hosting also moves the data path inside your control.
Check the embedding comparison page before committing, because the choice of embed method affects the migration scope.
A small estate of a few dashboards on a handful of explores is the lightest case. The fastest path is to rebuild the dashboards directly on Superset datasets and to write only the metrics the dashboards need. Because the content is limited, the process can run as a single short project, but the basics still matter: secrets, backups and access control must be in place before users arrive.
- Direct rebuild: Recreate each dashboard from the underlying SQL, using Superset datasets with the measures written as dataset metrics.
- Metadata database: Use PostgreSQL or MySQL for Superset metadata rather than the SQLite default, which is not recommended for production.
- Authentication: Connect Superset to your identity provider through OAuth or LDAP and map groups to roles with AUTH_ROLES_MAPPING.
- Required secret: Set a SECRET_KEY before first start, as Superset requires one.
- Validation: Compare figures against Looker for a fixed set of reference reports before switching users over.
Confirm the exact number of dashboards and their owners with your analytics team, since a small estate still needs a named cutover date.
What usually goes wrong and how to prevent it
Most Looker to Superset migrations fail in predictable places: definitions drift, joins change results, and cutover happens before anyone proves the numbers match. The cards below cover six failure points, each with a check to run before the Looker renewal date forces the decision.
Metric drift between LookML and Superset
A measure such as net revenue may be defined in LookML with filters, sql_always_where or a case expression, then recreated in Superset as a slightly different SQL metric. The two tools then disagree on the same dashboard number. Prevent it by moving every governed measure into one version-controlled source, either warehouse views or dbt definitions, and having Superset datasets reference those objects instead of retyping the logic. Compare each metric to the Looker output for the same date range and filters.
Fan-out joins and double counting
Looker explores generate joins from declared relationships, so a one-to-many join is handled according to the view definitions. A hand-written Superset SQL Lab query or a multi-table virtual dataset can join the same tables without that guardrail, and sums then inflate silently. Prevent it by writing each join as a tested view with an explicit grain, and checking row counts before and after each join against the Looker explore for a sample of keys.
Undocumented dashboard filters
Looker dashboards often carry filter fields that apply to several tiles through explore-level field mappings, and users rely on them without knowing they exist. In Superset each chart has its own filter scope, so a filter that once applied to every tile can quietly stop applying to some of them. Prevent it by inventorying every Looker dashboard filter and its target tiles in a spreadsheet, then confirming each one in the Superset native filter configuration before users are moved.
Permissions that do not map to roles
Looker grants access through model sets, permission sets and folder access, and row-level restrictions are often expressed as access filters. Superset controls access through roles, dataset permissions and row-level security rules, which must be recreated by hand. Prevent it by listing every Looker group with its effective model and folder access, then mapping each group to a Superset role and RLS rule. If you use LDAP or OAuth, confirm the AUTH_ROLES_MAPPING entries before go-live.
Skipped metadata database backups before upgrades
Superset stores dashboards, charts, datasets and permissions in its metadata database, and an upgrade runs schema migrations against it. A failed migration without a backup means rebuilding the BI layer by hand. Prevent it by taking a verified backup of the PostgreSQL or MySQL metadata database before each upgrade, running the upgrade first in staging, and reading UPDATING.md for breaking changes between versions.
Cutover without reconciliation sign-off
Teams often switch users to Superset once the main dashboards look right, without a documented comparison of key figures. Finance or operations users then discover differences weeks later, and trust in the new platform drops. Prevent it by agreeing a reconciliation list of top metrics and dashboards with named business owners, recording the tolerance for each difference, and making a written sign-off a precondition for turning off the Looker schedules and access.
Questions buyers ask before moving from Looker to Superset
How much does moving from Looker to Superset cost?
The software itself has no license fee, because Apache Superset is Apache-2.0 licensed and has no paid edition. The cost is the work and the infrastructure: servers or cluster capacity, a metadata database, the optional caching and worker components, warehouse query spend, and the people who model metrics, rebuild dashboards and run upgrades. Looker costs depend on the edition and user licenses you hold today, so compare your renewal quote against the one-time migration effort plus the recurring hosting and support lines. Ask any implementation partner for a fixed-scope quote built from the number of dashboards, datasets and LookML views in scope, and ask which items recur every year.
How long does a Looker to Superset migration take?
No duration is fixed by the product, so the timeline depends on the size of your LookML project, how many dashboards and scheduled deliveries must be rebuilt, and how many source systems sit behind the models. The main drivers are the count of Explores and derived tables, the number of dashboards whose users must sign off, and how much logic must move into the warehouse or dbt first. Before you set a date, export the LookML from your Git repository, inventory dashboards and permissions, and plan a parallel run against your current Looker renewal date.
What does our team need to provide for the migration?
You need read access to the LookML repository, a list of dashboards, schedules and users with their groups, and access to the data warehouse with a role that can create views and datasets. You also need a named owner who can approve metric definitions, because each measure must be agreed before it is rebuilt. Staging infrastructure for Superset, identity provider details for LDAP or OAuth group mapping, and a window for side-by-side validation are also required. Confirm these inputs in writing with any partner before work starts.
Can our internal team run the migration without outside help?
Yes, a team with SQL skills, warehouse administration experience and someone who can run Superset in a container or on Kubernetes can do the work in house. The skills that are hardest to staff are the LookML-to-SQL translation, the metric review with business owners and the production operations of the metadata database, cache and workers. An outside implementation partner is most useful when the team lacks one of those skills or needs the work finished inside a fixed window. Decide this by comparing your staff's time against the migration inventory.
How do we keep governed metrics without LookML?
Superset does not replace a modeling layer, so governed definitions have to live somewhere you control. The common approaches are warehouse views that hold the aggregation logic, dbt models or metrics checked into Git and reviewed like code, and Superset dataset metrics that reference those governed views rather than raw tables. Keep the definition in one place, test it with a reconciliation query against the Looker result, and treat changes as pull requests. Ask any partner how they will version the definitions and who approves a change.
What happens to Looker-only features like Explores and persistent derived tables?
Explores, which give business users a guided join and field picker over a modeled schema, have no direct equivalent in Superset. Users build charts from datasets and use the SQL Lab IDE, so joins and measures should be pre-modeled in views. Persistent derived tables must be recreated as warehouse tables or dbt models with their own refresh schedule. Scheduled deliveries, row-level access and embedding also need a plan, because Superset handles them through its own alerts, reports, roles and embedded SDK configuration, which you should test before cutover.
How are Superset upgrades handled after go-live?
Superset is an actively released project, so upgrades are a recurring operating task. The upgrade documentation says to back up the metadata database, run superset db upgrade and superset init, test the new version in staging first, and check UPDATING.md for breaking changes between versions. Pin the version you deploy, rotate the SECRET_KEY only with PREVIOUS_SECRET_KEY in place, and schedule upgrades as a routine change. Ask any retainer provider which upgrade and testing steps are included and how often they run.
Does DeployOpen help with the migration and the ongoing operation?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope you agree. Ask for the list of Superset components, environments and dashboards included in that scope before you sign.
How DeployOpen scopes and runs a Looker to Superset migration
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted Apache Superset inside your own infrastructure, whether that is your cloud account, a data center or an air-gapped network. For a Looker migration, the first written deliverable is a scope that names the Superset deployment target, the metadata database, the caching and worker components if you need alerts, reports or async queries, the authentication path (database, LDAP or OAuth through Flask-AppBuilder) and the set of LookML views and explores that will become Superset datasets. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before any work starts, and you can hold the team to that document at each review.
Before scoping, your team should decide which Looker content is in and out of the first phase, which warehouse connections Superset must reach, and who owns the governed metric definitions after cutover. DeployOpen will ask for the Git repository behind your LookML project, an inventory of dashboards and scheduled deliveries, and the role mapping you need for AUTH_ROLES_MAPPING. Ask for each deliverable to be listed with an owner, an acceptance check and a rollback step. Ask any vendor, including DeployOpen, to state how the metadata database will be backed up, how SECRET_KEY is managed and how an upgrade will be tested in staging against the release notes first.
DeployOpen does not publish prices, and a quote follows from the written scope. The main cost drivers are the number of LookML objects to translate, the number of dashboards to validate side by side, the infrastructure you choose, the authentication integration and the support model after go-live. Ongoing support, upgrades and continuous testing are available as a retainer, which is usually the better fit when your team will own Superset day to day but wants an external party for patches, backups and security reviews. Request a quote that separates one-time migration work from recurring hosting and retainer fees so you can compare it with your current Looker renewal line by line.
