Migrating from Power BI to Superset for Enterprise Organisations

Table of Contents

1. Why enterprises migrate from Power BI to Superset
2. Scoping and discovery
3. Cost and governance framework
4. Architecture and data layer design
5. Migration playbook and cutover pattern
6. Team structure and skills
7. Common pitfalls and how to avoid them
8. Post-migration operations and optimisation
9. Summary and next steps

---

Why enterprises migrate from Power BI to Superset {#why-migrate}

Power BI has dominated enterprise analytics for a decade. It’s easy to adopt, deeply integrated with the Microsoft stack, and requires minimal data engineering overhead. But at scale—particularly in organisations with hundreds of users, complex governance requirements, or multi-tenant SaaS products—the per-seat licensing model, vendor lock-in, and architectural constraints force teams to reassess.

Superset changes the equation. As an open-source, SQL-native analytics platform, it runs on your own infrastructure, scales horizontally, and costs a fraction of per-seat BI tools. For enterprise organisations, this translates to concrete outcomes: we’ve seen teams cut BI spend by 40–60%, ship embedded analytics in weeks instead of months, and regain control over their data stack.

But migration is not a copy-paste operation. It requires strategic scoping, governance redesign, and a disciplined cutover pattern. This guide walks you through the playbook we use at PADISO to migrate enterprise teams from Power BI to Superset—covering what to measure, how to architect, and how to land without breaking reporting.

The business case: cost, control, and customisation

Three factors drive migration decisions:

Cost. Power BI per-seat licensing scales linearly with users. A 500-person organisation with 200 BI users pays roughly $15,000–$25,000 per month. Superset, deployed on commodity cloud infrastructure (AWS, Azure, GCP), costs $3,000–$8,000 per month for equivalent scale—including storage, compute, and support. The payback period is typically 6–12 months.

Control. Power BI runs in Microsoft’s cloud. Your data models, dashboards, and governance policies live in Microsoft’s environment. Superset runs on your infrastructure. You own the data, the logic, and the audit trail. For regulated industries—financial services, healthcare, government—this is non-negotiable.

Customisation. Power BI’s extensibility is bounded by Microsoft’s roadmap. Superset is open-source. You can fork it, extend it, embed it, and integrate it with your product. For product teams building embedded analytics or operators modernising legacy platforms, this unlocks use cases Power BI cannot address.

These factors compound. A financial services firm we worked with in Sydney migrated 300+ Power BI users to Superset, cut BI infrastructure costs by 50%, and shipped embedded dashboards in their customer portal within 4 months. That outcome required disciplined scoping and execution.

---

Scoping and discovery {#scoping}

Scoping a Power BI to Superset migration is not about counting dashboards. It’s about understanding dependencies, data lineage, governance models, and user behaviour. Poor scoping leads to surprise rework, extended cutover windows, and user frustration.

Inventory and dependency mapping

Start by cataloguing every Power BI asset:

• Reports and dashboards. Count them, categorise by business function, and identify which are actively used. (Tools like Power BI Analyzer or Fabric workspace metrics reveal usage patterns.)
• Data sources. Document every connection: SQL databases, Azure Data Lake, Dataverse, web services, Excel files, on-premises systems. Identify refresh schedules, connection types (DirectQuery vs. Import), and row-level security (RLS) rules.
• Data models. Export the Power BI data model schema. Identify calculated columns, measures, hierarchies, and relationships. This becomes your specification for Superset datasets.
• User roles and permissions. Map who accesses what, at what granularity. RLS in Power BI is often baked into the data model; in Superset, it’s enforced at the database layer or via Superset’s native RBAC.
• Refresh pipelines. Understand data refresh cadences, dependencies on other systems, and failure modes. Power BI’s dataflow orchestration may not have an equivalent in your Superset setup.

A typical enterprise inventory:

• 150–400 active reports and dashboards
• 20–50 data sources
• 5–15 core data models
• 100–500 users with varying permission levels
• 10–30 refresh pipelines

Document this in a spreadsheet. Include owner, business function, refresh frequency, user count, and criticality. This becomes your migration sequencing guide.

User research and adoption planning

Interview 10–15 power users from each business function. Ask:

• Which dashboards do you use daily? Weekly?
• What breaks your workflow if that dashboard is unavailable for 2 hours? 2 days?
• What would you change about the current tool if you could?
• Do you use mobile, scheduled email delivery, or embedded reports?

This research informs your cutover sequence (migrate critical dashboards first) and helps you identify adoption risks early. Power BI users often develop strong habits; Superset’s interface is different, and some workflows may require rethinking.

Data readiness assessment

Superset is SQL-native. It expects clean, well-structured data in a data warehouse or analytical database. If your Power BI setup pulls from a maze of Excel files, legacy systems, and manual ETL, you’ll need to address that first.

Assess:

• Data warehouse maturity. Do you have a modern warehouse (Snowflake, BigQuery, Redshift, Postgres)? If not, you’ll need to build one alongside Superset.
• ETL pipeline quality. Are your data pipelines automated, tested, and documented? Or are they manual, brittle, and owned by one person?
• Data governance. Do you have a data dictionary, lineage tracking, and quality checks? Superset will expose gaps here.

If your data layer is weak, the migration becomes a dual project: modernise data, then migrate BI. This extends timelines and budgets, but it’s necessary. We typically recommend starting the data warehouse migration 2–3 months before BI cutover.

---

Cost and governance framework {#cost-governance}

Enterprise migrations fail when cost and governance are treated as afterthoughts. Define both upfront.

Total cost of ownership (TCO) model

Build a 3-year TCO model comparing Power BI and Superset. Include:

Power BI costs:

• Per-seat licenses (Pro, Premium, Embedded)
• Premium capacity (if applicable)
• Power BI Dataflows or Azure Data Factory for ETL
• Support and training
• Data warehouse licensing (if separate)

Superset costs:

• Cloud infrastructure (compute, storage, networking)
• Data warehouse licensing (Snowflake, BigQuery, etc.)
• Superset hosting (managed service like Preset or self-hosted)
• Custom development and integrations
• Support and training
• Personnel (DevOps, data engineer, BI engineer)

For a 500-person organisation with 200 Power BI users:

Category	Power BI (Year 1)	Superset (Year 1)	Savings
BI licensing	$180,000	$0	$180,000
Data warehouse	$60,000	$60,000	$0
Infrastructure	$0	$40,000	-$40,000
Migration/setup	$0	$120,000	-$120,000
Total Year 1	$240,000	$220,000	$20,000
Total Year 3	$720,000	$420,000	$300,000

Year 1 shows modest savings because you’re absorbing migration costs. Years 2–3 compound the advantage. Present this model to CFO and business stakeholders early. It reframes the migration from a cost centre to a value driver.

Governance and compliance framework

Superset’s governance model differs fundamentally from Power BI. You must redesign it.

Access control:

Power BI uses workspace roles (Admin, Member, Contributor, Viewer). Superset uses role-based access control (RBAC) at the database and dashboard level. You can map:

• Power BI Workspace Admin → Superset Admin
• Power BI Member → Superset Editor
• Power BI Contributor → Superset Editor
• Power BI Viewer → Superset Viewer

But granular permissions (who can see which dashboard) are enforced differently. In Superset, you grant users access to specific databases and dashboards via role assignments or LDAP/SSO integration.

Row-level security (RLS):

Power BI bakes RLS into the data model (via DAX). Superset enforces RLS at the database layer. This is a critical difference. If your Power BI reports use RLS to show sales reps only their territory, you’ll implement that via:

1. Database-level RLS (Postgres Row Security, BigQuery authorised views, Snowflake dynamic masking)
2. Superset jinja templating (inject user context into SQL queries)
3. Virtual datasets (create user-specific views or materialised tables)

Option 1 is most secure and scalable. It requires coordination with your data engineering team.

Audit and compliance:

Superset provides audit logs (who viewed what, when). For regulated industries, you may need:

• Query logging. Every SQL query executed, with user, timestamp, and result set size.
• Data lineage. Traceability from source system to dashboard.
• Encryption in transit and at rest.
• Compliance certifications. If you’re pursuing SOC 2 or ISO 27001, Superset’s open-source nature means you’re responsible for security posture. (We help teams pass audits via Security Audit and ISO 27001 compliance frameworks.)

Document your governance policy before migration. Socialise it with security, compliance, and business stakeholders.

---

Architecture and data layer design {#architecture}

Superset’s strength is its flexibility. But flexibility requires deliberate architecture.

Data warehouse selection

Superset works with any SQL database. For enterprise scale, choose one of:

• Snowflake. Cloud-native, multi-tenant, excellent for analytics. $2–$4 per compute hour. Best for organisations already using Snowflake or wanting managed infrastructure.
• BigQuery. Google’s serverless warehouse. Pay per query. Excellent for ad-hoc analytics, integrates natively with Google Cloud.
• Redshift. AWS’s data warehouse. Good for organisations deep in AWS. Requires more management than Snowflake.
• Postgres (with ClickHouse or TimescaleDB extensions). For cost-sensitive deployments or on-premises requirements. Requires more operational overhead.

For most enterprises, Snowflake + Superset is the default. It’s cloud-native, scales elastically, and separates compute from storage (you pay for query execution, not idle capacity).

If you’re already using a data warehouse (Snowflake, BigQuery, Redshift), Superset plugs in directly. If not, you’ll build one as part of the migration.

Dataset and semantic layer design

In Power BI, the data model is the semantic layer. In Superset, the semantic layer is distributed across:

1. Warehouse schema (fact and dimension tables, slowly changing dimensions)
2. Superset datasets (saved queries, aggregations, joins)
3. Superset metrics (reusable calculated fields)

Design your semantic layer to mirror Power BI’s data models. For each Power BI model, create a corresponding Superset dataset:

Example: Sales model

Power BI model:

• Fact table: Orders (order_id, customer_id, product_id, amount, order_date)
• Dimension: Customers (customer_id, name, region, segment)
• Dimension: Products (product_id, name, category, price)
• Measures: Total Revenue, Units Sold, Average Order Value

Superset dataset:

• Base query: SELECT o.order_id, o.amount, o.order_date, c.region, p.category FROM orders o JOIN customers c ON o.customer_id = c.customer_id JOIN products p ON o.product_id = p.product_id
• Metrics: SUM(amount) as Total Revenue, COUNT(order_id) as Units Sold, AVG(amount) as Average Order Value

This mapping ensures Power BI users find familiar structure in Superset.

Embedding and integration patterns

If you’re embedding analytics in a product or customer portal, Superset’s architecture matters. Superset supports:

• Embedded dashboards via iframe or SDK
• Guest token authentication (anonymous access to specific dashboards)
• API-driven dashboards (programmatic access to chart data)

For product teams at Platform Development in Sydney or other major hubs, embedded Superset often replaces custom BI layers. This unlocks faster feature delivery and lower infrastructure costs.

---

Migration playbook and cutover pattern {#playbook}

The cutover is where migrations succeed or fail. A disciplined playbook minimises risk.

Phase 1: Preparation (Weeks 1–4)

Weeks 1–2: Infrastructure and connectivity

• Provision Superset environment (managed service or self-hosted)
• Connect to data warehouse
• Set up SSO/LDAP integration
• Configure backup, monitoring, and logging
• Test data warehouse connectivity and query performance

Weeks 3–4: Semantic layer build

• Create Superset datasets for each Power BI data model
• Validate dataset queries against Power BI model definitions
• Set up metrics and calculated fields
• Implement RLS policies
• Document dataset lineage and ownership

Deliverables:

• Superset environment ready for testing
• All datasets created and validated
• RLS policies in place
• Team trained on Superset interface

Phase 2: Pilot migration (Weeks 5–8)

Week 5: Select pilot cohort

Choose 1–2 business functions with 20–50 users and 10–15 dashboards. Criteria:

• High user adoption (they’ll provide feedback)
• Moderate complexity (not your most critical, not your simplest)
• Self-contained data model (minimal cross-dependencies)

Good pilots: sales analytics, marketing dashboards, operational metrics. Avoid: regulatory reporting, executive dashboards (migrate those later).

Weeks 6–7: Recreate dashboards

• Rebuild Power BI reports in Superset
• Match layouts, filters, and interactivity as closely as possible
• Validate numbers against Power BI
• Set up scheduled email delivery and alerts
• Test on mobile (Superset’s mobile experience differs from Power BI)

Week 8: Pilot cutover and feedback

• Switch pilot users to Superset for 2 weeks
• Collect feedback via surveys and interviews
• Fix bugs and UX issues
• Document lessons learned
• Measure adoption (daily active users, dashboard views)

Deliverables:

• 10–15 pilot dashboards recreated in Superset
• Pilot cohort trained and live
• Feedback captured and prioritised
• Lessons learned documented

Phase 3: Scaled migration (Weeks 9–16)

Weeks 9–10: Batch 1 migration

• Migrate 30–40% of remaining dashboards
• Prioritise by criticality and user count
• Parallel-run Power BI and Superset for 1 week
• Switch to Superset-only

Weeks 11–13: Batch 2 migration

• Migrate next 30–40% of dashboards
• Repeat parallel-run and cutover

Weeks 14–16: Batch 3 migration and stabilisation

• Migrate remaining dashboards
• Focus on regulatory and executive dashboards (highest stakes)
• Extended parallel-run (2 weeks) for critical reports
• Full cutover

Parallel-run checklist:

• Both Power BI and Superset dashboards live
• Users encouraged to compare numbers
• Discrepancies logged and resolved
• Cutover decision gated on validation

Deliverables:

• All dashboards migrated
• Power BI decommissioned
• User adoption metrics tracked
• Support playbook documented

Phase 4: Optimisation (Weeks 17–24)

Weeks 17–20: Performance tuning

• Identify slow queries (Superset query logs)
• Optimise warehouse schema (add indexes, materialised views)
• Tune Superset caching and refresh policies
• Benchmark query performance vs. Power BI

Weeks 21–24: Governance hardening

• Implement advanced RBAC (if needed)
• Set up data quality monitoring
• Document runbooks for common tasks
• Transition to steady-state support model

Deliverables:

• Performance baselines documented
• Optimisations complete
• Support team trained and ready
• Governance policies enforced

---

Team structure and skills {#team-structure}

Migration success depends on team composition. You need:

Project lead (1 person). Owns timeline, stakeholder communication, and risk management. Usually a product manager or senior operator.

Data engineer (1–2 people). Builds and maintains semantic layer, optimises warehouse queries, manages data pipelines. Requires SQL, data modelling, and warehouse platform expertise.

BI engineer (2–3 people). Recreates dashboards in Superset, implements RLS, configures alerts and scheduling. Requires Superset knowledge, SQL, and design sense.

DevOps/platform engineer (1 person). Provisions infrastructure, manages Superset deployment, handles security and compliance. Requires Kubernetes, cloud platforms, and security practices.

QA/validation (1 person, part-time). Compares Power BI and Superset dashboards, validates numbers, documents discrepancies.

Change management (0.5 person). Trains users, gathers feedback, communicates progress. Often shared with product or ops.

Total effort: 6–8 FTE-months for a 500-person organisation with 200 Power BI users.

If you lack in-house expertise, partner with a vendor or agency. At PADISO, we embed fractional CTO and platform engineering teams into migration projects, handling architecture, semantic layer design, and governance frameworks. We’ve shipped migrations for financial services firms in New York and Toronto, and for government agencies in Canberra and Washington, D.C..

---

Common pitfalls and how to avoid them {#pitfalls}

Pitfall 1: Underestimating semantic layer work

Problem: Teams assume recreating dashboards is the main effort. In reality, it’s 20% of the work. The other 80% is designing, building, and validating the semantic layer.

Why it happens: Power BI’s data model is opaque to most users. The complexity is hidden until you try to replicate it.

How to avoid it:

• Spend Weeks 1–4 fully understanding Power BI models
• Build Superset datasets in parallel with dashboard recreation
• Allocate 40% of migration effort to semantic layer
• Use Apache Superset Documentation and community resources extensively

Pitfall 2: Ignoring RLS complexity

Problem: Power BI’s RLS is baked into the model. Superset’s RLS is at the database layer. Teams often miss this architectural shift and end up with insecure dashboards.

How to avoid it:

• Map RLS requirements during scoping
• Choose RLS implementation approach early (database-level, Superset jinja, or virtual tables)
• Test RLS thoroughly in pilot phase
• Document RLS logic and maintenance procedures

Pitfall 3: Weak data warehouse foundation

Problem: Teams migrate to Superset before their warehouse is mature. Queries are slow, schema is messy, and users blame Superset.

How to avoid it:

• Assess data warehouse maturity upfront
• If weak, modernise warehouse 2–3 months before BI cutover
• Use Superset migration as catalyst for data governance investment
• Involve data engineering early and often

Pitfall 4: Insufficient parallel-run time

Problem: Teams cut over to Superset before validating numbers. Discrepancies emerge post-cutover, eroding trust.

How to avoid it:

• Run Power BI and Superset side-by-side for 1–2 weeks per batch
• Require explicit sign-off from business stakeholders before cutover
• Document all number discrepancies and root causes
• Use Power BI optimization guidance to validate Power BI models during parallel-run

Pitfall 5: Underinvesting in training and change management

Problem: Superset’s interface is different from Power BI. Without training, users struggle and adoption stalls.

How to avoid it:

• Allocate 10–15% of migration budget to training
• Run cohort-based training (20–30 people per session)
• Create video tutorials for common tasks
• Establish office hours for Q&A
• Celebrate wins and gather feedback continuously

Pitfall 6: Decommissioning Power BI too early

Problem: Teams turn off Power BI before all dashboards are validated. Users lose access to critical reports.

How to avoid it:

• Keep Power BI live for 4–6 weeks after final cutover
• Maintain read-only access (disable new report creation)
• Use this window to catch edge cases and user feedback
• Only decommission after explicit stakeholder approval

---

Post-migration operations and optimisation {#operations}

Migration is not the end. Steady-state operations require discipline.

Performance monitoring and tuning

Query performance:

Superset logs every query. Use this data to identify slow dashboards:

SELECT
  dashboard_id,
  AVG(duration_ms) AS avg_duration,
  MAX(duration_ms) AS max_duration,
  COUNT(*) AS query_count
FROM query_log
WHERE executed_at > NOW() - INTERVAL 7 DAY
GROUP BY dashboard_id
ORDER BY avg_duration DESC

If a dashboard takes >10 seconds to load, investigate:

1. Dataset query complexity. Simplify joins, add indexes, materialise intermediate tables.
2. Warehouse compute. Scale up (Snowflake, BigQuery) or optimise query plan.
3. Caching. Enable Superset’s result caching for frequently-run queries.
4. Filters. Encourage users to filter by date range or region (reduces result set).

Infrastructure metrics:

Monitor Superset’s own performance:

• CPU and memory utilisation
• Database connection pool saturation
• Cache hit rates
• API response times

Set alerts for anomalies. If CPU spikes, investigate which dashboard is running expensive queries.

Governance and compliance maintenance

Quarterly access reviews:

Run quarterly audits of who has access to what:

SELECT
  user_id,
  COUNT(DISTINCT dashboard_id) AS dashboard_count,
  MAX(last_login) AS last_login
FROM user_dashboard_access
GROUP BY user_id
ORDER BY last_login DESC

Deactivate accounts with no recent activity. Remove access to dashboards users no longer need.

Data lineage and documentation:

Maintain a data dictionary:

• Dataset name and owner
• Source tables and refresh frequency
• Metrics and their definitions
• RLS policies
• Known limitations

Update quarterly as new dashboards are added.

Compliance and audit trails:

If you’re subject to SOC 2 or ISO 27001 audits, maintain:

• Query logs (6–12 months retention)
• Access logs (who viewed what, when)
• Change logs (schema changes, metric updates)
• Security patches and vulnerability assessments

For regulated industries, consider working with a partner experienced in compliance frameworks. Teams in Melbourne and Wellington often need Security Audit and ISO 27001 compliance support alongside analytics modernisation.

User feedback and iteration

Monthly adoption surveys:

Ask users:

• Are you using Superset daily? Weekly?
• What’s missing compared to Power BI?
• What’s better in Superset?
• What training would help?

Use feedback to prioritise improvements.

Feature requests and roadmap:

Maintain a backlog of feature requests. Prioritise by:

• User count affected
• Business impact
• Implementation effort

Common requests: advanced scheduling, custom branding, API enhancements. Some can be addressed in Superset; others may require custom development.

Cost optimisation

Warehouse costs:

Monitor warehouse spend. If using Snowflake:

SELECT
  DATE_TRUNC('day', query_start_time) AS query_date,
  SUM(credits_used) AS daily_credits,
  SUM(credits_used) * 4 AS estimated_cost_usd
FROM snowflake.account_usage.query_history
WHERE query_start_time > DATEADD(month, -3, CURRENT_DATE)
GROUP BY query_date
ORDER BY query_date DESC

If costs are rising, investigate:

1. New dashboards with expensive queries
2. Increased data volume
3. More frequent refreshes
4. Inefficient query patterns

Optimise by clustering tables, pruning unused data, or adjusting refresh schedules.

Infrastructure costs:

If self-hosting Superset, monitor cloud spend:

• Compute (EC2, GKE, AKS): scale down during off-hours
• Storage: archive old data, delete unused caches
• Networking: optimise data transfer costs

For most enterprises, managed Superset (Preset or similar) is cheaper than self-hosting when you factor in DevOps labour.

---

Summary and next steps {#summary}

Migrating from Power BI to Superset is a 4–6 month undertaking for enterprise organisations. Done well, it cuts BI costs by 40–60%, gives you control over your analytics stack, and unlocks embedded analytics use cases.

The playbook is straightforward:

1. Scope ruthlessly. Inventory all Power BI assets, understand dependencies, and assess data readiness.
2. Design governance upfront. Map access control, RLS, and compliance requirements before any dashboard recreation.
3. Build the semantic layer first. Datasets are 80% of the effort; dashboards are 20%.
4. Pilot with a cohort. Test with 20–50 users before scaling.
5. Run parallel for validation. Never cutover without comparing numbers.
6. Invest in training. Users need to learn Superset’s interface and workflows.
7. Optimise post-cutover. Monitor performance, maintain governance, and iterate based on feedback.

Getting started

If you’re evaluating Superset for your organisation, start with these resources:

• Apache Superset Documentation covers architecture, deployment, and administration
• Preset Blog has practical articles on governance, scaling, and operations
• Apache Superset guide explains how Superset fits into modern data stacks
• BI and Analytics Platforms reviews provide market context and user feedback
• Power BI reviews on Gartner Peer Insights help you understand Power BI’s strengths and limitations

For deeper guidance on architecture, governance, or team structure, consider engaging a partner. At PADISO, we embed platform engineering teams into analytics modernisation projects. We’ve led migrations for financial services, retail, and government organisations across Australia, North America, and beyond.

Our Platform Development in Australia teams specialise in Superset + ClickHouse stacks for multi-tenant SaaS and enterprise analytics. We also support teams in the US via Platform Development in Dallas, Chicago, and Austin, as well as Canada via Platform Development in Toronto and Ottawa, and New Zealand via Platform Development in Wellington.

If you’re migrating Power BI to Superset, we can help with:

• Scoping and discovery – Inventory, dependency mapping, cost modelling
• Architecture and semantic layer design – Data warehouse selection, dataset design, RLS implementation
• Migration execution – Fractional CTO leadership, BI engineering, quality assurance
• Post-migration optimisation – Performance tuning, governance hardening, cost optimisation

Get in touch to discuss your migration roadmap. We typically work with teams across Platform Development in United States, Canada, and New Zealand on analytics modernisation as part of broader platform engineering engagements.

The shift from per-seat BI to open-source analytics is not just a tool swap—it’s a structural change to how you own and operate your data. With the right playbook and team, it’s entirely achievable, and the payoff is substantial.