Migrate from Metabase to Apache Superset

How to migrate from Metabase to Apache Superset without losing governed access

Most of your Metabase content is rebuilt in Superset, not imported. Metabase questions, models and dashboards do not map one to one onto Superset objects, so the effort follows three counts: the number of questions and models you need to keep, the permission rules attached to groups and data, and the embedded dashboards that customers or staff see from outside Metabase. Apache Superset is released under the Apache License 2.0 (SPDX: Apache-2.0) and the project has no paid edition, so the cost question is the partner, hosting and your team's time rather than a license fee. Treat the move as a planned rebuild with a parallel run, not a file copy.

Start with an inventory that records, for each Metabase item, the database it reads, who uses it, how often it is opened, and whether it is embedded. Metabase serialization exports content as YAML files, but only on the Pro and Enterprise plans, so confirm which plan you run before you plan to use it as a source of truth. Many of your access rules will also need redesign: Superset controls access through roles, dataset permissions and row level security, so each Metabase group and row or column restriction needs a named Superset role and a tested RLS filter. Confirm with your security team which Metabase permission rules are enforced today and which are only conventions, because the second kind rarely survives a migration without being noticed.

Plan the parallel run before the cutover date. Run both tools against the same warehouse for a fixed set of business reviews, compare results and access outcomes for each rebuilt asset, and have the data owner sign off. Check identity separately: Superset supports OAuth2 providers, LDAP and mapping of groups to roles through AUTH_ROLES_MAPPING, so decide how your existing identity provider maps to Superset roles before users log in. For embedding, Metabase's SSO and embedding options at Pro and Enterprise levels do not carry over directly, so each embedded dashboard needs its own guest token or public design reviewed for tenant isolation. Keep Metabase read-only during the parallel run and retain its application database backup until the sign-off is complete.

What maps from Metabase to Superset and what must be rebuilt

This table pairs each Metabase capability with its closest Superset equivalent and marks whether it transfers as data, must be rebuilt by hand, or needs a design decision first. Read the last column as the confirmation list: where behavior must be verified in your own environment rather than assumed to match.

Capability	Superset equivalent and handling	Transfer type, and what to confirm
Saved questions	Charts built on SQL Lab queries or datasets. Metabase question definitions are not a direct import, so each question is recreated and compared against the same results.	Rebuilt by hand. Confirm row counts and filter logic match on a sample of questions before retiring any Metabase original.
Models (curated datasets)	Virtual datasets saved from SQL Lab, or physical datasets on warehouse tables. Model logic becomes SQL that your team owns and versions.	Needs a design decision. Decide which models become shared datasets and who owns their SQL after cutover.
Collections	No direct equivalent. Charts and dashboards are organized by ownership and by roles, so folder structure is a planning exercise.	Design decision. Map each collection to an ownership pattern and confirm who can see which assets.
Dashboards and filters	Superset dashboards with native filters. Layout and filter wiring are rebuilt, and cross-filter behavior should be tested per dashboard.	Rebuilt by hand. Confirm filter defaults and cross-filtering behave as expected on each migrated dashboard.
Groups and permissions	Superset roles assigned to users, with group sync through LDAP or OAuth group mapping where your identity provider supports it.	Design decision. Redesign roles from scratch rather than copying Metabase group permissions, then confirm access per role in a test instance.
Sandboxing and row-level restrictions	Row level security filters attached to datasets and roles. Metabase sandboxing rules must be translated into explicit RLS clauses.	Needs a design decision. Test each restriction with a non-admin test user, since the rules are not transferred automatically.
Embedding	Superset embedded SDK with guest tokens for applications. Signed Metabase embeds do not carry over and the integration code must change.	Rebuilt by hand. Confirm token lifetime, tenant isolation and browser settings in your own environment before go-live.
Scheduled subscriptions and alerts	Superset alerts and reports. These depend on the caching layer and Celery worker components, so they need that infrastructure in place.	Rebuilt by hand. Confirm delivery, schedules and recipients per report, since they do not transfer from Metabase.
Serialization (YAML export)	Superset exports dashboards, charts and datasets as ZIP archives. Metabase YAML files are not read by Superset and are used only as a reference during the rebuild.	Reference only. Use Metabase serialization output as a rebuild checklist, and confirm the Superset import behavior on your target version.

Why Metabase content cannot be imported into Superset in one step

Metabase content cannot move into Superset in one step because the two platforms store their work in different formats and Superset's import path only accepts its own asset format. Start by confirming which Metabase plan your team holds. Metabase serialization, the feature that exports content as YAML files, is only available on the Pro and Enterprise plans, whether you self-host or use Metabase Cloud. On Open Source or Starter, you may have no supported export at all, so the first inventory may need to come from the Metabase interface, the application database or a manual catalog of questions, models and dashboards. Check the Metabase serialization documentation against your plan before you plan the work.

Even with a complete YAML export, nothing is imported into Superset as is. Superset's documented import path works on its own ZIP-based asset bundles of databases, datasets, charts and dashboards. Metabase questions, models and dashboard layouts have to be translated by hand or with your own scripts into Superset datasets, SQL Lab queries, charts and dashboard positions. Question logic such as filters, joins, summaries and custom expressions must be rewritten and compared against the original results, since the two tools generate SQL differently and may apply defaults, such as time zones or null handling, in different ways. Treat each translated chart as a new artifact that needs its own test against known values.

Use the export as a reference and inventory, not as a finished migration. It gives you a list of what exists, who owns it and which databases it reads, which is useful for deciding what to retire. Record for each item whether it will be rebuilt, merged with an existing Superset dataset or dropped, and confirm with the business owners before you start. Also confirm the Superset release you will deploy, since asset import behavior changes between versions and is documented in the Superset upgrade notes. Plan a parallel run where both tools show the same figures for a agreed set of business questions before the Metabase content is switched off.

Documented export and import paths on each side

Both products offer export paths that carry some content across without custom code, but none of them moves everything. Each path below covers a different layer of the work, from saved content and users to database connections, so the team can plan which items are exported, which are recreated by hand and which need checking against the versions actually in use.

Metabase serialization export

Metabase serialization writes content out as YAML files, but it is available only on the Pro and Enterprise plans, both self-hosted and on Metabase Cloud. Confirm that your current plan includes it before you plan around it. Check which object types the export covers in your Metabase version, such as questions, dashboards and collections, and which it leaves out, such as user accounts and some permission settings. The YAML output is a mapping source, not a direct import into Superset, so the team still rebuilds each item as a dataset or chart.

Metabase API content reads

If your team has administrator access, the Metabase API can read questions, dashboards, collections and database settings in a form you can script against. This is the route for building a complete inventory when serialization is not available on your plan. Confirm the endpoints and response fields against the Metabase version you run, because the API is not a stable export format. Credentials for database connections are not returned in plain text, so record which connections need new passwords in Superset.

Superset ZIP export and import

Superset exports dashboards, charts and datasets as a ZIP bundle, which you can import into another instance to move content between environments. Database connection passwords are not included in the bundle, so each target connection needs its credentials entered again. Review how the import handles existing UUIDs and whether it overwrites matching objects, because this affects a migration into an instance that already holds content. Confirm the bundle format for your Superset version before scripting imports.

Superset database connections and datasets

Database connections and datasets are created in the Superset interface rather than imported as part of content in many workflows. Each Metabase connection maps to a Superset database connection, and each Metabase model or saved question that defines a reusable table becomes a virtual or physical dataset. Record the connection string, driver, schema and any SQL definitions, then recreate them on the Superset side. Confirm the driver versions your warehouse needs, since they are not carried over from Metabase.

Metabase permissions and groups export

Metabase groups, collection permissions and data permissions are configured through the admin interface, and their export depends on your plan and version. Serialization and the API may expose group membership, but they do not map directly to Superset roles. Document each group, its collection access and its data access before you design the Superset roles and row level security rules. Treat this inventory as the input to the role design, not as a configuration file to replay.

Version and plan checks

Both products change between releases, so the paths above can shift between the versions you run and the versions you migrate to. Confirm the serialization format, the API responses and the Superset import behavior in a staging copy of both products before the migration plan is final. Record the Metabase version and plan, the Superset version and the database driver versions in the migration runbook, so the team can repeat the exports later if a step fails.

Turning Metabase groups, sandboxes and embeds into Superset roles and RLS

In Metabase, people are placed in groups, and those groups decide which collections, databases and data permissions a person receives. Group membership can come from manual assignment or, on the plans that support it, from directory sync. Superset works differently: users hold one or more roles, and roles bundle permissions on databases, datasets, dashboards and charts. Superset can map LDAP or OAuth groups to roles through AUTH_ROLES_MAPPING, so the directory remains the source of truth for membership. Plan the role list before you configure the mapping, because each Metabase group usually needs a decision about which Superset role or roles it becomes.

Inventory group membership: Export the list of Metabase groups and their members from the admin console, and mark which groups exist only for permissions rather than for people.
Check the identity source: Confirm whether your current Metabase plan includes JWT, OIDC, SAML, advanced LDAP group sync or SCIM provisioning. The Metabase people and groups documentation lists these as Pro or Enterprise features.
Map groups to roles: Decide which Superset roles replace each Metabase group, and whether any group becomes several roles.
Configure AUTH_ROLES_MAPPING: Set the mapping for your LDAP or OAuth provider, then test with a small set of accounts before enabling it for all users.
Plan for drift: Remove the manual role assignments you created during testing so that directory changes flow through the mapping.

Confirm the group names your identity provider sends, because a mismatch between directory names and mapping keys is the most common reason users arrive without the access they expect.

Migration sequence: inventory, pilot, parallel run and cutover

This sequence moves Metabase content and users onto Superset in controlled stages, so each dashboard is proven against known results before users and embeds move and Metabase is retired. The output is a tested rollback point at every stage and a signed-off cutover.

Inventory Metabase content, users and integrations
Export a full inventory of collections, saved questions, models, dashboards, pulses and subscriptions, alerts, data source connections, groups and permission settings, and every embed and its authentication method. Use Metabase serialization where your plan includes it to produce YAML copies for review, and record which items are used, by whom and how often. The step is done when every asset has an owner, a keep, rebuild or retire decision, and a row in a shared tracking sheet. Confirm which Metabase plan you run, because serialization and SSO, row and column permissions are limited to the Pro and Enterprise plans.
Stand up Superset on a production metadata database
Deploy Superset with PostgreSQL or MySQL as the metadata database rather than the SQLite default, and set a user-specified SECRET_KEY before the first start. Configure the caching layer and Celery worker and beat if you plan to use alerts, reports, async queries or dashboard thumbnails, since these require them. Confirm the metadata database version against the supported range in the configuration documentation before you build. The step is done when the instance starts, logs in through the identity provider you intend to keep, and passes a backup and restore test of the metadata database.
Build a pilot slice of datasets, charts and roles
Choose one or two business areas with a limited number of dashboards and a clear owner. Rebuild their source tables or models as Superset datasets, recreate the charts and dashboards, and map the Metabase groups in scope to Superset roles, adding row level security where Metabase enforced row restrictions. Include at least one dashboard that uses filters, a calculated metric and a scheduled delivery if those are in use. The step is done when pilot users confirm access matches what they had in Metabase, and each rebuilt chart returns the same figures as its original for an agreed date range.
Run both tools in parallel with reconciliation
Keep Metabase live for the pilot and the remaining content while the pilot users work in Superset for an agreed period. Compare each rebuilt chart against its Metabase source on the same data and filters, log every difference with its cause, and fix the Superset dataset or metric until the figures match or the difference is explained and accepted. Assign a named owner to each dashboard who signs off that it is correct. The step is done when every in-scope dashboard has a signed reconciliation record and an owner who has approved it.
Build the remaining content in waves
Repeat the rebuild and reconciliation cycle for the rest of the inventory, grouped by business area and by dependency, so shared datasets are built once. Retire content that the inventory marked as unused rather than rebuilding it, after confirming the decision with its owner. Keep a running count of rebuilt, reconciled, retired and open items. The step is done when every item in the inventory has one of those four statuses.
Cut over users and embedded analytics
Move users to Superset by announcing the date, switching links and bookmarks, and disabling new content creation in Metabase for the in-scope groups. Repoint each embed to Superset only after its authentication and tenant isolation design has been tested, because Metabase embedding and Superset embedding use different mechanisms. Keep the Metabase instance available in read-only form for the agreed fallback period. The step is done when all in-scope users log in to Superset, every embed renders with the correct data for each tenant, and the owners have confirmed their content.
Back up Metabase and decommission it
Before shutting Metabase down, back up its application database and keep the backup and the Metabase version that produced it, since Metabase upgrades run application database migrations automatically. Retain that backup as the rollback point for as long as Metabase is still in use, because restoring it is the only clean way back. Once the agreed fallback period ends and no reconciliation issues remain open, stop the service, revoke its data source credentials and archive the serialized exports and the backup under your retention policy. The step is done when the archive is verified restorable and the Metabase service is removed from your inventory.

What drives Metabase to Superset migration cost and duration

This table lists the cost components of a Metabase to Superset move and what moves each one. Read each row as a question to answer in your own inventory before requesting a quote. The main takeaway is that the number of rebuilt assets, permission redesign and parallel-run length drive most of the effort, while Metabase licensing during the run is a recurring cost that depends on your current plan.

Cost component	What moves it	Cost behavior
Saved questions and models	Count of questions, models and the SQL behind them that must be rebuilt as Superset datasets and charts	One-time rebuild effort that scales with the inventory and how much logic is duplicated
Dashboards with filters	Number of dashboards, native filters, cross-chart interactions and drill-through paths	One-time build and test effort; dashboards that depend on Metabase-specific behavior need redesign
Groups and row-level rules	Number of Metabase groups, collection permissions and row or column restrictions to map to Superset roles and RLS	One-time design effort; access model decisions drive review and testing time
Embedded dashboards	Number of embedded views, the tenant model and how signed or guest access is issued today	One-time rework of embedding code and tenant isolation tests, which can outweigh chart rebuilds
Scheduled reports and alerts	Number of subscriptions, alert conditions and recipients, and the delivery channels in use	One-time rebuild plus a recurring need to run the caching layer and Celery workers in your infrastructure
Source databases and privileges	Number of connected databases, credential handling and the privileges each service account needs	One-time connection setup and privilege review; more sources add testing across each connection
Parallel-run length	Number of weeks both tools run, the user groups involved and the reconciliation checks agreed	Recurring cost of hosting both platforms and staff time for comparing results for the whole run
Metabase plan during the run	Features your team uses today, such as SSO, row-level permissions and embedding, which are limited to Pro and Enterprise	Recurring. Metabase lists Starter at $100 per month ($90 billed yearly) and Pro at $575 per month ($517.50 billed yearly), with per-user fees of $6 (Starter) and $12 (Pro), per the Metabase pricing page

Risks in a Metabase to Superset migration and how to prevent them

Most failures in a Metabase to Superset move come from assumptions that carry over silently: metric logic, access rules, embeds, schedules and the platform underneath. Each card below names one risk, the prevention step and the check that shows the step worked, so your team can verify cutover readiness instead of trusting the migration plan.

Metric definitions drift between tools

A Metabase question may compute a revenue or active-user figure through a model, a filter or a summarized column that does not map one to one onto a Superset dataset metric or a virtual dataset query. Rebuilt charts can return numbers that look plausible but differ from the source. Prevention: record each governed metric's SQL and filters before the move, then define it once in the Superset dataset. Check: run the same date range and segment in both tools and reconcile totals for every metric that finance or regulators read.

Access rules lost in group rebuild

Metabase row and column permissions, collection access and group memberships do not transfer as Superset roles and row level security filters. If groups are recreated by hand without RLS, users may see more rows than they should. Prevention: design Superset roles and RLS rules from the Metabase permission matrix, and map identity provider groups deliberately. Check: test each role with a named test account and confirm that restricted users see only their permitted rows and columns.

Embedded dashboards break at cutover

Metabase embeds rely on its own signed embedding setup and URLs, so product pages that load them will fail once the Superset host, token logic or dashboard IDs change. Breakage often appears only after the old instance is switched off. Prevention: inventory every embed location, plan the Superset embedding approach and tenant filtering before cutover, and keep the old embeds live during the parallel run. Check: load each embedding page in staging with the production-like tenant and confirm the correct data and no browser security errors.

Scheduled reports stop without an owner

Metabase subscriptions and alerts keep sending after the people who created them leave, and nobody notices when they stop. Superset alerts and reports need their own configuration, the caching layer and Celery workers, and a named owner per report. Prevention: list every active subscription and assign an owner and recipient list before rebuilding it in Superset. Check: confirm each rebuilt report delivers a test run, and that worker and beat processes are monitored so a stopped schedule raises an alert.

Metadata database on an unsuitable platform

Superset stores dashboards, users, roles and connection settings in its metadata database. The SQLite default of quickstart and PyPI installs and the Docker Compose PostgreSQL container are not recommended for production, and the metadata database must be PostgreSQL or MySQL within the supported versions. Prevention: provision a production-grade PostgreSQL or MySQL instance with backups before importing content, and keep the SECRET_KEY recorded securely. Check: confirm the Superset configuration points to that instance, the version falls within the supported range, and a restore from backup has been tested.

Upgrade steps skipped after install

Teams that install a new Superset and then move on often skip the upgrade routine they will need later. Each Superset upgrade requires a metadata database backup, running superset db upgrade and superset init, testing in staging first, and reading UPDATING.md for breaking changes. Skipping these steps can leave the metadata schema and roles out of step with the code. Prevention: write the upgrade runbook during the migration, pin the version, and rehearse it in staging. Check: confirm the staging upgrade completes, dashboards and RLS rules still return expected results, and the notes for the target version were reviewed and signed off.

Questions teams ask before moving from Metabase to Superset

How much does a Metabase to Superset migration cost?

The migration cost is the fixed-scope quote for the work, plus the recurring cost of running Superset. Apache Superset is licensed under Apache 2.0 and has no paid edition, so the license itself adds nothing. The quote depends on the number of dashboards and questions to rebuild, the number of data sources, how many metric definitions need sign-off, how many groups and permissions must be redesigned, and how many embedded views exist. Recurring costs include hosting, the PostgreSQL or MySQL metadata database, the cache and worker components, and staff time for upgrades. For comparison, 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 written scope that lists inventory, deliverables, what is rebuilt and what is moved, and the price of any change request.

How long does moving from Metabase to Superset take?

The timeline is set by how much content must be rebuilt and how many people must approve it, not by the tools themselves. The main drivers are the number of questions and dashboards that become Superset datasets and charts, the time business owners need to sign off on metric definitions, the redesign of permissions into roles and row level security, the embedding changes, and the parallel-run period in which both tools show the same numbers. The version you move to also matters. The Superset upgrade guide asks you to back up the metadata database, run the upgrade in staging first and check UPDATING.md for breaking changes. Superset 6.1.0 was published on May 13, 2026, so confirm which release your team will standardize on. Ask for a phased plan with named milestones, a defined parallel-run window, and a cutover date tied to sign-off criteria.

What must our team provide before a Metabase to Superset migration starts?

Your team must provide access, inventory and decisions that only your organization can make. The usual inputs are:

Read-only access to each source database or warehouse, with a service account that Superset can use
A list of Metabase groups and their members, along with the data each group should see
A named owner for every dashboard and collection in scope, who accepts or retires each one
Written sign-off on metric definitions, filters and calculations that users rely on for decisions

Also confirm who approves cutover, where Superset will run, and which identity provider users sign in with. Missing owners are the most common cause of delay, because nobody can say whether a dashboard should be rebuilt, merged or retired. Ask the provider to list these inputs in the written scope with a date by which each is needed.

Can our internal team migrate from Metabase to Superset alone?

An internal team can do the work if it has the skills and time for the full cycle. The skills include SQL and data modeling, Superset administration with roles and row level security, container or Kubernetes operations, PostgreSQL administration, and identity integration. Superset must be given a SECRET_KEY to start, and production deployments should use PostgreSQL or MySQL for the metadata database, not the SQLite default. Your team also needs to run the parallel period, validate numbers and manage the cutover. Consider whether anyone has run Superset in production before. A practical first step is a pilot with a small set of dashboards that have clear owners, which shows the actual effort before you commit to the full inventory. Compare the staff time with the written scope from a partner, including the parts your team would learn while doing the work.

Can Metabase content be exported automatically to Superset?

Metabase exports content with serialization, which writes YAML files, but that feature is available only on the Pro and Enterprise plans, both self-hosted and on Metabase Cloud. If you are on Open Source or Starter, check which export methods your plan allows before you plan the work. Even with a full export, the YAML describes Metabase objects, not Superset datasets, charts and roles, so someone must map each question and model to a Superset dataset or chart and rebuild it. Superset's own ZIP export and import moves assets between Superset instances, not from Metabase. Confirm with any provider which Metabase content types can be exported on your plan, what a sample export contains, and how each object will be mapped. Test the mapping on a few dashboards before estimating the full inventory. The Metabase serialization documentation describes the exported format.

What happens to dashboards embedded in our product?

Embedded dashboards need their own migration track, because the embedding code, authentication flow and URLs are tied to Metabase. Read the Metabase embedding introduction to confirm which embedding approach your product uses, then list every embedded view and how users reach it. Superset has its own embedding approach, which must be confirmed against the version you deploy, including how user identity is passed to Superset and how tenant data is isolated. The main drivers are the number of embedded views, the authentication model in your host application, the isolation requirements for each customer, and whether end users see Metabase branding. Plan to build the Superset embeds in staging, switch them over one page at a time, and keep Metabase running until each embedded view is verified. Ask for the embed inventory and the authentication flow in the written scope.

Will our Metabase permissions and row level security carry over to Superset?

No, permissions must be redesigned for Superset rather than copied across. Metabase's row and column level permissions, SSO and multi-tenant segregation are included only in its Pro and Enterprise plans, so the access rules you have today depend on your plan. In Superset, access is defined through roles and row level security, and group membership from LDAP or OAuth providers can be mapped to roles with AUTH_ROLES_MAPPING. The drivers are the number of groups, the number of existing row-level rules, the number of data sources each group reads, and whether group sync from your directory is required. Ask for a matrix that maps each Metabase group to Superset roles, the data each role may read, and the test cases that prove a user in one group cannot see another group's rows. Have your security team approve that matrix before any dashboards are rebuilt.

How DeployOpen scopes, delivers and supports a Metabase to Superset migration

DeployOpen works on Migrate from Metabase to Apache Superset as a fixed-scope engagement, with scope, deliverables and timelines agreed in writing before work starts. We plan, build, test and document the move inside infrastructure you control, then hand it over to your team, with ongoing support available as a retainer.

How we scope

We inventory your Metabase questions, models, dashboards, groups and embedded content before agreeing a written scope.
The written scope names which assets move, which are rebuilt as Superset datasets and charts, and which are retired.
We confirm your Metabase edition and plan, since serialization and SSO depend on it, and record that in the scope.
We agree the Superset deployment target, metadata database and parallel-run period as scope items, with a quote following from them.

How we build

We stand up a Superset deployment in your environment and map Metabase groups to Superset roles and row level security rules.
We rebuild priority dashboards as datasets and charts, checking each against the figures your Metabase dashboards show.
We configure database connections and access controls so Superset queries run under the permissions your data team has approved.
We test authentication, role assignments and embedded views in staging before any user sees the new platform.

How we hand over

We deliver a written mapping of every Metabase asset to its Superset equivalent, with the items that were not carried across listed.
We document the parallel-run results, open differences and the cutover steps your team needs to repeat or audit.
We walk your administrators through roles, datasets, upgrade steps and the backup routine for the Superset metadata database.
We hand over configuration and runbooks so your team can operate Superset without depending on us for daily work.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover, scoped in writing.
Retainer support can cover Superset upgrades, which we run with a metadata database backup and a staging test first.
We can retest role and row level security rules when your data sources, groups or access policies change.
Support scope, response expectations and fees are confirmed in the written agreement, and we do not publish a price list.