Apache Superset migration from another BI tool

What a Superset migration involves

Superset does not import proprietary workbooks from Tableau, Power BI, Looker or Metabase, so every dashboard, metric and user permission has to be rebuilt as a Superset dataset, chart and dashboard on top of the analytics databases you already run. The old tool's files are an inventory source, not a migration input. Plan the work as a rebuild with a source-to-target map, and expect the rebuild to be the largest share of effort. The usual triggers are a licence renewal that no longer fits the budget, rising per-user cost, data residency rules that prevent analytics queries from leaving your infrastructure, and a decision to run analytics on infrastructure your team controls. Name the trigger early, because it sets the priorities: a residency driver puts hosting and access control first, while a cost driver puts the rebuild backlog and retirement date first.

Apache Superset is licensed under Apache-2.0 and has no paid edition, so the migration cost is not a software fee. It sits in people, infrastructure and rebuilding work: the metadata database, cache and worker hosts, staff time for dataset modeling and chart rebuilds, and parallel running while both tools stay live. Ask any partner to separate these lines in a quote, and ask which of them recur after go-live. In-house or partner work depends on three things: how many dashboards and data sources are in scope, how many distinct source databases need credentials and network paths, and how complex the current access model is, including row-level restrictions and group-based permissions. A small estate with one warehouse and simple roles is often a reasonable in-house task. A large estate with many sources and layered access is where a fixed-scope partner engagement with a written inventory usually pays off.

What the work includes

The migration runs as a sequence of work packages, each tied to a specific asset type in the source tool. The list below shows what a fixed-scope engagement covers and what the client receives at the end.

Asset inventory across the source tool

Every dashboard, chart, dataset, saved query, scheduled report, alert, user, group and data connection in the current tool is catalogued with its owner, usage and dependencies. This inventory decides what is rebuilt, what is retired and what is left out of scope. Confirm with the client which assets are actually used, since unused content often makes up a large share of an old BI estate.

Superset platform setup

The Superset application is installed in the client's infrastructure with a PostgreSQL or MySQL metadata database, supported versions per the configuration documentation, and not the SQLite default. Alerts, reports, async queries and thumbnails need the caching layer and Celery workers, so those components are sized and deployed alongside the web application. Confirm which database and cache services the client already operates.

Dataset and semantic rebuilds

Connections, physical tables, virtual datasets, calculated columns and metrics from the source tool are recreated as Superset datasets. Business logic embedded in Tableau calculations, Power BI measures, Looker LookML or Metabase questions often needs to be rewritten as SQL and checked against the source results. Ask who owns metric definitions before the rebuild starts.

Chart and dashboard rebuilds

Charts and dashboards are rebuilt on the new datasets, usually with the same filters, drill paths and layout that users rely on. Visual parity is rarely exact, so the acceptance criteria should name the numbers and filters that must match, not the pixels. Plan for rebuilds to be reviewed by the business owner of each dashboard.

Role and permission mapping

Permissions from the source tool are translated into a Superset role model, including dataset access and any row-level security rules. Groups from the client's identity provider are mapped to Superset roles so access follows existing approvals. Review each source permission for exceptions that a simple group mapping would widen.

User onboarding through the identity provider

Users sign in through the client's identity provider using the agreed OAuth2, OIDC or LDAP integration, rather than local accounts created by hand. Account creation, deactivation and group membership changes are tested with real test users before any wider rollout. Confirm how leavers and contractors are removed in the source tool today.

Parallel running

Old and new dashboards run side by side for an agreed period while users compare results and report differences. Discrepancies are logged against the validation records and resolved before the team moves on. Agree the exit criteria for parallel running in writing before it begins.

Cutover and decommissioning of the old tool

Users, scheduled reports and alerts are moved to Superset in a planned cutover, and the old tool is switched to read-only and then retired. Decommissioning covers subscriptions, connections, stored credentials and data exports that the old tool still holds. Confirm retention obligations for old dashboards and logs before shutdown.

Deliverables at handover

The client receives an inventory register, a rebuilt asset catalog, the role model, validation records, a runbook and a handover session. These documents let the client's team operate, audit and extend the Superset estate after the engagement. Agree the format and acceptance process for each deliverable in the written scope.

What drives cost and duration

The table lists the factors that change how much work a Superset migration from another BI tool requires, why each one matters and how to keep it under control; effort itself is set in the written scope rather than estimated here.

Driver	Why it matters	How to reduce it
Number of dashboards and charts	Each dashboard must be rebuilt, reviewed and checked against the old numbers, so inventory volume sets most of the build effort.	Retire unused content before migration, consolidate near-duplicate dashboards and migrate in waves by business area.
Number and type of source databases	Each connection needs credentials, network paths, drivers and a decision on how Superset queries it, which multiplies testing.	Group sources by platform, migrate one database family at a time and confirm drivers and network access early.
Complexity of calculated fields and metrics	Calculations defined inside the old tool, such as Tableau calculated fields or Power BI DAX measures, must be rewritten as SQL in datasets or metrics.	Move logic into governed views or dbt models where possible, and sort metrics into simple, moderate and complex groups in the inventory.
Row-level and group-based access rules	Security filters in the old tool must be reproduced as Superset row-level security rules and role grants, and gaps here are high risk.	Document each rule as a written policy first, then map it to roles and RLS clauses and test with sample users from each group.
Scheduled reports and alerts tied to the old tool	Subscriptions, email schedules and threshold alerts depend on the old tool's scheduler and recipients, and each one needs a replacement and a parallel check.	List every schedule with owner and recipients, then recreate the highest-value ones first and retire the rest with sign-off.
Number of users and groups	Each group needs a role mapping and a test pass, and large or nested group structures lengthen access design.	Reduce group sprawl before migration and map groups to a small set of Superset roles using the identity provider.
Identity integration	Single sign-on, group claims and provisioning rules decide whether access follows the directory or needs manual upkeep.	Settle the identity provider design before building roles, and confirm which group attributes the provider passes to Superset.
Number of environments	Development, staging and production each need their own content and copies of data connections, and content must be promoted consistently.	Agree one promotion method, keep the number of environments to what the team needs and version exported assets.
Compliance evidence needed	Auditors may ask for access reviews, change records and proof that migrated controls match the old ones, which adds documentation work.	Agree the evidence list at scoping, such as access matrices and parallel-run comparisons, and capture it during the work rather than afterward.
Whether the old tool's content can be exported in usable form	Some tools export dashboards and metadata in formats that are easy to read, while others only provide images or proprietary files, which forces manual rebuilding.	Test exports on a sample of content early, confirm what the old tool's license and export settings allow, and plan manual rebuilding for anything that cannot be exported.

Migration phases and outputs

The sequence moves dashboards, users and permissions from the old tool to Superset in checked stages, so each phase closes with evidence before the next one starts.

Inventory the existing BI estate
Your team and DeployOpen catalog every dashboard, report, dataset, scheduled delivery, data source connection and user group in the current tool, and record which ones people actually use. The output is a signed-off inventory with owners, usage notes and a retire, rebuild or merge decision for each item.
Build the target Superset platform
DeployOpen deploys Superset in your infrastructure with a PostgreSQL or MySQL metadata database, the caching layer and Celery workers where alerts, reports or async queries are needed, and HTTPS and SSO configured. The step closes when a staging environment passes login, query, cache and scheduled-report tests and the secret key is stored under your control.
Pilot a representative set of dashboards
Rebuild a small set of dashboards that covers the main data sources, chart types, filters and audiences in the inventory. The pilot output is a documented pattern for datasets, metrics and charts, plus a list of gaps where the old tool's behavior does not map directly.
Rebuild the remaining content by domain
Work through the inventory one business domain at a time, reusing the pilot patterns for datasets, shared metrics and naming. Each domain closes when its owner reviews the rebuilt dashboards against the inventory entry and signs off on the content.
Map permissions and validate results
Translate the old tool's groups, row-level restrictions and sharing rules into Superset roles, groups mapped through AUTH_ROLES_MAPPING and row-level security rules. The check is a documented permission matrix tested with sample accounts, and key figures compared between the old and new tools for the same filters and dates.
Run both tools in parallel
Users work in both tools for an agreed period while automated and manual reconciliation checks compare totals, row counts and key metrics. The step closes when the agreed checks pass, and any differences have a recorded cause and an owner.
Cut over and retire the old tool
Point users, bookmarks, embeds and scheduled deliveries to Superset, then make the old tool read-only. Before shutdown, export and store the content, metadata and usage logs your retention policy requires. The output is a cutover record, a verified archive and a documented retirement date set in the written scope.

What teams keep and what they outsource

This table compares who usually does each part of a Superset migration from another BI tool, the skills each part needs, and whether it stays in-house or goes to a partner, so you can divide the work before a quote is written.

Work part	Usually in-house or outsourced	Skills needed
Business owners validating metrics	In-house. Owners sign off on every metric definition because rebuilt numbers must match the old reports before anyone trusts them	Knowledge of how each KPI is calculated today, including filters, exclusions and fiscal calendars
Data engineers modeling datasets	Often shared. Your engineers own source data and business logic, and a partner can translate them into Superset datasets and virtual metrics	SQL, the source databases, dbt or warehouse conventions, and the old BI tool's semantic layer
Platform engineers running Superset infrastructure	Usually in-house after handover. A partner can build the deployment, but your team must operate the database, cache, workers and upgrades	Linux, containers or Kubernetes, PostgreSQL or MySQL administration, Redis and Celery, and monitoring
Identity administrators	In-house. Group membership and role mapping come from your directory, and only your administrators can approve access	Your identity provider, OAuth2 or LDAP group design, and AUTH_ROLES_MAPPING configuration
Security reviewers	In-house sign-off with partner support. Reviewers approve role design, data source credentials and SQL Lab exposure before users move	Least-privilege access design, row-level security, secrets handling and review of audit evidence
Rebuild of charts and dashboards	Often outsourced in batches. A partner can rebuild the inventory in priority order while owners check each output	Superset chart types, dashboard layout, filter behavior and familiarity with the source tool's visuals

What usually goes wrong

Most migration problems are not technical failures in Superset itself. They come from decisions made during the move that nobody checked against the old tool, and from retiring the old tool before anyone confirmed the results.

Metric definitions drift from the old tool

Teams often rebuild a revenue or active-user metric in Superset from memory of the old dashboard, and the two tools then return different totals for the same period. Before cutover, pick the reference metrics, compare them side by side on the same date ranges and filters, and record every difference with an owner who signs it off.

Undocumented calculated fields and filters

Calculated columns, hidden filters and default time ranges often lived inside the old tool with no written record, so they disappear during rebuilding. Inventory each one from the source workbooks or models, classify it as needed or obsolete, and rebuild it in a dataset with a description that states its logic and source table.

Permissions flattened into broad roles

Mapping every old group to Superset's Admin, Alpha or Gamma roles is faster but gives people access they never had. Compare the old per-workspace, per-folder and per-data-source grants with the planned Superset roles, and use dataset-level permissions and row-level security where the old tool restricted rows.

Scheduled reports and alerts forgotten

Subscriptions, email schedules and threshold alerts often run from the old tool and go unnoticed until someone asks where a report went. Export the schedule list from the old tool, recreate each one in Superset's alerts and reports feature, and confirm the recipients receive a test delivery. Note that these features depend on the caching layer and Celery workers.

SQL Lab exposing more than before

Opening SQL Lab to every analyst gives people direct query access to databases they previously reached only through curated dashboards. Compare each user's old data access with their Superset database connections and SQL Lab permissions, and restrict or disable SQL Lab for roles that never had direct query access.

Metadata database on SQLite or a test container

Quickstart and PyPI installs default to SQLite, and the Docker Compose PostgreSQL container is not recommended for production. A migration that stores dashboards, users and permissions in either will be hard to move later. Run the metadata database on PostgreSQL or MySQL in a supported version, with backups and a restore test before users arrive.

Retiring the old tool before verification

Switching off the old tool once the new dashboards are published removes the only reference for disputed numbers. Keep both running in parallel for a period agreed in advance, collect user sign-off by dashboard and by role, and retire the old tool only after every open difference is closed and signed off in writing.

How the work differs by starting point

Tableau and Power BI teams usually carry over the business questions, KPI definitions and dashboard purpose, but not the calculation engine or file formats. Plan for a rebuild of the logic and a fresh review of every chart.

Carries over: dashboard purpose, audience, filter logic and the list of metrics the business relies on.
Rebuilt by hand: data sources become database connections and datasets, and calculated fields or DAX measures become SQL expressions.
Rebuilt by hand: extracts and published data sources are replaced by live queries or scheduled cache refreshes, which changes performance and data freshness.
Check during rebuild: visual types, drill paths and parameters do not map one to one, so each chart needs a side-by-side comparison with the original.
Access: workbook and workspace permissions are remapped to Superset roles from your identity groups.

What the client needs to provide

Most delays in a Superset migration come from inputs the client was expected to supply and did not. Before work starts, the client should provide read access to the source tool's dashboards, datasets, saved queries, and its permission settings, including the groups, workspaces, and row-level rules that exist there. Without an export or read-only login for each, the team cannot inventory what must be rebuilt or map who should see what.

Each data source also needs a database credential or service account that Superset can use, scoped to the schemas the migrated content reads. Ask for separate accounts per source and environment, and confirm with the data owners whether the old tool used shared logins that will need to be replaced. Identity provider access is equally important: whoever administers the IdP should be available to configure OAuth2 or LDAP sign-in and to confirm which groups will map to Superset roles through AUTH_ROLES_MAPPING.

The client should name a business owner for each domain, such as finance, sales, or operations, who signs off that rebuilt metrics match the old numbers. Hosting must also be decided in advance: a PostgreSQL or MySQL metadata database in a supported version, a cache layer, Celery workers, and a staging environment that mirrors production closely enough to test upgrades and migrated content. Settle the target Superset version as well. Pre-release builds such as 7.0.0rc2 should not be used for production cutover unless both parties agree to it in writing.

Frequently asked questions

What drives the cost and timeline of a Superset migration?

Cost and duration follow the written scope, and DeployOpen does not publish a price list. The main drivers are the number of dashboards, datasets and charts to rebuild, the number of data sources and calculated fields to translate, the complexity of the permission model, and how many scheduled reports must be recreated. Parallel running and business validation add time. Platform costs for the metadata database, cache, workers and hosting are separate and recur in your infrastructure. Ask for a quote that splits one-time migration work from recurring run costs, with phases, milestones and a clear list of what is in and out of scope.

Can Superset import Tableau or Power BI files directly?

Plan on rebuilding most content in Superset, and confirm during discovery whether any export from your source tool can be loaded and how much would carry over. Tableau and Power BI files use proprietary formats, so calculations, layouts and filter logic usually need to be recreated against the underlying databases. A practical discovery step is to rebuild one representative dashboard from each source tool, record what translates and what needs manual work, and base the rebuild estimate on that result.

How do Tableau or Power BI permissions map to Superset roles?

Permissions map through a role model designed during planning, with groups from your identity provider assigned to Superset roles. Superset can map LDAP or OAuth groups to roles through AUTH_ROLES_MAPPING, so the old tool's site, workspace and group memberships should be inventoried first. Row-level security rules, dataset access and database connection permissions usually need separate mapping and testing because they do not carry over one to one. Confirm during discovery which old permissions apply at the dataset level and which apply at the workbook or report level.

Can scheduled reports and alerts move from the old BI tool?

Yes, but Superset recreates them rather than importing them, and they depend on infrastructure you must run first. Superset's alerts and reports need the caching layer and Celery worker components, and most installations back them with Redis and Celery. Each schedule, recipient list, file format and threshold is rebuilt individually, so the inventory should list every schedule and its owner. During the validation window, run old and new schedules side by side to catch missed or duplicate deliveries before the old schedules are turned off.

Can our internal team run a Tableau or Power BI migration alone?

An internal team can often run the migration alone if it has Superset operations skills, database and identity provider access, and time for inventory and validation. Most of the effort is inventory, rebuilding datasets and charts, and checking results with business owners. Gaps usually appear in metadata database operations, caching and workers, and role design. Clients typically provide the source tool inventory and admin access, database connection details, identity provider access, named business reviewers and one sign-off owner. Confirm these inputs during discovery.

What happens to data and content in the old tool after cutover?

Source databases stay where they are, because Superset queries them directly, so the migration moves dashboard definitions and access rules rather than warehouse data. Extracts, published data sources and embedded content in the old tool need an explicit decision: export, archive or delete. Retirement should follow a written plan covering export format, archive location, retention period and the person who approves shutdown. Confirm the old vendor's export options and license terms before setting the shutdown date. After go-live, Superset upgrades and support are a separate scope that you agree in writing.

How DeployOpen delivers Superset migrations

DeployOpen plans and runs Apache Superset migrations from Tableau, Power BI, Looker or Metabase inside infrastructure you control, with each phase agreed in writing before work starts. The work moves dashboards, datasets, users and permissions in stages so your teams can compare results before the old tool is retired.

How we scope

The written scope lists the source tools, dashboards, datasets and user groups covered by the migration.
Scope names the target metadata database, cache and worker components and the data sources Superset will query.
Engagements are fixed-scope, so deliverables, timelines and exclusions are agreed in writing before build starts.

How we build

We inventory existing dashboards and usage, then rebuild datasets and charts in Superset with documented definitions.
We map source permissions to Superset roles and test access for each group before any user is moved.
Parallel running is planned with reconciliation checks comparing key figures between the old tool and Superset.

How we hand over

You receive a documented inventory, rebuilt asset register, role model and the configuration used in each environment.
Runbooks cover backups of the metadata database, staging-first upgrades and the steps for retiring the old tool.
Your team is walked through the parallel-run results and the decisions that were made about retired or merged dashboards.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after go-live.
A retainer can cover Superset version upgrades, reviewing UPDATING.md for breaking changes and staging tests before production.
Confirm with us in writing what response and coverage terms a retainer includes before signing.