Migrating Power BI Dashboards to Apache Superset: A Real Playbook

If you’re running Power BI at scale, you’ve likely hit the same walls: licensing costs that climb with every user, vendor lock-in that makes switching platforms feel impossible, and a platform that doesn’t quite fit your data stack if you’re already committed to open-source tooling or a cloud data warehouse.

Apache Superset changes that equation. It’s open-source, API-first, and integrates seamlessly with modern data stacks—dbt, Snowflake, BigQuery, Postgres, you name it. But moving from Power BI to Superset isn’t a simple export-and-import job. Your DAX measures need conversion. Your data models need rethinking. Your dashboards need rebuilding.

This playbook walks you through the real work: assessing what you have, mapping your architecture, converting your logic, and deploying dashboards that perform. By the end, you’ll know exactly what’s portable, what needs rebuilding, and how to minimize disruption while you migrate.

Understanding Why Teams Move from Power BI to Apache Superset

Before you start migrating, it’s worth understanding the actual reasons teams make this move. It’s not always about cost—though that matters. It’s usually about control, flexibility, and fit.

Power BI is a closed platform. You pay per user, per month. The data model lives inside Power BI’s proprietary format. Your queries execute on Power BI’s engine. If you want to embed analytics in your product, you’re buying premium licenses and dealing with embedding APIs that feel bolted-on. If you want to customize the UI or add functionality, you’re constrained by what Microsoft ships each quarter.

Apache Superset flips that. It’s open-source, so you control the code. It’s API-first, so embedding analytics into your product is native, not an afterthought. It integrates with your data warehouse directly—no proprietary data model layer. And because it’s built on Python and JavaScript, you can extend it, customize it, and deploy it however your infrastructure demands.

For data teams at scale-ups and mid-market companies, that’s often the difference between a tool that fits your stack and one that fights it. D23’s managed Apache Superset platform removes the operational overhead of self-hosting Superset while preserving that control and flexibility, making the migration from Power BI genuinely practical for teams that don’t want to run their own infrastructure.

The cost difference is real too. Power BI’s per-user licensing model means a 50-person analytics team can cost $10K–$20K per month. Superset, whether self-hosted or managed, scales differently—you pay for infrastructure, not seats. For organizations with large user bases or heavy self-serve BI adoption, that’s a 40–60% cost reduction.

But cost alone won’t get you through a migration. You need a plan.

Step 1: Audit Your Power BI Estate

You can’t migrate what you don’t understand. Before touching any code, spend time cataloging what you actually have.

Create a spreadsheet with these columns:

• Report name: The human-readable name of the Power BI report
• Report ID: The Power BI report GUID (you’ll need this for API calls)
• Data source(s): Where the data comes from (SQL Server, Azure SQL, Snowflake, etc.)
• Refresh frequency: How often the data updates (hourly, daily, weekly)
• User count: How many people access this report
• Critical measures: The key DAX calculations this report depends on
• Filters and slicers: What controls does the report expose to users
• Interactivity: Does it use drillthrough, bookmarks, or dynamic segmentation
• Complexity score: Rate it 1–5 based on how complex the logic is

Use the Power BI REST API to pull this metadata programmatically. Microsoft provides a Python SDK that makes this straightforward. You’ll want to extract:

• All reports and their page structure
• All datasets and their refresh schedules
• All data sources and connection strings
• All DAX measures and their definitions

This audit serves two purposes. First, it gives you a realistic scope—you might have 200 reports, but only 30 are actually critical. Second, it helps you prioritize. Start with high-traffic, low-complexity reports. Build momentum, learn the process, then tackle the complex stuff.

Step 2: Map Your Data Architecture

Power BI works with a data model layer. You define tables, relationships, and calculations in the Power BI data model, then build visualizations on top of that. Superset works differently—it queries your data warehouse or database directly.

This is the biggest conceptual shift. In Power BI, the data model is the source of truth. In Superset, your data warehouse is the source of truth, and Superset is a query layer on top of it.

That means you need to decide: do you move your data model logic into your data warehouse (using dbt), or do you rebuild it in Superset’s semantic layer?

For most teams, dbt is the answer. dbt lets you define metrics, dimensions, and transformations as code in your data warehouse. Then Superset queries those dbt models directly. Your data model becomes version-controlled, testable, and decoupled from your BI tool.

Here’s the mapping:

Power BI Data Model → dbt Project

• Power BI tables → dbt models (staging, marts, or fact tables)
• Power BI relationships → foreign keys in your warehouse schema
• Power BI measures (DAX) → dbt metrics or computed columns
• Power BI calculated columns → dbt computed columns or staging models

If your Power BI data model is already in a data warehouse (Snowflake, BigQuery, SQL Server), you’re halfway there. You just need to extract the DAX logic and convert it to SQL or dbt metrics.

If your Power BI data model is a self-service import (Excel files, CSV, or Power BI Dataflows), you’ll need to build a proper data pipeline first. This is where things get real—you can’t migrate a dashboard if the data isn’t reliable. Consider this an opportunity to professionalize your data stack.

Step 3: Convert DAX Measures to dbt Metrics or SQL

This is the hardest part of the migration. DAX is a functional language optimized for tabular data models. SQL is relational and optimized for set operations. They think differently.

Let’s work through a real example. Here’s a common Power BI DAX measure:

Sales YTD = 
  CALCULATE(
    SUM([Sales Amount]),
    DATESYTD(Calendar[Date])
  )

This calculates the year-to-date sum of sales. In dbt, you’d write this as a metric:

metrics:
  - name: sales_ytd
    description: Year-to-date sales
    type: sum
    sql: amount
    time_grains: [day, week, month, quarter, year]
    timestamp: date
    filters:
      - field: date
        operator: in_past
        value: year_to_date

Or, if dbt metrics don’t fit your use case, you’d create a SQL view:

SELECT
  DATE_TRUNC('year', order_date) as year_start,
  SUM(amount) as sales_ytd
FROM orders
WHERE DATE_TRUNC('year', order_date) = DATE_TRUNC('year', CURRENT_DATE)
GROUP BY DATE_TRUNC('year', order_date)

The conversion isn’t mechanical. You need to understand what each DAX measure actually does, then find the SQL equivalent. Some DAX measures are simple sums or averages. Others use complex functions like RANKX, DISTINCTCOUNT, or time intelligence functions. Those require more thought.

Here’s a practical approach:

1. List all DAX measures in your Power BI model. Export them from the PBIX file or copy them from the Power BI UI.
2. Categorize them by complexity: simple aggregations (SUM, AVG), time intelligence (YTD, MTD), and complex logic (RANKX, CALCULATE with multiple filters).
3. Start with simple aggregations. These convert to SQL easily.
4. Move to time intelligence measures. These need SQL window functions or date logic.
5. Save complex logic for last. You might need to rebuild these as Superset metrics or even custom Python code.

For a detailed guide on this conversion process, the Augustin Fotech guide on migrating Power BI to open-source dashboards covers DAX-to-SQL conversion patterns that apply directly to Superset.

One critical point: test your conversions. Write SQL that produces the same results as your DAX measures, then validate against Power BI’s output. A 1% difference in a key metric can invalidate your entire migration.

Step 4: Rebuild Your Data Models in Superset

Once your data is in the warehouse and your measures are converted, you need to define how Superset queries that data.

Superset uses “datasets” as the query abstraction. A dataset is a SQL query (or table reference) that Superset treats as a source for charts and dashboards. You define column types, time columns, and filters at the dataset level.

Here’s the workflow:

1. Create datasets for each logical data source. If you had a “Sales” table in Power BI, create a Sales dataset in Superset that queries your dbt mart table.
2. Define columns and types. Superset needs to know which columns are dimensions (categorical), measures (numeric), or timestamps. Get this right—it affects filtering, aggregation, and performance.
3. Set up time columns. If you have date or timestamp columns, mark them as such. Superset uses these for time-based filters and granularity controls.
4. Create virtual calculated columns if you need lightweight transformations. Superset lets you define computed columns in the dataset UI without touching SQL.
5. Add table relationships if you’re using multiple datasets in a dashboard. Superset supports cross-filtering based on shared dimensions.

For datasets that depend on complex dbt models, reference the dbt model directly. Superset integrates with dbt’s metadata, so you can query dbt models as if they were tables.

If you’re using D23’s managed Superset, this process is streamlined—D23 handles the Superset infrastructure, so you focus on defining your datasets and dashboards.

Step 5: Rebuild Dashboards, Don’t Migrate Them

This is the counterintuitive part: you’re not migrating Power BI dashboards to Superset. You’re rebuilding them.

Why? Because Power BI’s UI paradigms don’t map 1:1 to Superset. Power BI uses canvas-based layout with overlapping elements. Superset uses a grid-based layout. Power BI’s slicers work differently than Superset’s filters. Power BI has features like bookmarks and drillthrough that Superset handles via cross-filtering and custom URLs.

That said, the logic is portable. A sales dashboard in Power BI showing revenue by region, filtered by date and product category, translates to a Superset dashboard with the same charts and filters. The layout might be different, but the data story is the same.

Here’s the rebuild process:

1. Start with the dashboard structure

Open your Power BI report and take a screenshot. Note:

• How many pages does it have
• What visualizations are on each page
• What filters/slicers are exposed
• What’s the layout (top filters, charts arranged below, etc.)

2. Create the Superset dashboard

In Superset, create a new dashboard. Add the same visualizations using the datasets you created in Step 4. Superset’s grid layout will feel different, but aim for visual parity.

3. Add filters and cross-filtering

Power BI slicers become Superset native filters. Superset filters can be:

• Dataset filters: Filter a specific chart
• Dashboard filters: Apply across all charts that share a dimension
• Cross-filters: Click a value in one chart to filter others

Set these up to match your Power BI interactivity.

4. Test the user experience

Have actual users test the Superset dashboard. Does it feel intuitive? Can they find what they need? Are there Power BI features they relied on that are missing?

This is where you might need to use Superset’s advanced features: custom drill-through URLs, embedded links to other dashboards, or even Superset’s API to build custom integrations.

Step 6: Handle Power BI Premium Features

Some Power BI features don’t have direct Superset equivalents. Here’s how to handle them:

Paginated Reports

Power BI’s paginated reports are pixel-perfect, multi-page documents—think formatted reports for printing or PDF export. Superset doesn’t have a direct equivalent. Your options:

• Rebuild as Superset dashboards optimized for screen viewing
• Use a separate reporting tool (Jasper, SSRS) for paginated output
• Export Superset dashboards to PDF (less polished, but functional)

Real-time Data

Power BI can push real-time data to dashboards. Superset’s real-time support depends on your data warehouse. If you’re using a database that supports subscriptions (like Kafka or streaming data), you can set up real-time dashboards in Superset. For most data warehouses, you’ll be limited to refresh intervals (5 minutes, 1 hour, etc.).

Custom Visuals

Power BI’s custom visuals marketplace has thousands of third-party visualizations. Superset has a solid set of built-in charts (bar, line, pie, map, etc.) but fewer custom options. If you’re heavily dependent on custom visuals, you’ll need to either:

• Find Superset plugins that replicate the functionality
• Build custom visualizations using Superset’s plugin framework
• Accept that some visualizations will be different

Row-Level Security (RLS)

Power BI’s RLS restricts data based on user identity. Superset has RLS too, but it works differently. In Superset, you define RLS rules in SQL, filtering data based on the logged-in user’s attributes. This is more flexible than Power BI’s RLS in some ways, but requires more setup.

Step 7: Test, Validate, and Go Live

Before you switch off Power BI, run both systems in parallel. This is your safety net.

Validation checklist:

• Data accuracy: Do Superset dashboards show the same numbers as Power BI? Check key metrics against Power BI, your data warehouse, and source systems.
• Performance: Are dashboards fast enough? Superset queries your data warehouse directly, so performance depends on your warehouse query times. If queries are slow, optimize your dbt models or add indexes.
• Functionality: Can users do everything they could in Power BI? Filters, drillthrough, exports, etc.
• User adoption: Have your users test the Superset dashboards. Are they comfortable with the interface?

Performance optimization:

If Superset dashboards are slow, here are the levers:

1. Cache query results. Superset caches chart queries by default. Adjust cache TTL based on your refresh frequency.
2. Optimize your SQL. If your dbt models or datasets are running slow queries, optimize the SQL.
3. Add database indexes on commonly filtered columns (dates, categories, IDs).
4. Use materialized views for complex aggregations that don’t need real-time accuracy.
5. Limit data granularity. If a chart is aggregating millions of rows, pre-aggregate in your data warehouse.

Cutover strategy:

Once you’re confident, pick a cutover date. Options:

• Big bang: Switch everyone to Superset on a specific date. Riskier, but faster.
• Gradual: Roll out Superset dashboard by dashboard, team by team. Slower, but lower risk.
• Hybrid: Keep Power BI for historical reports, use Superset for new dashboards and self-serve analytics.

For most teams, a gradual rollout is safest. Pick your 5–10 most critical dashboards, migrate them first, validate, then move the rest.

Step 8: Leverage Superset’s Advanced Features Post-Migration

Once you’re live, you have opportunities that Power BI doesn’t offer. Take advantage.

Embedded Analytics

Superset is built for embedding. If you’re a SaaS company, you can embed dashboards directly into your product. D23’s managed Superset platform makes this trivial—just generate an embed token and drop the dashboard into your app. This is native in Superset, not bolted on like Power BI embedding.

AI-Powered Analytics

Superset integrates with large language models for text-to-SQL queries. Users can ask “Show me revenue by region for Q4” in natural language, and Superset generates the SQL and runs the query. This is a Power BI feature gap that Superset is filling.

API-First Architecture

Every Superset object—dashboards, charts, datasets—has an API. You can programmatically create dashboards, update filters, export data, and more. This opens up automation and integration possibilities that are hard in Power BI.

Custom Metrics and Dimensions

Superset’s semantic layer lets you define metrics and dimensions that work across all dashboards. Change a metric definition once, and it updates everywhere. This is more powerful than Power BI’s calculated columns.

Addressing Common Migration Challenges

Challenge: “Our Power BI data model is complex. How do we migrate it?”

Complex data models—with many relationships, calculated columns, and measures—are the hardest to migrate. Your best bet is to rebuild the model in dbt. dbt is designed for this. You’ll end up with a more maintainable, testable data model than you had in Power BI.

For guidance on this, Preset’s comprehensive guide on assessing BI tool migrations covers the risks and practical solutions including data model complexity.

Challenge: “Some dashboards have Power BI-specific features we can’t replicate in Superset.”

This is real. Some Power BI features (like certain custom visuals or advanced RLS scenarios) don’t map to Superset. Your options:

• Rebuild the dashboard with similar functionality
• Accept that the user experience will be slightly different
• Keep those dashboards in Power BI (hybrid approach)

Challenge: “Our team doesn’t know SQL. How do they build dashboards in Superset?”

This is where Superset’s semantic layer shines. If you set up datasets correctly, non-technical users can build dashboards by selecting columns and applying filters. They don’t need to write SQL. It’s similar to Power BI’s experience, just with a different interface.

Challenge: “We’re worried about performance. Power BI’s in-memory model is fast.”

Power BI’s in-memory model is fast for interactive queries, but it has limits—you can’t load gigabytes of data into Power BI. Superset queries your data warehouse, which can handle terabytes. For large datasets, Superset is actually faster. For small datasets with heavy interactivity, Power BI might feel snappier. The trade-off is real, but for most organizations, Superset’s performance is sufficient with proper optimization.

Real-World Migration Timeline

Here’s what a realistic migration looks like for a mid-sized organization (50–100 dashboards):

• Weeks 1–2: Audit Power BI estate, define scope, prioritize dashboards
• Weeks 3–4: Set up Superset infrastructure (or sign up for D23 managed Superset), build dbt project for data modeling
• Weeks 5–6: Convert DAX measures to SQL/dbt, create datasets in Superset
• Weeks 7–10: Rebuild priority dashboards (10–15), test with users
• Weeks 11–12: Parallel run, validation, performance tuning
• Week 13+: Gradual rollout of remaining dashboards, decommission Power BI

Total: 3–4 months for a mid-sized estate. Larger organizations might need 6–9 months.

Why D23 Simplifies Superset Migration

Managing Superset infrastructure adds complexity to an already complex project. You need to provision servers, manage upgrades, handle backups, and scale as usage grows. D23’s managed Superset platform eliminates that overhead.

With D23, you get:

• Production-grade infrastructure: Superset running on reliable, scalable infrastructure
• Built-in integrations: Direct connections to your data warehouse, dbt, and APIs
• Expert support: Access to data consulting and migration guidance
• API-first architecture: Embed dashboards, automate workflows, build custom integrations
• Semantic layer: Define metrics and dimensions once, use everywhere

For teams migrating from Power BI, this means you can focus on the data and dashboards, not the infrastructure.

Key Takeaways

Migrating from Power BI to Apache Superset is feasible, but it requires planning. Here’s what you need to do:

1. Audit your Power BI estate to understand scope and complexity
2. Map your data architecture and decide on dbt vs. Superset semantic layer
3. Convert DAX measures to SQL or dbt metrics
4. Rebuild dashboards in Superset (don’t expect a direct migration)
5. Handle Power BI-specific features with workarounds or acceptance
6. Test thoroughly before cutting over
7. Leverage Superset’s advantages post-migration (embedding, APIs, AI)

The effort is real, but the payoff is significant: lower costs, more control, better integration with modern data stacks, and a platform that grows with your team.

If you’re ready to start the migration, D23 can guide you through the process with managed Superset infrastructure and expert data consulting. The first step is understanding your current state—run that audit, and you’ll know whether Superset is right for you.