Tableau to Apache Superset: A 90-Day Migration Plan

Table of Contents

1. Executive Summary
2. Why Migrate from Tableau to Apache Superset
3. Pre-Migration Assessment (Weeks 1–2)
4. Infrastructure & Environment Setup (Weeks 3–4)
5. Data Source Migration (Weeks 5–6)
6. Dashboard & Calc Field Translation (Weeks 7–10)
7. Testing, Validation & UAT (Weeks 11–12)
8. Cutover Strategy & Go-Live (Week 13)
9. Risk Register & Mitigation
10. Post-Migration Support & Optimisation
11. Next Steps

---

Executive Summary

Migrating from Tableau Server to Apache Superset via D23.io’s managed platform is a strategic move that reduces licensing costs by 60–80%, increases flexibility through open-source architecture, and eliminates vendor lock-in. However, it requires disciplined planning, data mapping, and stakeholder alignment across 13 weeks.

This guide provides a realistic, week-by-week roadmap covering data source inventory, dashboard translation, calculated field logic preservation, user acceptance testing (UAT), and a detailed risk register. We’ll walk through the technical and organisational challenges that catch most teams off guard—and how to avoid them.

The outcome: a fully operational Apache Superset environment with zero dashboard downtime, validated data lineage, and a trained user base ready to query and iterate on analytics independently.

---

Why Migrate from Tableau to Apache Superset

Before diving into the plan, let’s establish the business case. Tableau’s annual licensing costs for mid-market deployments typically run $200K–$500K+ per year. Apache Superset, deployed on D23.io’s managed infrastructure, costs a fraction of that—often a fixed $50K engagement fee plus modest cloud hosting.

Beyond cost, Superset offers:

• Open-source transparency: Full visibility into query logic, no black-box calculations.
• Semantic layer flexibility: Use dbt or custom SQL to define metrics once, reuse everywhere.
• Integration with modern data stacks: Native support for Snowflake, BigQuery, PostgreSQL, and data warehouses that Tableau charges premium connectors for.
• Agentic AI readiness: As explored in our guide on agentic AI with Apache Superset, Superset’s API-first design makes it trivial to let Claude or other LLMs query dashboards programmatically—something Tableau doesn’t support natively.

However, migration is not a lift-and-shift. Tableau and Superset have different data models, permission systems, and dashboard composition logic. A rushed migration leaves teams with broken dashboards, duplicated effort, and frustrated users.

---

Pre-Migration Assessment (Weeks 1–2)

Weeks 1–2: Inventory and Dependency Mapping

The first two weeks are entirely non-technical. Your goal is to understand what you’re moving and why each piece matters.

Step 1: Audit Your Tableau Estate

Export a complete inventory of your Tableau Server:

• Workbooks: Count, owner, last-accessed date, embedded vs. published data sources.
• Data sources: List all connections (databases, APIs, files), refresh schedules, row-level security (RLS) rules.
• Calculated fields: Document all custom logic, especially date logic, string manipulation, and aggregations.
• Permissions: Map workbook and data source access by user role and group.
• Extracts: Identify which data sources use Tableau extracts vs. live connections.

Use Tableau Server’s REST API or the Tableau Help documentation on migration planning to automate this. A spreadsheet with columns for workbook name, owner, data source, refresh frequency, and criticality is your baseline.

Realistic effort: 2–3 days for a mid-market deployment (50–200 workbooks).

Step 2: Prioritise Dashboards by Business Impact

Not every dashboard is equally important. Segment your workbooks:

• Tier 1 (Critical): Daily decision-making dashboards (sales pipeline, operational metrics, financial reporting). These must migrate first and be rock-solid.
• Tier 2 (Important): Weekly or monthly reporting, ad-hoc analysis dashboards. These can migrate in phase 2.
• Tier 3 (Nice-to-have): Exploratory, historical, or archived dashboards. Candidates for decommissioning.

Focus your 90-day window on Tier 1 and Tier 2. Tier 3 can follow post-go-live or be retired entirely.

Step 3: Identify Data Source Dependencies

Draw a map of which dashboards depend on which data sources. Often, 20% of data sources power 80% of dashboards. Prioritise migration of:

• High-cardinality data sources (used by many dashboards).
• Data sources with complex calculated fields or RLS rules.
• Slowly-changing dimensions that require refresh logic.

Step 4: Document Calculated Fields and Custom Logic

Tableau’s calculated fields are a common pain point. Create a spreadsheet listing:

• Calculated field name
• Formula (copy directly from Tableau)
• Data type (string, date, number, boolean)
• Where it’s used (which dashboards/data sources)
• Complexity (simple arithmetic vs. complex LOD expressions)

Tableau’s LOD (Level of Detail) expressions—FIXED, INCLUDE, EXCLUDE—don’t map directly to SQL or Superset. You’ll need to translate these into SQL window functions or semantic layer logic. This is often the longest part of migration.

Example translation:

• Tableau: {FIXED [Customer ID] : SUM([Revenue])}
• Superset SQL: SUM(revenue) OVER (PARTITION BY customer_id)

Step 5: Stakeholder Alignment Workshop

Host a 2-hour workshop with:

• CFO / finance leadership (cost justification, timeline expectations)
• Data team lead (data source ownership, refresh SLAs)
• BI/analytics lead (dashboard prioritisation, training scope)
• IT/security (infrastructure, SSO, compliance)
• Key business users (Tier 1 dashboard owners)

Cover:

• Why we’re migrating (cost, flexibility, strategic roadmap)
• What will change (UI, query performance, permission model)
• Timeline and risks
• Support model post-go-live
• Training schedule

Document decisions and get sign-off on prioritisation.

---

Infrastructure & Environment Setup (Weeks 3–4)

Weeks 3–4: Build Your Superset Environment

While the data team finalises the inventory, your infrastructure team provisions the Superset environment. This is where D23.io’s managed platform accelerates delivery—they handle networking, security, and baseline configuration. If you’re self-hosting, follow the official Apache Superset installation guide.

Step 1: Provision Cloud Infrastructure

If using D23.io or a similar managed service, they’ll handle this. If self-hosting:

• Compute: Superset runs on Python/Flask. A t3.medium AWS EC2 or equivalent handles 50–100 concurrent users. Larger deployments need auto-scaling.
• Database: Superset metadata lives in PostgreSQL or MySQL. Use a managed RDS instance (AWS) or Cloud SQL (GCP) for high availability.
• Cache: Redis for query caching and session management. Reduces load on your data warehouse.
• Reverse proxy: Nginx or AWS ALB for SSL termination and load balancing.

Step 2: Configure Single Sign-On (SSO)

Superset integrates with OAuth2, SAML, and LDAP. Map your Tableau Server permission groups to Superset roles:

• Admin: Full access to all dashboards, data sources, and configuration.
• Editor: Can create and modify dashboards, but not manage data sources.
• Viewer: Read-only access to assigned dashboards.

If you used Tableau Server’s Active Directory integration, configure Superset’s LDAP connector to pull the same groups. This avoids manual permission re-assignment.

Step 3: Set Up Data Source Connections

In Superset, create database connections to all your data sources. Unlike Tableau, Superset connects directly to your database—no extracts by default (though you can cache query results in Redis).

For each data source:

• Test the connection from Superset to the database.
• Verify query performance: run a simple SELECT COUNT(*) and confirm latency < 5 seconds.
• Document the connection string (host, port, database, credentials).
• Set up a dedicated Superset service account with read-only access to required schemas.

Security note: Store credentials in Superset’s secrets manager (encrypted in the metadata database). Never hardcode passwords in connection strings.

Step 4: Install and Configure Plugins

Superset’s plugin ecosystem extends functionality. For a Tableau migration, consider:

• Semantic layer plugins: If using dbt, install the dbt Cloud integration to expose metrics.
• Custom visualisations: If Tableau dashboards use custom viz types, check if Superset plugins exist (e.g., Echarts, Apache ECharts).
• Authentication plugins: SAML, OAuth2, or custom plugins for legacy SSO systems.

Test plugins in a non-production environment first.

Step 5: Establish Backup and Disaster Recovery

Superset metadata (dashboards, data sources, saved queries) lives in the metadata database. Back it up daily:

pg_dump superset_metadata > superset_backup_$(date +%Y%m%d).sql

Store backups in S3 or equivalent, with a 30-day retention policy. Test restore procedures monthly.

---

Data Source Migration (Weeks 5–6)

Weeks 5–6: Migrate and Validate Data Sources

Now that infrastructure is ready, migrate data source connections. This is largely mechanical but requires validation.

Step 1: Migrate Database Connections

For each Tableau data source:

1. Create a matching database connection in Superset.
2. Run a test query to confirm the connection works.
3. Document the connection in a migration tracker (source name, target connection, status, notes).

If a Tableau data source uses an extract (a cached .tde or .hyper file), you have two options:

• Option A: Refresh the extract in Tableau, export to CSV, and load into a staging table in your data warehouse. Then connect Superset to that table.
• Option B: Identify the underlying database (often hidden from Tableau users) and connect Superset directly to it, bypassing the extract entirely. This is faster and reduces data staleness.

Recommendation: Choose Option B wherever possible. It simplifies the architecture and improves data freshness.

Step 2: Validate Data Lineage

For each migrated data source, run a row count and sample query in both Tableau and Superset. Compare results:

-- In Tableau: Run a simple query
SELECT COUNT(*) FROM [Data Source]

-- In Superset: Run the same query
SELECT COUNT(*) FROM schema.table

Row counts must match exactly. If they don’t, investigate:

• Are there row-level security (RLS) filters applied in Tableau? Superset won’t inherit these automatically.
• Does the Tableau data source have a custom SQL query? You’ll need to replicate that SQL in Superset.
• Are there extract refresh schedules that lag behind the source? Ensure both systems query the same point-in-time data.

Step 3: Document Calculated Fields and Metrics

Create a detailed spreadsheet of all calculated fields from Tableau, mapping each to Superset. For complex calculations, you have three options:

1. SQL-based metrics: Define in Superset’s metric editor as SQL expressions.
2. Semantic layer (dbt): Define once in dbt, expose as metrics, reuse across all dashboards.
3. Dashboard-level calculations: Define in the dashboard itself (less ideal, but acceptable for one-off calcs).

Best practice: Use the semantic layer for any metric used in more than one dashboard. This ensures consistency and reduces maintenance burden.

Step 4: Test Refresh Schedules

If Tableau extracts refresh on a schedule (e.g., daily at 6 AM), ensure equivalent refresh logic exists in Superset:

• For database queries, Superset caches results in Redis. Set cache TTL (time-to-live) to match your refresh frequency.
• For aggregated tables in the data warehouse, ensure those tables refresh on schedule (usually via dbt or Airflow).

Test a refresh cycle end-to-end. Confirm data updates appear in Superset dashboards within your target SLA (e.g., within 1 hour of source update).

Step 5: Audit Permissions and Row-Level Security

Tableau’s RLS filters data based on user identity. Superset doesn’t have built-in RLS, but you can implement it via:

• Database-level RLS: Configure RLS in your data warehouse (PostgreSQL, Snowflake, BigQuery all support this). Superset queries inherit the RLS rules.
• Superset datasets: Create separate datasets with pre-filtered data for sensitive views, then assign permissions to specific roles.

For each Tableau data source with RLS:

1. Identify the RLS rule (e.g., “Sales reps see only their region’s data”).
2. Implement equivalent logic in your data warehouse or Superset dataset.
3. Test as a non-admin user to confirm filtering works.

---

Dashboard & Calc Field Translation (Weeks 7–10)

Weeks 7–10: Rebuild Dashboards in Superset

This is the longest phase. You’re not copying dashboards—you’re translating them. Tableau and Superset have different design paradigms.

Understanding the Differences

Tableau dashboards are worksheet-centric. You build worksheets (individual charts), then arrange them on a dashboard canvas. Worksheets are reusable, and filters cascade across them.

Superset dashboards are chart-centric. Each chart is independent, with its own SQL query. Filters are dashboard-level, but require explicit linking to chart parameters.

This means:

• A Tableau workbook with 5 worksheets might become 5+ Superset charts on a single dashboard.
• Tableau’s parameter actions (interactive filters) need to be recreated as Superset’s “Cross Filter” or “Select Filter” features.
• Tableau’s level of detail (LOD) calculations must be translated to SQL window functions or aggregations.

Step 1: Chart-by-Chart Translation

For each Tier 1 dashboard:

1. Identify all worksheets and their data sources.
2. Extract the SQL logic: What dimensions and measures does each worksheet show? What aggregations are applied?
3. Recreate in Superset: Build a Superset chart with equivalent SQL and visualisation type.
4. Match the look and feel: Colours, axis labels, legends, number formatting.

Example: Sales Pipeline Dashboard

Tableau worksheet: “Pipeline by Stage”

• Dimensions: Deal Stage (Prospect, Qualified, Negotiation, Closed)
• Measure: SUM(Deal Value)
• Visualisation: Horizontal bar chart
• Filter: Year = 2024

Superset equivalent:

SELECT 
  deal_stage,
  SUM(deal_value) AS total_value
FROM deals
WHERE YEAR(deal_date) = 2024
GROUP BY deal_stage
ORDER BY total_value DESC

Then configure the Superset chart:

• Visualisation type: Horizontal Bar Chart
• X-axis: total_value
• Y-axis: deal_stage
• Colour scheme: Match Tableau’s palette

Step 2: Translate Calculated Fields

For each calculated field in Tableau, determine its equivalent in Superset:

Simple arithmetic: Translate directly to SQL.

• Tableau: [Revenue] - [Cost]
• Superset: revenue - cost (in the SQL query)

Date logic: Use SQL date functions.

• Tableau: DATEDIFF('day', [Order Date], [Ship Date])
• Superset: EXTRACT(DAY FROM ship_date - order_date) or DATE_DIFF(ship_date, order_date, 'day')

String manipulation: Use SQL string functions.

• Tableau: LEFT([Product Name], 5)
• Superset: SUBSTRING(product_name, 1, 5)

Conditional logic: Use CASE statements.

• Tableau: IF [Profit Ratio] > 0.2 THEN "High" ELSE "Low" END
• Superset: CASE WHEN profit_ratio > 0.2 THEN 'High' ELSE 'Low' END

Aggregations with filters (LOD in Tableau): Use window functions or subqueries.

• Tableau: {FIXED [Region] : SUM([Revenue])}
• Superset: SUM(revenue) OVER (PARTITION BY region) or a subquery in the FROM clause.

For complex LOD expressions, consider moving them to the semantic layer (dbt) so they’re defined once and reused across dashboards.

Step 3: Implement Dashboard Filters and Parameters

Tableau’s parameters allow users to dynamically change values (e.g., “Show top N products”). Superset’s equivalent is the “Select Filter” or “Filter Box”.

Example: Top N Products Filter

Tableau:

1. Create a parameter: “Top N” (integer, default 10, range 1–50)
2. Create a calculated field: RANK() <= [Top N]
3. Add the parameter to the dashboard filter.

Superset:

1. Create a “Select Filter” with name “Top N” and type “Integer Slider”.
2. In the chart’s SQL, use a subquery:

   WITH ranked_products AS (
     SELECT 
       product_name,
       SUM(revenue) AS total_revenue,
       ROW_NUMBER() OVER (ORDER BY SUM(revenue) DESC) AS rank
     FROM sales
     GROUP BY product_name
   )
   SELECT * FROM ranked_products
   WHERE rank <= {{ top_n_filter }}  -- Reference the filter

3. Link the filter to the chart by setting its “Adhoc Filter” or embedding it in the SQL.

Step 4: Recreate Interactivity

Tableau dashboards often have interactive elements:

• Filters that cascade across worksheets (clicking a region filters all charts).
• Drill-down (clicking a bar expands to show detail).
• Highlighting (hovering over one chart highlights related data in others).

Superset’s interactivity model is simpler:

• Cross Filter: Clicking a value in one chart filters others (requires explicit configuration).
• Drill-down: Not natively supported; instead, create separate dashboards for detail views and link via dashboard tabs.
• Highlighting: Limited; focus on clear visual hierarchy and colour coding instead.

Recommendation: Simplify interactivity during migration. Complex Tableau dashboards often have UX debt. Use Superset as an opportunity to redesign for clarity.

Step 5: Test Each Dashboard

Once a Tier 1 dashboard is rebuilt:

1. Functional testing: Verify all charts load, filters work, and data is correct.
2. Performance testing: Run the dashboard, measure query times. Aim for < 5 seconds to load all charts.
3. Visual testing: Compare side-by-side with Tableau. Colours, formatting, and layout should match closely.
4. User acceptance testing: Have the dashboard owner (Tier 1 owner) review and sign off.

Performance troubleshooting:

• If a chart is slow, optimise the SQL: add indexes, simplify joins, reduce data volume.
• Use Superset’s query cache to avoid re-running identical queries.
• Consider materialised views in the data warehouse for commonly-queried aggregations.

---

Testing, Validation & UAT (Weeks 11–12)

Weeks 11–12: Comprehensive Testing and User Acceptance Testing

With all Tier 1 dashboards rebuilt, conduct rigorous testing before go-live.

Step 1: Data Validation Testing

Compare data in Tableau and Superset side-by-side for every Tier 1 dashboard:

1. Pick a date range (e.g., last 30 days).
2. Export key metrics from Tableau and Superset.
3. Compare row-by-row: Totals, subtotals, filtered views.
4. Document discrepancies: If a number differs, investigate:
   • Are both systems querying the same data source?
   • Is there a filter or RLS rule applied in one but not the other?
   • Is the aggregation logic identical (SUM vs. AVG, COUNT vs. COUNT DISTINCT)?

Create a sign-off document listing all validated dashboards and any known differences (with explanations).

Step 2: Performance Testing

Load test Superset with realistic user concurrency:

• If Tableau typically has 20 concurrent users during business hours, simulate 20 concurrent users accessing Superset dashboards.
• Measure response times, CPU, memory, and database query load.
• Identify bottlenecks and optimise.

Tools: Apache JMeter, Locust, or cloud provider load testing services.

Step 3: User Acceptance Testing (UAT)

Invite 5–10 power users from each Tier 1 dashboard team to UAT. Provide:

• Access to the Superset environment.
• A UAT script (step-by-step instructions for testing each dashboard).
• A feedback form (bugs, missing features, performance issues).

UAT script example:

1. Log in with your Tableau credentials (SSO).
2. Open the “Sales Pipeline” dashboard.
3. Verify the total pipeline value matches the Tableau version.
4. Apply the “Region” filter to “North America” and confirm only NA deals appear.
5. Click on a deal stage to drill down (or note if drill-down is unavailable).
6. Export the dashboard to PDF and verify formatting.

Collect feedback over 3–5 days. Prioritise bugs and critical missing features for fix before go-live. Non-critical feedback goes to a post-go-live backlog.

Step 4: Security and Compliance Testing

Verify:

• SSO works: Users can log in with their corporate credentials.
• Permissions are enforced: A user assigned to “Viewer” role cannot create dashboards. A user without access to a dashboard cannot view it.
• Audit logging is enabled: Superset logs all dashboard views, filter changes, and data exports.
• Data encryption is in place: Connections to the data warehouse use SSL/TLS. Superset metadata is encrypted at rest.
• Secrets are not exposed: Database passwords and API keys are stored securely, not visible in logs or UI.

If your organisation requires SOC 2 or ISO 27001 compliance, leverage Superset’s audit-readiness features to document security controls. Superset’s API and logging capabilities make it straightforward to integrate with compliance platforms like Vanta.

Step 5: Training and Documentation

During UAT, create user documentation:

1. Getting Started Guide: How to log in, navigate dashboards, apply filters.
2. Dashboard Reference: For each Tier 1 dashboard, explain what it shows, how to interpret it, and how to export data.
3. FAQ: Common questions (“Why is this number different from Tableau?” “How do I request a new dashboard?”).
4. Video tutorials: Screen recordings of common tasks (filtering, exporting, creating a new chart).

Hold a 1-hour live training session with all Tier 1 users. Record it for those who can’t attend.

---

Cutover Strategy & Go-Live (Week 13)

Week 13: Execute the Cutover

Cutover is the moment you switch users from Tableau to Superset. Plan it carefully to minimise disruption.

Step 1: Cutover Approach

Choose one of three strategies:

Option A: Big Bang (Recommended for small estates < 50 dashboards)

• On a Friday evening or weekend, disable Tableau Server.
• Enable Superset for all users.
• Be prepared for a 24–48 hour support surge.

Option B: Phased (For larger estates or risk-averse organisations)

• Week 1: Tier 1 dashboards go live on Superset. Tableau remains available for Tier 2 and Tier 3.
• Week 2: Tier 2 dashboards go live. Tier 3 remains on Tableau.
• Week 3: Tier 3 migrated or decommissioned.

Option C: Parallel (Lowest risk, highest cost)

• Run Tableau and Superset side-by-side for 2–4 weeks.
• Users gradually migrate at their own pace.
• After 4 weeks, decommission Tableau.

For a 90-day timeline, Option A (Big Bang) is most realistic. Ensure you have a rollback plan: keep Tableau running in read-only mode for 2 weeks post-cutover, in case you need to revert.

Step 2: Cutover Checklist

One week before cutover:

• All Tier 1 dashboards rebuilt and UAT-signed off.
• Data validation complete (numbers match Tableau).
• SSO tested and working.
• Training completed and recorded.
• Superset infrastructure scaled to handle peak load.
• Backup and disaster recovery tested.
• Support team trained (how to reset passwords, troubleshoot dashboard issues).
• Stakeholder communication plan finalised (email templates, status page).

Day before cutover:

• Final data refresh in Superset (ensure latest data is loaded).
• Database connections tested.
• Superset metadata backed up.
• Tableau Server backed up (for rollback).
• Support team on standby.

Cutover day:

• Send user communication: “Tableau will be offline at 6 PM Friday. Superset goes live at 7 PM.”
• At scheduled time, disable Tableau Server (or set to read-only).
• Verify Superset is healthy (all dashboards load, no errors).
• Send follow-up communication: “Superset is now live. Here’s how to log in.”
• Monitor Superset for errors, slow queries, and user issues.

First 48 hours post-cutover:

• Support team monitors Superset logs for errors.
• Have a senior engineer on call for critical issues.
• Collect user feedback and prioritise urgent fixes.
• If critical issues arise (data corruption, widespread outages), trigger rollback to Tableau.

Step 3: Rollback Plan

If Superset fails catastrophically post-cutover:

1. Notify all users: “We’ve encountered an issue. Tableau is being restored. ETA: 30 minutes.”
2. Restore Tableau from backup: Use the backup taken pre-cutover.
3. Investigate root cause: Why did Superset fail? Database connection? Query performance? Permissions?
4. Fix and retry: Schedule a new cutover for the following week after fixes are validated.

Realistic rollback time: 30–60 minutes. Have a detailed runbook and test it in advance.

Step 4: Post-Cutover Stabilisation (Week 13–14)

After go-live, expect a support surge:

• Users forget passwords or have SSO issues.
• Dashboards load slowly (need query optimisation).
• A calculated field is wrong (need to debug and fix).
• Users ask how to export data or create a new dashboard.

Allocate 40% of your team’s capacity to support for the first 2 weeks. Create a ticketing system (Jira, Linear, Zendesk) to track issues and resolutions.

Common post-cutover issues and fixes:

Issue	Root Cause	Fix
Dashboard loads slowly	Slow SQL query	Optimise query, add database indexes, reduce data volume
”Permission denied” error	User not assigned to dashboard role	Assign user to correct role in Superset
Numbers don’t match Tableau	Calculated field logic error	Review SQL, compare with Tableau formula, fix
SSO not working	LDAP/SAML misconfiguration	Test SSO connection, verify group mappings
Data is stale	Cache TTL too long or refresh schedule missed	Reduce cache TTL, verify data warehouse refresh

---

Risk Register & Mitigation

Migration carries risks. Here’s a detailed risk register with mitigation strategies.

High-Risk Items

Risk	Probability	Impact	Mitigation
Data discrepancy between Tableau and Superset	High	High	Conduct row-by-row data validation for all Tier 1 dashboards pre-cutover. Document any differences. Have a data engineer review calculations.
Slow query performance in Superset	Medium	High	Load test dashboards with realistic data volume. Optimise SQL queries. Add database indexes. Use Superset’s query cache.
SSO integration fails at cutover	Medium	High	Test SSO with 10+ users in UAT. Have a local admin account as fallback. Brief support team on manual user provisioning.
Key calculated fields lost or incorrect	Medium	High	Document all Tableau calculated fields before migration. Translate each to SQL and test independently. Have a subject matter expert review.
Users resist Superset, demand return to Tableau	Medium	Medium	Invest in training and change management. Highlight benefits (cost, flexibility, agentic AI readiness). Gather feedback early and iterate.

Medium-Risk Items

Risk	Probability	Impact	Mitigation
Tier 2 dashboards not completed by cutover	Medium	Medium	Prioritise ruthlessly. Defer non-critical Tier 2 dashboards to post-go-live. Have a backlog and timeline.
Superset infrastructure not scaled for peak load	Low	High	Load test with 1.5x peak concurrent users. Auto-scale compute and database. Monitor CPU/memory during cutover.
Row-level security (RLS) rules not replicated	Medium	Medium	Audit Tableau RLS rules early. Test RLS in Superset as non-admin users. Document any gaps and mitigations.
Backup/disaster recovery not tested	Low	High	Test restore procedures monthly in staging. Document runbook. Have a senior DBA on call.

Low-Risk Items

Risk	Probability	Impact	Mitigation
Tier 3 dashboards not migrated	Low	Low	Accept this. Decommission or archive Tier 3 dashboards. Document what was retired and why.
Custom visualisations not available in Superset	Low	Low	Use Superset’s built-in viz types or install plugins. If unavailable, recreate as standard charts or export data for manual viz.
Superset plugin compatibility issues	Low	Medium	Test all plugins in staging before production. Have fallback viz types if plugins fail.

---

Post-Migration Support & Optimisation

Weeks 14–16: Stabilise and Optimise

After cutover, shift focus from migration to optimisation and adoption.

Step 1: Query Performance Tuning

Now that you have real usage data, identify slow queries:

1. Enable Superset’s query logging (logs all SQL queries and execution time).
2. Export query logs and analyse for slow queries (> 10 seconds).
3. For each slow query, optimise:
   • Add database indexes on frequently-filtered columns.
   • Rewrite joins to reduce cardinality.
   • Create materialised views for complex aggregations.
   • Move calculations to the semantic layer (dbt) if reused across dashboards.

Step 2: Adopt Agentic AI Integration

With Superset live, consider integrating agentic AI to let users query dashboards naturally. For example:

• Enable Superset’s API and expose it to Claude or another LLM.
• Users can ask questions in plain English (“What’s the pipeline value for Q4?”) and Claude queries Superset, returning results.
• This reduces dependency on pre-built dashboards and empowers self-service analytics.

Implementing agentic AI is a natural next step post-migration, especially for organisations looking to modernise their data stack further.

Step 3: Gather Feedback and Iterate

After 2–4 weeks, survey users:

• What’s working well?
• What’s confusing or missing?
• Are there dashboards they need that don’t exist yet?

Prioritise feedback into:

• Quick wins (< 1 day to implement): Fix a label, adjust a colour, add a missing filter.
• Medium-term (1–2 weeks): Rebuild a dashboard with better UX, add a new chart.
• Backlog (post-migration): Nice-to-haves, exploratory features.

Step 4: Decommission Tableau

Once Superset is stable and users are confident:

1. Set a decommission date (e.g., 4 weeks post-cutover).
2. Announce it widely and give users time to verify they have access to equivalent Superset dashboards.
3. Export any remaining Tier 3 dashboards to PDF for archival.
4. Shut down Tableau Server and cancel licenses.
5. Document the migration (lessons learned, what went well, what to improve next time).

---

Next Steps

A 90-day Tableau-to-Superset migration is ambitious but achievable with disciplined planning. Here’s your immediate action plan:

Week 1: Kick Off

1. Assemble a migration team: Data engineer, BI lead, IT/infrastructure, business stakeholder.
2. Audit your Tableau estate: Run the inventory steps outlined in Weeks 1–2.
3. Engage D23.io or a managed Superset provider: Get infrastructure and baseline configuration set up in parallel.
4. Schedule stakeholder alignment workshop: Secure buy-in on timeline, prioritisation, and success metrics.

Parallel Work: Infrastructure

While your team inventories Tableau, provision Superset infrastructure (Weeks 3–4). This removes a critical path dependency.

Weeks 5–13: Execution

Follow the plan outlined above: data source migration, dashboard translation, testing, and cutover. Adjust timelines based on your estate size and complexity.

Beyond Week 13: Optimisation

Post-cutover, focus on performance tuning, user adoption, and exploring advanced features like agentic AI integration with Superset.

Why Partner with PADISO

If you’re a Sydney-based founder or operator managing this migration, consider partnering with PADISO for fractional CTO leadership and co-build support. We’ve executed similar migrations for mid-market companies, and we can accelerate your timeline while reducing risk.

Our AI & Agents Automation service also positions Superset for next-generation analytics—letting your team query dashboards via natural language and automate reporting workflows. Combined with AI Automation for E-commerce or AI Automation for Retail, Superset becomes a strategic data asset, not just a BI tool.

For security-conscious teams, we also handle SOC 2 and ISO 27001 compliance as part of infrastructure setup, ensuring your Superset deployment is audit-ready from day one.

Final Checklist

Before you go live, confirm:

• All Tier 1 dashboards rebuilt and UAT-signed off.
• Data validation complete (numbers match Tableau).
• SSO configured and tested.
• Backup and disaster recovery tested.
• Support team trained.
• Rollback plan documented and rehearsed.
• User training completed.
• Cutover communication plan finalised.
• Post-cutover support allocated (40% team capacity for 2 weeks).

You’re ready to migrate. Good luck, and welcome to the Superset ecosystem.