Migrating from Power BI to Apache Superset starts with the semantic model
A Power BI to Apache Superset migration is a rebuild of the semantic layer and the data preparation behind it, not a file conversion. A .pbix file cannot be opened in Superset, and the DAX measures, calculated columns, relationships and Power Query steps inside it have no direct equivalent. The usual trigger is a renewal, a change in Power BI licensing, a data residency rule or a wish to stop depending on one vendor's identity and capacity model. Whatever the trigger, the reader's first decision is whether the business logic in each model is worth rebuilding in SQL, and that decision sets the size of the project. Internal BI developers and data engineers usually own the work, with identity and platform engineers handling sign-in and hosting. An implementation partner can take on the rebuild or the Superset deployment, but the people who know the business definitions must stay involved.
Effort and risk depend mostly on two things: how complex the semantic models are and how many reports depend on them. A model with a few tables and simple sums is a short exercise, while a model with time intelligence, many-to-many relationships or row-level security needs careful translation and testing against numbers the business already trusts. Before any build, inventory each model and each report, record which measures are used and by whom, and confirm which downloads are possible. Microsoft lists limits on downloading reports and semantic models with data, including Direct Lake models, models with incremental refresh and models larger than 50 GB, so some sources may need to be rebuilt from their upstream databases. The Superset platform itself is licensed under Apache-2.0 and has no paid edition, so the recurring cost sits in infrastructure, maintenance and the people who run it, not in a per-user license. Ask the implementation partner to quote each of those components separately against your written scope.
Which Power BI capabilities map to Superset and which need rework
This table compares Power BI features with their Apache Superset equivalents and marks each row as clean, needs rework or gap. Superset has no DAX engine, so measures with time intelligence or context-sensitive logic must be rewritten as SQL metrics or confirmed in a pilot before you retire a report. Use the rework rows to size the migration effort.
| Power BI capability | Apache Superset equivalent | Status | Notes for migration |
|---|---|---|---|
| Reports and dashboards | Charts and dashboards | Needs rework | Visuals are rebuilt in Superset; layout and chart types rarely copy one to one, so plan a visual check per report. |
| Semantic models (datasets) | SQL datasets on a database connection | Needs rework | Superset queries your database directly, so the model's relationships must exist as SQL joins or as a governed view. |
| DAX measures | SQL metrics on Superset datasets | Gap | Superset has no DAX engine. Simple aggregates translate to SQL; complex time intelligence must be rewritten as SQL or confirmed in a pilot. |
| Power Query transformations | Upstream SQL, views or dbt models | Needs rework | Transform steps move into the database layer before Superset reads them. Each applied step needs an equivalent query or model. |
| Row-level security | Database-level or Superset row-level security rules | Needs rework | Rules must be re-created and tested per role; confirm that the database policy and Superset rule produce the same result. |
| Scheduled refresh and alerts | Alerts and reports with Celery workers and Redis caching | Needs rework | Alerts, reports and async queries need the caching layer and worker components running and monitored. |
| Subscriptions and email delivery | Alerts and reports via scheduled delivery | Needs rework | Recipient lists and schedules must be recreated; confirm delivery channels against your mail setup. |
| Entra ID sign-in | OAuth2 with Azure provider or LDAP | Needs rework | Superset supports OAuth2 providers and LDAP; map groups to roles with AUTH_ROLES_MAPPING and test sign-in in staging. |
| Embedding in external apps | Embedded SDK with guest tokens | Gap | Embedded use needs tenant isolation rebuilt in your application; confirm guest token and RLS behavior in a pilot. |
What data and integrations move, and through which documented paths
A Power BI move splits into four parallel streams: report and model definitions, model metadata, the source databases Superset must reach, and the identity model that decides who sees what. Each stream has a different documented path, a different set of blocks and a different owner on the client side, so plan them separately and confirm each one before the cutover date is set.
Report and model definitions
Workspace Contributors can download reports and semantic models as .pbix files from the Power BI service, and this is the starting inventory for every visual, page and measure. The export does not carry everything: Direct Lake models, models with incremental refresh and models over 50 GB cannot be downloaded with their data. Check each workspace for those three cases before planning, because a blocked model means its logic must be rebuilt from documentation and source queries rather than copied.
Model metadata through XMLA
Where the tenant allows it, the XMLA endpoint can expose semantic model metadata, including tables, columns, relationships and measure definitions, which is more complete than reading a .pbix by hand. Access depends on tenant settings and workspace capacity, so confirm with Microsoft and your tenant administrator whether the endpoint is enabled and who may query it. Measures still have to be translated to SQL metrics on Superset datasets; the endpoint gives you the source text, not a working Superset model.
Source database connections
Superset reaches each source through a Python DB-API driver and a SQLAlchemy dialect, so every warehouse or database behind a Power BI model needs a driver installed in the Superset image and a tested connection string. Power Query steps that reshaped data inside Power BI will not run in Superset and must move upstream into SQL views, dbt models or pipelines. Confirm each source has a supported driver and that its service account has read access before any dataset is created.
Identity and group mappings
Microsoft Entra ID groups and workspace roles currently decide who sees which reports, and those assignments do not transfer automatically. Superset supports OAuth2 providers such as Azure, LDAP, and mapping of LDAP or OAuth groups to roles with AUTH_ROLES_MAPPING, so you can rebuild the role structure from the existing group list. Row-level security rules also need to be written again as Superset rules and tested with real accounts. Confirm with your identity team which groups map to which Superset roles before pilot users are onboarded.
How DAX measures become SQL metrics on Superset datasets
Start by inventorying every DAX measure and calculated column in the semantic model, then classify each one. A plain aggregation such as SUM or COUNT over a single table maps directly to a Superset metric. A filtered aggregation (CALCULATE with filter arguments) usually becomes a SQL CASE expression inside the metric or a filtered view. Time-intelligence calculations such as year-to-date or prior-period comparisons need a date dimension in the database and an explicit date logic in SQL, because Superset does not reproduce DAX time functions. Context-dependent calculations, where the result depends on the filters applied in a visual, are the hardest class. They need to be rewritten as explicit grain-level SQL or split into several metrics so the same result holds under Superset's filter behavior. Record each measure with its class, its source tables and the report pages that use it, so the inventory doubles as a test plan.
Once classified, move the logic to where it can be versioned and tested. Plain and filtered aggregations can live in the Superset dataset as metric definitions, but anything reused across dashboards is better placed in a database view or a dbt model so that every dataset reads the same definition. Power Query steps should move upstream into SQL, dbt or a pipeline before the dataset is built, so that the Superset dataset exposes clean, typed tables rather than the transformation logic of the original .pbix. Confirm with your data team which tool owns each transformation, because a metric defined in two places will drift.
Reconciliation against the original report is the acceptance test. For each measure, compare totals and a sample of filtered slices between the Power BI visual and the Superset chart on the same date range, filters and grain, and investigate every difference before retiring the source report. Expect differences around nulls, distinct counts, time zones and rounding, and document each accepted variance with its cause. Ask the team that owns the model to sign off on the reconciliation results, not only the Superset developer who built them.
Moving sign-in from Microsoft Entra ID to OAuth or LDAP
Superset is built on Flask-AppBuilder, which supports OAuth2 providers such as Google and Azure, as well as custom OAuth2 servers that use the code flow. For a team leaving Microsoft Entra ID sign-in for Power BI, the Azure option is the closest path, because the same tenant can usually issue the tokens Superset needs. Configure an app registration with a redirect URI pointing at your Superset host, then set the provider details in superset_config.py.
- Provider configuration: Set
AUTH_TYPEto OAuth and define the Azure provider inOAUTH_PROVIDERS, with the client ID, client secret and tenant-specific endpoints kept out of source control. - Group mapping: Use
AUTH_ROLES_MAPPINGto map Entra group identifiers to Superset roles such as Admin, Alpha or Gamma, so role changes follow directory group membership. - Role sync: Set
AUTH_USER_REGISTRATIONandAUTH_ROLE_ADMINdeliberately, since first-time sign-in creates the local user record. - SECRET_KEY: Superset requires a user-specified
SECRET_KEYto start, and you can rotate it later withPREVIOUS_SECRET_KEY. Store it in your secrets manager, not in the config file. - Parallel test: Confirm that a sample of users in each Entra group lands in the expected role, that removing a user from a group revokes access on next sign-in, and that dataset-level permissions still hold.
Confirm the exact provider keys and claim names against the Superset configuration documentation for your release before you deploy.
LDAP suits organizations whose users and groups already live in an Active Directory or another LDAP directory and whose policy requires that directory to remain the source of truth. Superset supports LDAP authentication through Flask-AppBuilder, so the work is mainly in connection settings, search filters and the group-to-role map. Plan the directory service account and TLS setup with the directory team before writing configuration.
- Connection settings: Set
AUTH_TYPEto LDAP and define the server URI, bind account and search base insuperset_config.py, using LDAPS or StartTLS for encrypted transport. - Group mapping: Use
AUTH_ROLES_MAPPINGto translate directory groups into Superset roles, and keep the mapping in version control so changes are reviewed. - User migration: Users are created on first successful LDAP sign-in, so the migration is mostly about role assignments and ownership of existing dashboards, not about copying password data.
- Nested groups: Confirm with the directory team whether groups are nested, because the search filter must return the groups a user actually belongs to.
- Parallel test: Sign in with accounts from each group, test a disabled account, and confirm that lockout and password policy follow the directory, not Superset.
Verify the LDAP option names and behavior for your Superset version in the configuration documentation before cutover.
For a small team with a handful of analysts, database authentication is the simplest option. Superset stores users, roles and password hashes in its metadata database, which in production should be PostgreSQL or MySQL rather than the SQLite default. This avoids an identity integration, but it also moves account lifecycle work onto your administrators, so it is a poor fit if many people join and leave.
- Account creation: Create users with the Superset command line tools or the admin interface, and assign built-in roles that match the Power BI workspace roles you are replacing.
- Role migration: Export a list of Power BI workspace Contributors and Viewers from the Power BI admin side, then map each person to a Superset role by hand.
- Password and access policy: Decide how passwords are set, reset and retired, and document who can create accounts, since no directory enforces it for you.
- SECRET_KEY: The same startup requirement applies, so the key must be set before the first start in every environment.
- Parallel test: Confirm each migrated account can sign in, that a departed user's account is disabled, and that role-based dataset access matches the earlier Power BI access list.
Ask your security team whether database accounts meet your access review requirements before you choose this path.
The migration sequence from inventory to decommission
This sequence moves Power BI content to Apache Superset in controlled stages, so each report is inventoried, proven against the source numbers, and cut over with access checked before any Power BI license or capacity is released. Each stage ends with a signed record that the next stage depends on.
Inventory workspaces, datasets, reports and consumers
Run a full inventory of every Power BI workspace, semantic model, report, dataset refresh schedule, subscription and alert, and list who views each one through apps, sharing or security groups. Record which items can be downloaded as .pbix files with data and which are blocked by limits such as Direct Lake, incremental refresh or models over 50 GB, since those need a different extraction path through the XMLA endpoint. The output is a signed inventory with one row per item, its owner, its consumers and its extraction method. The BI lead and the data owner for each workspace sign it off, and the Power BI admin confirms the export was complete.
Pilot one domain with representative DAX
Choose one business domain whose reports include typical DAX measures, such as time intelligence, filter context and row-level security, and one identity path, such as a single OAuth provider or LDAP group. Rebuild its measures as SQL metrics on Superset datasets, and move the upstream Power Query steps into SQL views or the data pipeline that feeds the database. The output is a pilot report set with a list of every DAX pattern that did not translate cleanly and how it was handled. The domain's data owner and the Superset administrator sign off, and the security team confirms the sign-in path works for the pilot group.
Reconcile numbers in a parallel run
Keep Power BI and Superset running side by side for the agreed reports and compare outputs for the same filters, date ranges and audiences. Investigate every difference, which often traces to null handling, rounding, time zones or measure context, and fix either the SQL metric or the source model with a documented reason. The output is a reconciliation report that lists each agreed report, the tested filter sets, the variances found and their resolution. Finance or the business metric owner signs the report, and the BI lead confirms that no open variances remain on agreed reports.
Cut over by audience with access verified
Move consumers in groups by audience, starting with the pilot domain, and move the subscriptions and alerts that belong to each group. Before each group switches, check that its sign-in works through the chosen OAuth or LDAP configuration, that AUTH_ROLES_MAPPING assigns the expected Superset roles, and that dataset and row-level permissions match the access the group had in Power BI. The output is a cutover checklist per audience, with the access test results and a list of users who could not sign in and how they were resolved. The application owner and the identity team sign off each group before the next one moves.
Retire Power BI licenses and capacity
After the final audience has moved and the retention period set by your records policy has passed, remove the remaining Power BI content, disable scheduled refreshes, and withdraw Pro or Premium Per User licenses and any Premium or Fabric capacity that no longer serves a workload. Keep the exported .pbix files and the inventory in archive storage so the reports can be reviewed later. The output is a decommission record listing each license or capacity removed, the date of removal and where the archive is held. The IT asset owner and the finance approver for licensing sign off, and the vendor contract or subscription is confirmed as not renewing.
What drives cost and duration, and how to keep each one down
This table lists the factors that move effort and cost in a Power BI to Superset migration, why each one matters, and how to reduce it. Read it as a checklist: the rows at the top set the size of the inventory, and the rows below set how much rebuilding each report will need. Ask every vendor or partner to price each row explicitly in the written scope.
| Driver | Why it moves effort | How to keep it down | What to ask for in a quote |
|---|---|---|---|
| Number of reports and semantic models | Each model needs its tables, relationships and measures recreated as Superset datasets and metrics, and each report needs its charts rebuilt. | Retire unused reports first, merge duplicates, and count .pbix files and workspaces before estimating. | An inventory-based count of models and reports, with the retire, merge and rebuild split stated. |
| DAX complexity | Time intelligence, context transition, iterators and calculation groups have no direct SQL metric equivalent and need case-by-case rewrites and testing. | Classify measures into simple aggregations, time comparisons and complex logic, and move logic into SQL views where it is easier to test. | A per-measure classification and the test method used to confirm results match the Power BI values. |
| Power Query depth | Transformations in Power Query must be re-expressed upstream in SQL, dbt or a pipeline, and each step needs validation against the source. | Move transformations into the database or a modeling layer once, instead of repeating them in each dashboard. | Which Power Query steps move upstream, who builds them, and how row counts are reconciled. |
| Data source count and type | Each connector needs a working SQLAlchemy dialect and Python DB-API driver, and each source needs its own credentials and network path. | Consolidate sources into a warehouse or PostgreSQL where feasible, and confirm driver support early for uncommon sources. | A connector-by-connector list confirming driver availability and the credential and network changes for each. |
| Row-level security rules | Power BI RLS rules defined in DAX must be rewritten as Superset row-level security filters and tested per consumer group. | Document the RLS matrix before the build and keep rules in the database where possible. | The number of RLS rules, the test cases to be run, and who signs off on access results. |
| Distinct consumer groups | Each group needs a role mapping, dashboard permissions and sometimes a separate dataset scope, which multiplies test effort. | Map Power BI workspace roles to a small set of Superset roles before migration. | How many roles are proposed and how group-to-role mapping is handled. |
| Identity model | Moving sign-in from Microsoft Entra ID to OAuth or LDAP requires app registrations, group claims, AUTH_ROLES_MAPPING and login testing. | Use one OAuth2 provider or LDAP directory that already holds the group structure, and test role mapping before cutover. | Which identity provider is used, how groups map to roles, and the test plan for sign-in and role assignment. |
| Alerts and scheduled delivery | Alerts, reports and thumbnails need the caching layer and Celery workers, and each schedule must be recreated and checked. | Limit scheduled deliveries to those people still use, and size the Redis and worker components to that set. | The number of schedules to rebuild and the Redis and Celery components included in the scope. |
| Embedding | Embedded reports need the Superset embedded SDK, guest tokens and tenant isolation rules, which are separate work from internal dashboards. | Keep embedded use cases to a short list and treat them as their own phase. | Whether embedded reports are in scope, and how guest token and tenant rules are tested. |
| Hosting and upgrade approach | The Helm chart is marked deprecated in current development docs in favor of the Apache Superset Kubernetes Operator, so a Helm-based build may need rework. Upgrades also require backup, superset db upgrade, staging tests and UPDATING.md review. | Confirm the deployment method against the current docs before building, and plan a recurring upgrade window. | Which deployment method is used (Kubernetes Operator or other), who owns upgrades, and how staging tests are run. |
What usually goes wrong in a Power BI to Superset move
Most failed migrations break in the same few places: the logic that moves from DAX into SQL, the artifacts Power BI will not export, the sign-in cutover, the metadata database, and upgrades. Each card below names one of these risks and the checks that prevent it. Work through them before the first consumer is switched over.
Totals that do not reconcile
DAX measures evaluate in filter context, so a total on a Power BI card can differ from the sum of the rows beneath it. When a measure such as a ratio or a distinct count is rewritten as a plain SQL aggregate on a Superset dataset, the totals often drift from the original report. Choose a set of reference figures for each report, including subtotals and filtered views, and reproduce them in Superset before any consumer switches. Ask the team that owns the model to document every measure that uses CALCULATE, time intelligence or relationship-dependent logic.
Blocked .pbix downloads
Microsoft's download limits decide what can be extracted from the Power BI service. Direct Lake models, models with incremental refresh and data models larger than 50 GB cannot be downloaded with their data, so a straightforward export is not available for them. Inventory every semantic model before planning the move, mark which ones fall into these categories, and plan a rebuild from the source database for those. Confirm the Contributor role on each workspace, because only Contributors can download.
Identity cutover that locks people out
Power BI users sign in through Microsoft Entra ID, and group membership usually controls report access. If Superset is switched to OAuth or LDAP without the group mappings carried over, consumers can sign in but see no dashboards, or lose access to the datasets they used. Map each Entra group to a Superset role with AUTH_ROLES_MAPPING and test with a sample account from each group in staging. Keep the old sign-in path available until the mapping is verified, and agree a rollback plan with the identity team.
Production on SQLite or the Compose container
The default SQLite database that comes with Quickstart and PyPI installs is not suitable for production, and the PostgreSQL container in the Docker Compose file is also not recommended for production use. Teams that run the pilot on these defaults and then keep them often discover problems once dashboards, scheduled reports and multiple users arrive. Deploy the metadata database on PostgreSQL or MySQL within a version the configuration docs list as supported, with managed or separately operated backups. Confirm the version with the database team before go-live.
Missing caching and worker tiers
Alerts and reports, async queries and dashboard thumbnails depend on the caching layer and Celery worker and beat processes, not on the web application alone. A migration that copies Power BI scheduled refreshes into Superset without deploying these components will show dashboards that run but never send their subscriptions. List every Power BI subscription and scheduled delivery, map each one to a Superset alert or report, and confirm that Redis and the workers are running and monitored before the cutover.
Upgrades without backup or staging
Superset upgrades run database migrations, so a version change can alter the metadata database in ways that are hard to reverse. Teams that upgrade production directly, skip the backup or do not read UPDATING.md for breaking changes often find dashboards or datasets broken after the change. Take a backup of the metadata database, run the upgrade in staging, run superset db upgrade and superset init, and check UPDATING.md for each version between your current and target release. Repeat the same steps for the production upgrade.
How the move changes by starting point
A small team with a few Pro-licensed workspaces usually has a modest number of reports and semantic models, and most of the work is in rebuilding logic rather than in moving infrastructure. The extraction step is the easiest part: Contributors can download reports and models as .pbix files from the Power BI service, provided the model is not blocked by a limit such as incremental refresh or Direct Lake. The main cost is the rewrite of DAX measures into SQL metrics on Superset datasets.
- Steps that shrink: Export and inventory are quick when the workspace count is small, and the number of dashboards to recreate is limited.
- Steps that grow: Each DAX measure is a manual translation, and the team must confirm that filter context and time intelligence produce the same numbers.
- Decisions that change: Sign-in moves from Microsoft Entra ID to Superset's OAuth or LDAP configuration, which is a small but real task for a team with few administrators.
- Hosting: A single node with a managed PostgreSQL metadata database may be enough, but the team must still plan backups and the SECRET_KEY.
- Ongoing: Pro licensing stops, so the recurring cost becomes hosting and whoever maintains the upgrades.
Before committing, ask a partner or your own analyst to rebuild two of the most-used reports and compare results against the Power BI originals. Confirm the sibling Power BI cost vs self-hosted Apache Superset comparison for your user count before deciding.
A large estate on Premium Per User or Fabric capacity has many workspaces, shared semantic models and scheduled refreshes that other teams depend on. Here the extraction work is larger and needs an inventory first, because some models will be blocked from download with their data, including Direct Lake models, incremental refresh models and models over 50 GB. The migration is less about single reports and more about sequencing, since downstream dashboards depend on shared models.
- Steps that shrink: Shared logic can be consolidated into fewer Superset datasets and metrics, which reduces duplicate DAX.
- Steps that grow: Power Query upstream logic must be moved into the database, dbt or a pipeline, and refresh scheduling must be rebuilt with Celery workers and beat.
- Decisions that change: Hosting moves to high availability, with separate caching and worker components, and the choice between Helm and the Kubernetes Operator becomes important.
- Identity: Group mapping through AUTH_ROLES_MAPPING must replace Entra ID groups that currently control workspace access.
- Ongoing: Upgrades need a staged process: back up the metadata database, run the upgrade commands, and check UPDATING.md before each version change.
For this tab, confirm the Premium or Fabric capacity size you are replacing and the list of blocked models, since these drive both scope and timeline. The Power BI cost vs self-hosted Apache Superset page covers how these costs change as user counts grow.
An organization running Power BI Report Server on-premises usually does so for data residency or because reports must stay inside its network. The move to Apache Superset keeps the hosting model but changes the software, so the server, database and network decisions carry over more directly. Report Server reports are typically .pbix or .rdl based, and the .pbix extraction path applies in the same way, although the source of the data is often an on-premises SQL Server that Superset can query directly.
- Steps that shrink: Connection setup is simpler, because Superset connects to on-premises databases through a Python DB-API driver and SQLAlchemy dialect.
- Steps that grow: Paginated reports and subscriptions need a different replacement plan, and report types that do not move cleanly should be listed separately.
- Decisions that change: The product key and SQL Server licensing question disappears, but the team must choose hosting, backup and patch responsibilities.
- Identity: Windows-integrated sign-in may move to LDAP, and the team must confirm how group membership is exposed by the directory.
- Ongoing: Superset releases are tracked on its own cadence, so the upgrade process replaces the Report Server release cycle.
Confirm your Report Server product key path and SQL Server edition, and read the Open-source alternative to Power BI Report Server comparison before deciding which reports to keep on Report Server during a transition.
An organization that embeds Power BI reports in its own product for customers has a different problem from an internal BI team. Power BI Embedded capacity handled tenant isolation and the embedding service, and that responsibility moves to the application team. In Superset, embedding uses an embedded SDK with guest tokens and row-level security rules, so tenant isolation must be designed explicitly and tested.
- Steps that shrink: Report layouts can often be recreated from a shared set of datasets and charts.
- Steps that grow: Row-level security rules must be written for every tenant boundary, and the team must prove that one customer cannot query another customer's data.
- Decisions that change: Guest token issuance moves into the application backend, which becomes part of the security boundary.
- Identity: Customer-facing sign-in is separate from internal staff sign-in, and the two flows should not share roles.
- Hosting: Load on the embedded dashboards may require caching and worker tuning, which should be sized through testing rather than estimated.
Before choosing this path, run a tenant isolation test with synthetic data and confirm the embedding model with your security team. For plan and licensing questions, see the sibling page on Open-source alternative to Power BI Embedded and the Metabase comparison for teams that need a different embedding model.
Questions buyers ask before moving from Power BI to Superset
What does a move from Power BI to Superset cost, and what drives it?
The cost comes from four components: the infrastructure that runs Superset and its metadata database, the implementation work to rebuild models and dashboards, the identity integration, and the people who operate and support the platform afterward. Apache Superset is Apache-2.0 licensed with no paid edition, so there is no license fee for the software itself. Infrastructure and implementation are the largest one-time items, while hosting, patching and support recur. Costs rise with the number of reports, the number of DAX measures and Power Query steps that must be rebuilt, and the size of the data sources. When you request a quote from DeployOpen, ask for the scope split into one-time and recurring items, the assumed report inventory, and what is excluded, such as your own cloud accounts or existing SSO setup. DeployOpen does not publish a price list, so the quote follows from the written scope.
How long does a Power BI to Superset migration take?
The timeline depends mostly on how many reports and semantic models are in scope, how complex the DAX and Power Query logic is, which data sources must be connected, and how quickly your identity and data owners can answer questions. Models that rely on Direct Lake, incremental refresh or very large datasets need more planning because their data cannot be downloaded with a .pbix file. Plan for an inventory phase, a pilot with a small set of dashboards, a staging run with user acceptance testing, and a cutover with a parallel run period. Ask any implementation partner to state the phases, the deliverables for each, and the acceptance criteria in writing before work starts. DeployOpen agrees scope, deliverables and timelines in writing before work begins.
Can our team migrate from Power BI to Superset without outside help?
Yes, a capable team can do it, but the work spans several skills at once: database administration for the metadata store, container or Kubernetes operations, identity configuration, SQL modeling and dashboard design. Superset's own documentation covers installation, configuration and upgrades, so a team with strong data engineering and platform skills can start internally. The usual risk is the rebuild of DAX measures and Power Query logic, which is manual work that is easy to underestimate. Consider outside help if no one on the team has run a production Python web service with a Redis and Celery stack, or if the migration must finish before a license expiry. Whichever path you choose, document the decision and the skills gap so the ownership question is answered before cutover.
What do we need to provide during a Superset migration?
Three groups of people do most of the work on your side. Data owners confirm which tables, views and business definitions are authoritative, and they sign off on metric logic. Identity administrators provide the sign-in design, including the existing Microsoft Entra ID tenant, app registrations, group membership and whether OAuth or LDAP will be used, plus the group-to-role mapping. BI analysts supply the report inventory, usage data, the list of DAX measures and Power Query steps, and the people who will test the rebuilt dashboards. Also confirm access to the data warehouse or database credentials that Superset will use, and the network path between Superset and those sources. Agree on these inputs in the scope document so delays on your side are visible early.
Can we export our Power BI reports as .pbix files and open them in Superset?
No. A .pbix file cannot be opened in Apache Superset. Power BI Desktop and the Power BI service download only give you a copy of the report and semantic model inside Microsoft's format, and the downloaded file is useful as an inventory and as a reference for logic. The DAX measures, calculated columns, relationships and Power Query transformations inside the model must be rebuilt: DAX measures become SQL metrics on Superset datasets, and Power Query steps move upstream into SQL views, dbt models or the data pipeline. Some downloads are blocked entirely for Direct Lake models, models with incremental refresh and models over 50 GB, so you may need the model definition from another source. Treat the .pbix as a specification, not as an import.
Will Superset replace every Power BI report we use?
Not automatically. Superset covers SQL-based charts, dashboards, filters and scheduled reports, and it works with any database that has a Python DB-API driver and SQLAlchemy dialect. Reports that depend on DAX-specific behavior, complex visual interactions, paginated report layouts, or Microsoft 365 features such as Teams or Excel-linked content may need a different approach or may stay on Power BI. Before you commit, classify each report as move, rebuild, redesign or retire, and record the owner and the business reason for each. Confirm the output requirements with the report owners, because a dashboard that looks similar can still produce different numbers if the metric definitions differ.
How do upgrades and backups work after Superset goes live?
Plan upgrades and backups as recurring operations from the start. Superset's upgrade documentation says to back up the metadata database first, run the database upgrade and initialization commands, test in staging, and read UPDATING.md for breaking changes between versions. Superset requires a user-specified SECRET_KEY, and it supports rotating that key with PREVIOUS_SECRET_KEY, so include key handling in your runbook. Schedule the metadata database into your backup and restore tests, and check that the Redis and Celery components are recoverable if you use alerts, reports or async queries. Ask any operations partner to document the upgrade calendar, the rollback steps and the staging environment they will use.
Does Apache Superset require a paid license?
No. Apache Superset is an Apache Software Foundation project released under the Apache License 2.0, and the project has no paid edition. You can install and run it in your own infrastructure without a license fee. Costs still arise from the infrastructure, the implementation, the identity integration, the upgrade and support work, and any commercial support contract you choose to buy. Ask your legal or procurement team to confirm the license terms against the repository license file before you record the decision, and check the license of any database drivers, extensions or plugins you add to the stack.
How DeployOpen scopes and runs a Power BI to Superset migration
DeployOpen plans and implements the Apache Superset side of this move inside your own cloud accounts, data centers or air-gapped networks. Engagements are fixed-scope, with the inventory, deliverables and timelines agreed in writing before any work starts.
How we scope
- Inventory every .pbix file, semantic model and report that is in scope for the migration.
- Record which models can be downloaded with data and which are blocked by Power BI limits.
- Agree in writing which DAX measures, Power Query steps and sign-in flows the engagement covers.
How we build
- Stand up Superset with a PostgreSQL or MySQL metadata database, plus caching and workers where alerts need them.
- Rewrite DAX measures as Superset SQL metrics on datasets, and test each result against Power BI figures.
- Configure OAuth or LDAP sign-in and map directory groups to Superset roles with AUTH_ROLES_MAPPING.
How we hand over
- Deliver written documentation of the metric definitions, dataset lineage and role mappings.
- Provide the SECRET_KEY handling, backup routine and upgrade runbook for your operations team.
- Walk your analysts and administrators through the rebuilt dashboards and the parts that changed.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Test each Superset upgrade in staging against your metric checks before it reaches production.
- Review release notes and breaking changes with your team before each version change is approved.
