Migrating from Sisense to Apache Superset: The D23.io Playbook

Table of Contents

1. Why Teams Migrate from Sisense to Superset
2. The Migration Architecture and Timeline
3. Phase 1: Assessment and Data Source Remapping
4. Phase 2: Semantic Layer Translation
5. Phase 3: Dashboard Rebuild and Validation
6. Phase 4: User Training and Change Management
7. Phase 5: Cutover and Go-Live
8. Cost and Timeline Benchmarks
9. Common Pitfalls and How to Avoid Them
10. Next Steps: Getting Started

---

Why Teams Migrate from Sisense to Superset {#why-teams-migrate}

Over the past three years, we’ve guided more than a dozen mid-market and scale-up teams through BI platform migrations. The pattern is consistent: organisations outgrow Sisense for one of three reasons.

Cost. Sisense per-seat licensing becomes prohibitive when you need to scale analytics access across your entire organisation. A 200-person company paying $5,000 per analyst seat quickly hits $500K+ annually. Apache Superset, deployed on your own infrastructure or via a managed service like Preset, costs a fraction of that.

Flexibility. Sisense’s data model is powerful but opinionated. When you need to embed analytics into your product, build custom transformations, or integrate with modern data stacks (Snowflake, BigQuery, Databricks), you hit the edges of what Sisense can do without engineering workarounds.

Modernisation. Superset is open-source, actively maintained, and integrates natively with dbt, Airflow, and containerised deployments. Teams pursuing platform engineering modernisation often find Superset aligns better with their cloud-native, infrastructure-as-code philosophy.

We’ve seen teams cut BI costs by 40–60% and reduce time-to-dashboard from weeks to days after migration. But the migration itself is not trivial. It requires a structured plan, realistic timelines, and clear ownership.

This playbook covers the exact steps we use to de-risk Sisense-to-Superset migrations, including data source remapping, semantic layer translation, dashboard rebuild patterns, and a battle-tested cutover process.

---

The Migration Architecture and Timeline {#migration-architecture}

A well-executed Sisense-to-Superset migration follows five phases, spanning 8–12 weeks for a mid-market deployment.

Phase 1: Assessment and Data Source Remapping (Weeks 1–2) Inventory all Sisense data sources, cubes, and dashboards. Map each to equivalent Superset data sources (native connectors, SQL, or semantic layers). Identify gaps and build a data pipeline plan.

Phase 2: Semantic Layer Translation (Weeks 2–4) Rebuild Sisense cubes and calculated fields in Superset. This is typically done via SQL views, dbt models, or Superset’s native dataset abstraction. Validate metric definitions and calculations match the source system.

Phase 3: Dashboard Rebuild and Validation (Weeks 4–8) Rebuild dashboards in Superset. Test all visualisations, filters, and drill-throughs. Validate that dashboard KPIs match Sisense outputs exactly. Run parallel reporting for 2–4 weeks.

Phase 4: User Training and Change Management (Weeks 6–10) Run role-based training sessions. Publish Superset best-practice guides. Establish support channels and escalation paths.

Phase 5: Cutover and Go-Live (Weeks 10–12) Deactivate Sisense. Switch all users to Superset. Monitor performance and user adoption. Retire Sisense infrastructure after 30 days (in case rollback is needed).

The timeline assumes a team of 2–3 engineers and 1 analytics lead working part-time. Larger teams can compress this; smaller teams may extend it.

---

Phase 1: Assessment and Data Source Remapping {#phase-1-assessment}

Inventory Your Current State

The first step is a complete audit of your Sisense deployment. Document:

• Data sources: All databases, APIs, and file connectors (JDBC, ODBC, REST, CSV).
• Cubes and datasets: Fact tables, dimensions, hierarchies, calculated fields, and filters.
• Dashboards: Count, ownership, refresh frequency, and user count.
• Users and roles: Admin, designer, viewer, and custom role definitions.
• Scheduled reports: Email distributions, export formats, and frequency.
• Custom extensions: Any JavaScript, plugins, or bespoke connectors.

Create a simple spreadsheet:

Sisense Asset	Type	Complexity	Owner	Target Superset Equivalent	Notes
Sales Data Warehouse	Cube	High	Analytics	dbt model + Superset dataset	Includes 15 calculated fields
Regional Revenue	Dashboard	Medium	Finance	Superset dashboard	8 charts, daily refresh
Customer 360	Cube	Medium	Product	SQL view + Superset semantic layer	Drill-through to transactions

This inventory is your migration roadmap. Teams often underestimate complexity here; plan for 3–5 days of discovery.

Map Data Sources to Superset Connectors

Superset supports 100+ data sources natively, including all major databases (PostgreSQL, MySQL, Snowflake, BigQuery, Redshift, Databricks). However, not all Sisense connectors have direct equivalents.

Common mappings:

• Sisense JDBC/ODBC → Superset SQL Alchemy connector (PostgreSQL, MySQL, Oracle, etc.).
• Sisense REST API → Superset Python connector or custom plugin.
• Sisense CSV/Excel → Superset database import or dbt seed.
• Sisense cloud connectors (Salesforce, HubSpot, etc.) → Superset connectors or dbt packages.

For each source, test connectivity in Superset before proceeding. Document any authentication changes (IP whitelisting, API key rotation, VPN access).

Define the Semantic Layer Strategy

This is critical. Sisense cubes are semantic layers—they abstract raw data into business logic. Superset has no direct cube equivalent, but you have options:

Option 1: SQL Views Create database views that replicate Sisense cube logic. Simple, fast, database-native. Works well for straightforward transformations. Requires database DDL permissions.

Option 2: dbt Models Use dbt to document and version-control your semantic layer. Recommended for teams already using dbt. Provides lineage, testing, and documentation out of the box.

Option 3: Superset Datasets Use Superset’s native dataset abstraction to define metrics, dimensions, and calculated fields. Easiest for non-technical analysts. Less portable than dbt or SQL views.

Option 4: Hybrid Combine SQL views (for heavy lifting) with Superset datasets (for business logic). Often the most pragmatic approach.

For a migration, we recommend Option 2 (dbt) or Option 4 (hybrid). dbt gives you version control, testing, and documentation. Superset datasets provide a UI-driven layer on top for analysts.

Create a Data Lineage Map

Document how data flows from source systems through Sisense cubes to dashboards. Example:

Salesforce → Data Warehouse → Sisense "Sales" Cube → Regional Revenue Dashboard
                          ↓
                    Sisense "Forecast" Cube → Pipeline Dashboard

In Superset, this becomes:

Salesforce → Data Warehouse → dbt models → Superset datasets → Dashboards

This lineage map is invaluable for testing and validation. It also helps you identify dependencies and build a rebuild sequence.

---

Phase 2: Semantic Layer Translation {#phase-2-semantic-layer}

Translate Sisense Cubes to dbt Models

If you’ve chosen dbt (recommended), each Sisense cube becomes one or more dbt models. The translation process:

1. Extract the cube definition from Sisense (via API or manual review).
2. Identify base tables and joins. Sisense cubes are built on fact and dimension tables; document the join logic.
3. Translate calculated fields to dbt SQL. Most Sisense expressions (SUM, COUNT, DATEDIFF, etc.) map directly to SQL.
4. Create staging and mart models. Use dbt best practices: staging models for raw data cleaning, mart models for business logic.
5. Test and validate. Use dbt tests to ensure row counts, uniqueness, and relationships match Sisense.

Example: Translating a Sisense Sales Cube

Sisense cube definition (pseudocode):

Cube: Sales
  Fact Table: transactions
  Dimensions: customer, product, date, region
  Measures:
    - Total Revenue: SUM(amount)
    - Avg Order Value: SUM(amount) / COUNT(DISTINCT order_id)
    - YoY Growth: (This Year Revenue - Last Year Revenue) / Last Year Revenue

dbt equivalent (staged models):

-- models/staging/stg_transactions.sql
select
  transaction_id,
  customer_id,
  product_id,
  transaction_date,
  amount,
  quantity
from {{ source('salesforce', 'transactions') }}
where transaction_date >= '2020-01-01'

-- models/marts/fct_sales.sql
select
  t.transaction_id,
  c.customer_id,
  c.region,
  p.product_id,
  p.category,
  t.transaction_date,
  t.amount,
  t.quantity,
  t.amount / nullif(t.quantity, 0) as unit_price
from {{ ref('stg_transactions') }} t
left join {{ ref('dim_customer') }} c on t.customer_id = c.customer_id
left join {{ ref('dim_product') }} p on t.product_id = p.product_id

-- models/marts/fct_sales_aggregated.sql
select
  date_trunc('month', transaction_date)::date as month,
  region,
  category,
  sum(amount) as total_revenue,
  count(distinct transaction_id) as transaction_count,
  sum(amount) / nullif(count(distinct transaction_id), 0) as avg_transaction_value,
  sum(quantity) as total_quantity
from {{ ref('fct_sales') }}
group by 1, 2, 3

Then, in Superset, you create a dataset pointing to fct_sales_aggregated and define additional metrics (YoY growth) at the Superset layer.

Handle Calculated Fields and Expressions

Sisense calculated fields often use proprietary syntax. Common translations:

Sisense Function	SQL Equivalent	Notes
SUM(field)	SUM(field)	Direct
COUNT(DISTINCT field)	COUNT(DISTINCT field)	Direct
DATEDIFF('month', date1, date2)	DATE_TRUNC('month', date2) - DATE_TRUNC('month', date1)	Database-specific
IF(condition, true_val, false_val)	CASE WHEN condition THEN true_val ELSE false_val END	Direct
RUNNING_SUM(field)	Window function: SUM(field) OVER (ORDER BY date)	Requires SQL window syntax
RANK()	ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...)	Requires window function

For complex expressions, test them in your target database before committing to dbt. Many teams find that 10–15% of Sisense calculated fields need refactoring or simplification.

Validate Metric Definitions

Run reconciliation queries to ensure your dbt models produce the same results as Sisense. For each key metric:

1. Export the metric from Sisense (CSV).
2. Query the equivalent dbt model in Superset.
3. Compare row-by-row. Document any discrepancies.

Common sources of discrepancy:

• Null handling: Sisense and SQL treat NULLs differently in aggregations.
• Date boundaries: Time zone differences or inclusive/exclusive date ranges.
• Rounding: Sisense may round intermediate calculations; SQL does not.
• Filters: Sisense cube filters may not translate directly to WHERE clauses.

Allocate 1–2 weeks for this validation. It’s tedious but essential—users will notice if KPIs change.

---

Phase 3: Dashboard Rebuild and Validation {#phase-3-dashboard-rebuild}

Prioritise Dashboards by Impact

Not all dashboards are equally important. Prioritise based on:

• User count: Dashboards viewed by 50+ users per month.
• Business criticality: Executive dashboards, operational reports, customer-facing analytics.
• Complexity: Start with simple dashboards (5–10 charts) to build momentum.

Rank dashboards on a simple matrix:

Dashboard	Users/Month	Criticality	Complexity	Priority
Executive KPI	200	High	Low	1
Regional Sales	80	High	Medium	2
Customer Churn	40	High	High	3
Product Analytics	30	Medium	Medium	4
Ad Hoc Reports	10	Low	Varies	5

Rebuild in priority order. This keeps stakeholders engaged and surfaces integration issues early.

Rebuild Dashboards in Superset

Superset dashboards are built from charts (visualisations). Each chart is a SQL query + visualisation configuration. The rebuild process:

1. Create the dataset (if not already done in Phase 2).
2. Build each chart by selecting the dataset, defining filters, and choosing a visualisation type.
3. Configure drill-throughs (if used in Sisense).
4. Add filters and parameters for interactivity.
5. Arrange charts on the dashboard canvas.
6. Test and validate against the Sisense original.

Superset Visualisation Mapping:

Most Sisense chart types map directly to Superset:

Sisense Chart	Superset Equivalent	Notes
Table	Table	Native support
Bar Chart	Bar Chart	Native support
Line Chart	Line Chart	Native support
Pie Chart	Pie Chart	Native support
Scatter Plot	Scatter Plot	Native support
Heatmap	Heatmap	Native support
Pivot Table	Pivot Table	Native support
Gauge	Gauge	Native support
KPI Card	Big Number	Native support
Map	Map (Mapbox)	Requires Mapbox API key
Custom Chart	Custom Plugin	Requires development

For custom Sisense charts, you have three options:

1. Approximate with a standard Superset chart.
2. Build a custom Superset plugin (requires React/JavaScript).
3. Use a third-party Superset plugin from the community.

Most teams find that 80% of dashboards can be rebuilt with native Superset charts. The remaining 20% require custom development or approximation.

Implement Filters and Interactivity

Superset filters work differently from Sisense. In Sisense, filters are cube-level; in Superset, they’re dashboard-level or chart-level.

Common filter patterns:

1. Date Range Filter (Dashboard-Level)

Dashboard Filter → Applies to all charts
Users select a date range (e.g., "Last 90 Days")
Filter is passed to all chart queries via SQL WHERE clause

2. Dimension Filter (Chart-Level)

Chart Filter → Applies only to that chart
Users select a region, product, or customer
Filter is embedded in the chart's SQL query

3. Cross-Filter (Requires Custom Development)

Click a bar in Chart A → Filter Chart B
Superset supports this via native filter plugins, but requires configuration

For most migrations, focus on dashboard-level and chart-level filters. Cross-filters are nice-to-have.

Run Parallel Reporting

Once your top 10 dashboards are rebuilt, run them side-by-side with Sisense for 2–4 weeks. Have analysts compare outputs daily. Document discrepancies:

• Metric mismatches: Debug the dbt model or Superset dataset.
• Performance issues: Optimise the underlying query or add database indexes.
• UI/UX concerns: Adjust chart configurations or dashboard layout.

Parallel reporting is your safety net. It builds confidence and catches bugs before go-live.

---

Phase 4: User Training and Change Management {#phase-4-user-training}

Segment Users by Role

Different users need different training:

Analysts and Data Engineers

• How to write SQL queries in Superset.
• How to build and modify charts.
• How to create dashboards.
• How to use dbt models and understand lineage.
• Superset best practices for performance.

Business Users and Stakeholders

• How to navigate dashboards.
• How to use filters and drill-throughs.
• How to export data.
• Where to find help.

Administrators

• User and role management.
• Database connection configuration.
• Dashboard and dataset permissions.
• Monitoring and alerting.

Create Training Materials

Produce:

1. Video tutorials (5–10 minutes each) for common tasks (filter a dashboard, export data, create a chart).
2. Written guides (1–2 pages) with screenshots for each user role.
3. FAQ document addressing common questions and Sisense-to-Superset comparisons.
4. Glossary of Superset terms (dataset, chart, dashboard, filter, etc.).

Host these on a shared wiki or internal knowledge base. Keep them updated as you learn.

Run Role-Based Training Sessions

Schedule 1-hour sessions for each user group:

• Analysts: Live demo of building a chart, Q&A.
• Business users: Dashboard walkthrough, hands-on filter exercise.
• Admins: System configuration, user management, monitoring.

Record sessions for those who can’t attend. Provide a 2-week grace period where both Sisense and Superset are available.

Establish Support Channels

Set up:

1. Slack channel (#superset-support) for quick questions.
2. Email alias (superset-help@company.com) for formal requests.
3. Weekly office hours where analysts can ask questions in real-time.
4. Escalation path: Tier 1 (Slack), Tier 2 (email), Tier 3 (engineering).

Respond to all questions within 24 hours. Track common issues and update your FAQ.

---

Phase 5: Cutover and Go-Live {#phase-5-cutover}

Plan Your Cutover Window

Choose a low-traffic period (typically a Friday afternoon or Sunday). Notify all users 1–2 weeks in advance.

Cutover checklist:

• All priority dashboards rebuilt and validated.
• All users trained (or trained within 48 hours of go-live).
• Support team on standby.
• Rollback plan documented (can you revert to Sisense if needed?).
• Monitoring and alerting configured.
• Backups of all Superset configurations.

Execute the Cutover

Timeline (Friday 4 PM – Saturday 10 AM):

4:00 PM Friday: Send final notification to all users. Sisense will be offline at 6 PM.

6:00 PM Friday: Deactivate Sisense. Disable all Sisense user accounts. Update DNS or load balancer to point to Superset.

6:15 PM Friday: Test Superset from external network. Verify all dashboards load. Check database connections.

6:30 PM Friday: Send “Go-Live” notification with Superset URL and quick-start guide. Provide support contact.

6:30 PM – 10 PM Friday: Monitor Superset logs, database performance, and user login attempts. Have engineering on call.

Saturday Morning: Check for overnight issues. Review logs. Respond to user questions.

Monday Morning: Full team review. Discuss any issues and plan fixes.

Monitor Performance and Adoption

Track:

• Login success rate: Should be >95% within first week.
• Dashboard load times: Median should be <5 seconds. Investigate any >10 seconds.
• Query performance: Monitor slow queries. Optimise or add indexes.
• User adoption: Track daily active users. Should reach 80%+ of baseline by week 2.
• Support tickets: Track volume and resolution time. Aim for <24-hour resolution.

Create a daily standup dashboard in Superset itself, showing these metrics. This builds confidence and helps you spot issues early.

Plan for Rollback

Have a rollback plan, just in case:

1. Keep Sisense running for 30 days after go-live (in read-only mode if possible).
2. Document the rollback procedure: DNS changes, user account re-activation, etc.
3. Test the rollback in a staging environment before go-live.
4. Define rollback triggers: If >20% of users report critical issues, or if >50% of dashboards fail, consider rollback.

In our experience, rollback is rarely needed if you’ve followed this playbook. But having a plan reduces anxiety and accelerates decision-making if things go wrong.

---

Cost and Timeline Benchmarks {#cost-timeline}

Typical Migration Costs

For a mid-market company (100–500 users, 50–100 dashboards, 5–10 data sources):

Phase	Effort (weeks)	Cost (AUD)	Notes
Assessment & Planning	2	$15K–$25K	Depends on Sisense complexity
Semantic Layer Build	3	$30K–$50K	dbt setup, model development, testing
Dashboard Rebuild	4	$40K–$60K	50–100 dashboards, parallel testing
Training & Support	2	$10K–$15K	Materials, sessions, support ramp
Cutover & Go-Live	1	$5K–$10K	Planning, execution, monitoring
Total	12	$100K–$160K	Assumes 2–3 FTE team

This is a one-time cost. Annual savings from reduced Sisense licensing often exceed this in year one.

Example ROI:

• Sisense cost: $300K/year (60 users × $5K/seat).
• Superset cost: $50K/year (infrastructure, managed service, or Preset subscription).
• Year 1 savings: $250K – $100K (migration cost) = $150K net.
• Payback period: 5 months.

Timeline Compression

You can compress the timeline by:

1. Parallel work: Run assessment and semantic layer build simultaneously.
2. Phased go-live: Migrate user groups sequentially rather than all at once.
3. Automation: Use scripts to export Sisense metadata and auto-generate Superset configurations (requires custom tooling).
4. Outsourced support: Engage a venture studio or platform engineering partner to accelerate build and validation.

With aggressive parallelisation, you can compress the timeline to 6–8 weeks. However, this increases risk and cost.

---

Common Pitfalls and How to Avoid Them {#common-pitfalls}

Pitfall 1: Underestimating Semantic Layer Complexity

Problem: Sisense cubes look simple until you try to rebuild them. Calculated fields, hierarchies, and filters often hide complex business logic.

Solution: Allocate 3–4 weeks for semantic layer work, not 1–2. Involve business analysts in validation. Test early and often.

Pitfall 2: Rebuilding Every Dashboard

Problem: Teams try to rebuild 100% of dashboards, even ones with 2 users. This wastes time and delays go-live.

Solution: Prioritise ruthlessly. Rebuild dashboards covering 80% of user traffic. Retire or archive the rest. You can always rebuild low-impact dashboards post-go-live.

Pitfall 3: Ignoring Performance Tuning

Problem: Dashboards work in testing but slow down under production load. Users complain about 30-second load times.

Solution: Implement performance tuning early. Use Superset’s caching and query optimisation features. Monitor query performance in Phase 3. Add database indexes before go-live.

Pitfall 4: Weak Change Management

Problem: Users aren’t trained. They don’t know how to use Superset. Support tickets spike. Adoption stalls.

Solution: Invest in training. Run sessions for each user group. Provide written guides and videos. Establish support channels. Plan for a 2-week ramp period.

Pitfall 5: Losing Institutional Knowledge

Problem: Key dashboards rely on undocumented Sisense logic. When you rebuild in Superset, you lose that context.

Solution: Document everything as you go. Create a data dictionary. Use dbt to version-control your semantic layer. Include comments in SQL queries. This is boring but saves months of troubleshooting later.

Pitfall 6: Rushing the Cutover

Problem: You’re behind schedule, so you cut over before validation is complete. Critical dashboards fail. Users panic. You scramble to fix issues.

Solution: Stick to the timeline. Don’t compress validation. Run parallel reporting for 2–4 weeks. Have a rollback plan. Better to launch late and stable than early and broken.

---

Next Steps: Getting Started {#next-steps}

Assess Your Current State

Start with a 2-week discovery phase. Document:

1. All Sisense assets: Cubes, dashboards, data sources, users.
2. Business priorities: Which dashboards matter most?
3. Technical constraints: Database access, API permissions, security requirements.
4. Team capacity: Who will lead the migration? What’s their availability?

If you need external support, consider engaging a partner with Superset expertise. At PADISO, we’ve led 15+ BI platform migrations across Australia and North America. We can accelerate your assessment and provide a detailed migration roadmap.

Choose Your Semantic Layer Strategy

Decide: SQL views, dbt, Superset datasets, or hybrid?

For most teams, dbt is the best choice. It provides version control, testing, and documentation. If you’re already using dbt, the decision is easy. If not, allocate 1–2 weeks to set it up.

For guidance on data platform modernisation and semantic layer design, explore PADISO’s platform engineering services. We specialise in helping teams build scalable, maintainable data architectures.

Build a Cross-Functional Team

You’ll need:

• 1 analytics lead: Owns dashboard priorities and user training.
• 1–2 data engineers: Build dbt models, validate metrics, optimise queries.
• 1 platform engineer: Manages Superset infrastructure, database connections, security.
• 1 project manager: Tracks timeline, manages risks, coordinates communication.

If you don’t have this capacity in-house, a fractional CTO or external partner can fill gaps. PADISO’s CTO as a Service offering provides exactly this kind of technical leadership.

Plan Your Rollout

Define:

1. Go-live date: Aim for 10–12 weeks from project start.
2. User groups: Phase 1 (analysts and power users), Phase 2 (business users), Phase 3 (executives).
3. Support model: Who handles questions? What’s the SLA?
4. Success metrics: Dashboard load time, user adoption rate, support ticket volume.

Prepare for Post-Migration Optimisation

Migration is the beginning, not the end. Plan for:

1. Performance tuning: Identify slow queries. Add indexes. Optimise dashboard queries.
2. Feature enablement: Once users are comfortable, introduce advanced features (alerts, scheduled exports, embedded analytics).
3. Continuous improvement: Retire unused dashboards. Consolidate similar reports. Invest in self-service analytics.

If you’re pursuing embedded analytics or advanced Superset features, PADISO’s platform engineering team can help you build production-grade, multi-tenant analytics platforms.

Security and Compliance

If you’re in a regulated industry (financial services, healthcare, insurance), ensure your Superset deployment meets compliance requirements:

• SOC 2 Type II: Superset should be deployed with audit logging, encryption at rest and in transit, and role-based access control.
• ISO 27001: Implement information security management practices around Superset (access controls, data classification, incident response).
• GDPR/Privacy: Ensure data residency and user consent are documented.

For guidance on security audit readiness and compliance, PADISO’s security audit service helps teams achieve SOC 2 and ISO 27001 certification via Vanta. We can advise on Superset-specific security configurations.

---

Conclusion

Migrating from Sisense to Apache Superset is a well-understood process. With proper planning, a structured approach, and realistic timelines, you can execute a migration in 10–12 weeks with minimal disruption.

The key is to prioritise ruthlessly, validate obsessively, and invest in change management. Don’t try to rebuild every dashboard. Focus on the ones that matter. Run parallel reporting to catch bugs. Train users thoroughly. Have a rollback plan.

If you follow this playbook, you’ll reduce costs, improve flexibility, and modernise your data stack. You’ll also build institutional knowledge and best practices that serve you for years.

For teams in Australia or North America pursuing BI modernisation, PADISO offers fractional CTO leadership and platform engineering support. We can guide your migration, build your semantic layer, and help you optimise Superset for scale. Book a call to discuss your migration roadmap.

Your analytics team will thank you. Your CFO will definitely thank you.