Migrating from Tableau to Apache Superset: A D23.io Playbook

Table of Contents

1. Why Migrate from Tableau to Apache Superset?
2. Pre-Migration Assessment and Planning
3. Data Source Remapping Strategy
4. Dashboard and Workbook Redesign
5. User Training and Change Management
6. Cutover Planning and Execution
7. Post-Migration Optimisation
8. Common Pitfalls and How to Avoid Them
9. Real Timeline and Effort Estimates
10. Next Steps and Governance

---

Why Migrate from Tableau to Apache Superset?

Tableau is powerful. It’s also expensive. Many mid-market and enterprise organisations find themselves paying six figures annually for Tableau licences, infrastructure, and support—only to discover that 60% of their dashboards sit unused and their data pipeline costs have spiralled out of control.

Apache Superset offers a compelling alternative. It’s open-source, self-hosted, and dramatically cheaper to operate at scale. But “cheaper” isn’t the real win. The real win is control.

When you move to Superset, you own your BI infrastructure. You control your data flow. You eliminate vendor lock-in. And you can integrate directly with your modern data stack—dbt, Airflow, Snowflake, BigQuery, Postgres, whatever you’re running.

At PADISO, we’ve helped Sydney-based startups and mid-market operators execute this migration successfully. The teams that move fast—4 to 8 weeks for a full cutover—do three things right: they prioritise ruthlessly, they automate what they can, and they treat it like a product launch, not an IT project.

This guide walks you through the exact playbook we use. It covers data source remapping, dashboard rebuilds, user training, and cutover execution. We’ll give you realistic timelines, effort estimates, and the hard-won lessons that prevent migration disasters.

---

Pre-Migration Assessment and Planning

Audit Your Current Tableau Estate

Before you move a single dashboard, you need to understand what you’re actually moving. Many organisations have never done a full audit of their Tableau instance. They discover, mid-migration, that they have 300 dashboards, 150 of which are abandoned, 80 are broken, and 70 are duplicates.

Start here:

Step 1: Inventory all assets. Export a complete list of workbooks, dashboards, sheets, data sources, and users from your Tableau Server or Tableau Cloud instance. Use the Tableau Server Client (TSC) library or Tableau’s REST API to automate this. Record:

• Dashboard name and owner
• Last accessed date
• Number of views per month
• Data source dependencies
• Filters, parameters, and calculated fields
• Embedded content or custom extensions

Step 2: Classify by criticality. Not all dashboards are equal. Tier them:

• Tier 1 (Critical): Executive dashboards, revenue tracking, operational dashboards used daily by 10+ people.
• Tier 2 (Important): Team dashboards, used 2–3 times per week, inform decisions but aren’t mission-critical.
• Tier 3 (Nice-to-have): Exploratory dashboards, ad-hoc reports, rarely accessed.
• Tier 4 (Deprecated): Broken dashboards, no recent access, candidates for deletion.

You’ll typically find that 20% of your dashboards drive 80% of the value. Focus your migration effort there.

Step 3: Document data source architecture. Map every data source in Tableau:

• Database connections (Snowflake, BigQuery, Postgres, SQL Server, etc.)
• Extract schedules and refresh frequencies
• Row-level security (RLS) rules
• Custom SQL queries
• Joins and unions
• Calculated fields and LOD expressions

This is tedious. Do it anyway. Many teams skip this step and regret it during cutover.

Define Your Success Criteria

Before you begin, agree on what “done” looks like. This isn’t subjective. Define measurable outcomes:

• Timeline: We’ll aim for full cutover in 6 weeks (adjust based on your estate size).
• Dashboard parity: All Tier 1 and Tier 2 dashboards rebuilt and validated in Superset.
• Data freshness: Superset dashboards refresh on the same schedule as Tableau (or better).
• User adoption: 90% of active Tableau users sign in to Superset within 2 weeks of launch.
• Performance: Dashboard load times match or beat Tableau (typically they’re faster).
• Cost reduction: Total cost of ownership (infrastructure, licensing, support) drops by at least 60%.

Write these down. Share them with stakeholders. Revisit them weekly.

Assemble Your Migration Team

Migrations fail when ownership is unclear. Assign these roles:

• Migration Lead: Owns the overall timeline, coordinates across teams, removes blockers. This should be your CTO, Head of Data, or a fractional CTO partner like PADISO.
• Data Engineer: Remaps data sources, builds Superset connections, validates data integrity.
• BI Developer: Rebuilds dashboards, writes SQL, configures filters and parameters.
• Change Manager: Runs user communication, training, feedback collection.
• Security/Compliance Lead: Ensures RLS rules are enforced, validates audit trails (critical if you’re pursuing SOC 2 or ISO 27001 compliance).

If you don’t have all these people in-house, this is where a venture studio partner or fractional CTO can accelerate your timeline by 2–3 weeks.

---

Data Source Remapping Strategy

This is the hardest part of the migration. Get this wrong and your dashboards will show stale or incorrect data.

Understand Tableau’s Data Model

Tableau stores data in two ways:

1. Live connections: Direct queries to databases. No caching, always fresh, but slower for large datasets.
2. Extracts: Tableau’s proprietary format. Refreshed on a schedule, fast queries, but requires scheduled refresh jobs.

Superset doesn’t have Tableau’s extract format. Instead, Superset connects directly to your databases and caches results using Redis or Memcached. For large datasets that Tableau handled via extracts, you’ll need to decide: leave the data in your database (Superset queries it directly) or use your data warehouse’s native materialised views or dbt models.

Most teams choose the latter. It’s cleaner, cheaper, and aligns with modern data stack practices.

Map Data Sources to Superset Connections

For each Tableau data source, create a corresponding Superset connection:

1. Database Connections

Tableau data sources that connect to live databases (Snowflake, BigQuery, Postgres, etc.) map directly to Superset database connections. In Superset, navigate to Settings > Database Connections and add each database:

Database Type: Snowflake (or your platform)
Host: [your-snowflake-account].snowflakecomputing.com
Database: [database-name]
Schema: [schema-name]
Username: [service-account-username]
Password: [service-account-password]
Port: 443

Use service accounts, not personal credentials. If you’re pursuing SOC 2 or ISO 27001 compliance, this is non-negotiable—personal credentials are a finding waiting to happen.

2. Extract Replacements

For Tableau extracts, you have three options:

• Option A: Materialised views in your data warehouse. Create a scheduled job (dbt, Airflow, or your warehouse’s native scheduler) that materialises the extract logic as a table. Superset queries the table directly.
• Option B: dbt models with incremental refreshes. dbt handles the transformation logic; Superset queries the dbt-created tables.
• Option C: Superset’s native caching. Create a Superset dataset (see below), configure a cache TTL (time-to-live), and let Superset handle refresh. This works for smaller datasets.

For most teams, Option A or B is best. It keeps transformation logic in your data warehouse (where it belongs) and keeps Superset as a pure visualization layer.

Create Superset Datasets

In Superset, a “dataset” is the equivalent of a Tableau data source. It’s a SQL query (or table reference) that Superset uses to populate dashboards.

For each Tableau data source:

1. In Superset, go to SQL Lab and write a query that replicates the Tableau source’s logic.
2. Test the query. Validate row counts and column names match Tableau.
3. Save as a dataset: SQL Lab > Save > Save as dataset.
4. Name it to match your Tableau source (e.g., sales_transactions, customer_cohorts).
5. Set Cache TTL based on your refresh frequency:

• Real-time dashboards: 0 seconds (no cache) - Hourly refresh: 3600 seconds - Daily refresh: 86400 seconds

Pro tip: Use Superset’s Virtual Datasets feature if you’re building on top of existing tables. This lets you define transformations (filters, aggregations) without writing raw SQL.

Validate Data Integrity

Before you move a single dashboard, validate that your Superset datasets produce identical results to Tableau.

For each critical dataset:

1. Run the Superset query.
2. Run the equivalent Tableau query (or export Tableau data).
3. Compare row counts, sums, and sample rows.
4. Investigate discrepancies. Common culprits:

• Timezone differences (Tableau often uses server timezone; Superset uses database timezone) - NULL handling (Tableau excludes NULLs in some aggregations; Superset includes them) - Rounding or precision differences in calculated fields - Filter logic differences (Tableau’s context filters vs. Superset’s WHERE clauses)

Document every discrepancy and its resolution. You’ll reference this during cutover.

Handle Row-Level Security (RLS)

If your Tableau instance uses row-level security (e.g., sales reps only see their own region’s data), Superset has you covered—but configuration is different.

In Superset, RLS is defined at the dataset level using SQL WHERE clauses:

WHERE region = '{{ current_user_attribute("region") }}'

You’ll need to:

1. Populate user attributes: In Superset, go to Settings > Users and add custom attributes (e.g., region, department, cost_center) for each user.
2. Create RLS rules: For each dataset, define a WHERE clause that references these attributes.
3. Test thoroughly: Log in as different users and verify they only see their data.

If your RLS rules are complex (multiple attributes, nested conditions), consider building a user_attributes table in your database and joining against it. This is cleaner and easier to maintain.

---

Dashboard and Workbook Redesign

Prioritise Ruthlessly

You can’t rebuild every dashboard in 6 weeks. Don’t try.

Focus on Tier 1 and Tier 2 dashboards first. Aim for:

• Week 1–2: Tier 1 dashboards (5–10 critical dashboards)
• Week 2–4: Tier 2 dashboards (15–25 important dashboards)
• Week 4–6: Tier 3 dashboards (if time permits); deprecate Tier 4

This keeps your critical stakeholders happy and gives you momentum.

Understand the Superset UI/UX Differences

Superset’s interface is different from Tableau. Your users will notice. Prepare them.

Key differences:

• No drag-and-drop dashboard builder: Superset dashboards are built using a grid-based layout. You can’t drag fields onto a canvas like Tableau. Instead, you add charts (created in SQL Lab) to a dashboard and resize them.
• Charts are separate from dashboards: In Tableau, you build a sheet and add it to a dashboard. In Superset, you create a chart in SQL Lab, then add it to a dashboard. This separation is actually cleaner for reusability.
• Filters are dashboard-scoped, not chart-scoped: In Tableau, filters can be sheet-specific. In Superset, filters apply to all charts on a dashboard (unless you configure native filters per chart). This requires rethinking filter architecture.
• No calculated fields in the UI: Superset doesn’t have a calculated field builder like Tableau. All logic must be in SQL. This is actually better (version control, reusability) but requires your team to be comfortable with SQL.

Rebuild Dashboards in Superset

Here’s the process for each dashboard:

Step 1: Plan the layout.

Open the Tableau dashboard. Sketch out the layout:

• How many charts?
• What’s the visual hierarchy?
• What filters do users need?
• Are there any parameters or dynamic elements?

In Superset, you’ll use a grid layout (typically 12 columns). Plan your chart sizes accordingly.

Step 2: Create charts in SQL Lab.

For each chart on the dashboard:

1. Go to SQL Lab.
2. Write a query that produces the data for the chart.
3. Click Visualize to preview.
4. Choose a visualization type (Table, Bar, Line, Pie, Scatter, etc.).
5. Configure chart settings (title, axes, colors, legend).
6. Save as a chart: Save > Save as chart.

Step 3: Build the dashboard.

1. Go to Dashboards and create a new dashboard.
2. Click Edit Dashboard.
3. Click + Chart and add each chart you created.
4. Resize and position charts on the grid.
5. Add filters if needed (see below).
6. Click Save.

Step 4: Configure filters and interactivity.

Superset filters work differently than Tableau. In Superset:

• Native filters are defined at the dashboard level and can be linked to specific charts.
• Each filter has a datasource (the table/query it pulls values from), a column (what to filter on), and a filter type (Select, Range, etc.).

Example: If you want a “Region” filter that appears on a sales dashboard:

1. Click Filter in the dashboard editor.
2. Choose Select filter.
3. Set datasource to sales_transactions, column to region.
4. Link the filter to charts that have a region column.
5. Save.

Filters are powerful but require careful design. Map out your filter logic before you build.

Migrate Calculated Fields and LOD Expressions

Tableau calculated fields and LOD (Level of Detail) expressions don’t exist in Superset. You need to rewrite them as SQL.

Example: Tableau Calculated Field

Tableau: IF [Profit] > 0 THEN "Profitable" ELSE "Loss" END

Superset SQL:
CASE WHEN profit > 0 THEN 'Profitable' ELSE 'Loss' END AS profitability

Example: Tableau LOD Expression

Tableau: { FIXED [Customer ID] : SUM([Revenue]) }

Superset SQL:
SUM(revenue) OVER (PARTITION BY customer_id) AS customer_lifetime_revenue

For complex calculations, build them into your datasets (in SQL Lab) rather than trying to do them at the chart level. This is cleaner and more maintainable.

Handle Embedded Content and Extensions

If your Tableau dashboards embed custom extensions, web objects, or R/Python scripts, you’ll need to rebuild or replace them.

Superset has limited extension support compared to Tableau. Options:

1. Rebuild in Superset’s visualization plugins: Superset has a plugin architecture. If you have custom viz needs, you can build them (requires JavaScript/React knowledge).
2. Use Superset’s Markdown chart: For simple HTML/CSS content, embed it in a Markdown chart.
3. Link to external tools: Embed links to external dashboards or reports rather than embedding them directly.

If you have heavily customised Tableau extensions, this is where a platform engineering partner can help you assess whether rebuilding is worth it or if you should deprecate the functionality.

---

User Training and Change Management

Communicate Early and Often

Migrations fail because users feel blindsided. Start communication 4–6 weeks before cutover.

Week 1–2: Announce the migration.

• Why: Cost savings, control, modern data stack alignment.
• What: Superset will replace Tableau.
• When: Cutover date (e.g., 6 weeks from now).
• How: Gradual rollout, training provided, support available.

Week 3–4: Share training materials.

• Superset overview video (15 mins).
• How to log in, access dashboards, apply filters.
• How to create simple charts (for power users).
• FAQ document.

Week 5: Run live training sessions.

• Beginner session: Dashboard navigation, filters, exporting data.
• Advanced session: SQL Lab, creating custom charts, parameters.
• Record sessions for asynchronous viewing.

Week 6 (cutover week): Intensive support.

• Slack/Teams channel for questions.
• Daily stand-ups with support team.
• Escalation path for critical issues.

Create Training Materials

Not everyone learns the same way. Provide multiple formats:

1. Video tutorials: 5–10 minute videos showing common tasks (filter a dashboard, export data, create a chart). Use tools like Loom or Camtasia.
2. Written guides: Step-by-step instructions with screenshots. Publish in Confluence or a shared wiki.
3. Interactive demos: Let users explore Superset in a sandbox environment before cutover.
4. Live training: 1-hour sessions for different user groups (executives, analysts, operational users).
5. Office hours: 30-minute slots where users can ask questions one-on-one.

Address Change Resistance

Some users will resist. That’s normal. Here’s how to handle it:

“Superset is slower than Tableau.” Measure it. In most cases, Superset is faster (because you’re querying your data warehouse directly, not Tableau’s proprietary engine). Show benchmarks: “Average dashboard load time: Tableau 8 seconds, Superset 2 seconds.”

“I don’t know SQL.” Superset has a visual query builder for simple cases. But yes, power users need SQL. Offer SQL training or hire a fractional data engineer to write queries for your team.

“We paid for Tableau; why are we switching?” Show the cost-benefit analysis. Tableau licenses: $70k/year. Superset infrastructure: $15k/year. Savings: $55k/year. Over 3 years, that’s $165k. Plus: you own your data, you control your roadmap, you’re not vendor-locked.

Plan for Different User Personas

Not all users interact with Superset the same way. Create training paths:

Executive Users (5–10 people)

• Need: Access to key dashboards, ability to filter and export.
• Training: 30-minute overview. Show them how to access their dashboards, apply filters, export to Excel.
• Support: Dedicated Slack channel, priority support.

Analyst Users (20–50 people)

• Need: Ability to create custom charts, write SQL, build dashboards.
• Training: 2-hour workshop on SQL Lab, dataset creation, dashboard building.
• Support: Office hours, SQL review, best practices guide.

Operational Users (50–200 people)

• Need: Access to operational dashboards, ability to apply filters.
• Training: 1-hour group session on navigation and filters.
• Support: FAQ, video tutorials, general Slack channel.

Collect Feedback and Iterate

Post-launch, feedback is gold. Create a feedback loop:

1. Survey: 2 weeks post-launch, send a 5-question survey (NPS-style). What’s working? What’s broken? What do you miss from Tableau?
2. Office hours: Weekly 30-minute sessions where users can raise issues.
3. Bug tracking: Create a Jira board for Superset issues. Prioritise and fix them weekly.
4. Roadmap: Share a public roadmap of planned improvements (new visualizations, performance optimizations, etc.). This shows you’re listening.

Many teams find that after 4 weeks, adoption is smooth and feedback becomes sporadic. That’s your signal to shift to maintenance mode.

---

Cutover Planning and Execution

Choose Your Cutover Strategy

You have two options:

Option 1: Big Bang Cutover

• On day 1, shut down Tableau and switch everyone to Superset.
• Pros: Clean break, no confusion, forces adoption.
• Cons: High risk. If something breaks, everything breaks.
• Best for: Small teams (< 50 users), simple dashboards, low risk tolerance.

Option 2: Parallel Run

• Run Tableau and Superset simultaneously for 2–4 weeks.
• Users access both, compare results, build confidence.
• Gradually deprecate Tableau as confidence grows.
• Pros: Lower risk, users can validate data, smooth transition.
• Cons: Longer timeline, ongoing Tableau costs, potential confusion.
• Best for: Large teams (> 100 users), complex dashboards, risk-averse stakeholders.

Most teams choose Option 2. It costs an extra 2–3 weeks and a bit more in infrastructure, but it’s worth the peace of mind.

Create a Cutover Plan

Document your cutover plan in excruciating detail. Share it with stakeholders 1 week before cutover.

Cutover Plan Template:

Cutover Date: [Date]
Cutover Window: [Start time] to [End time] (e.g., 6 PM Friday to 8 AM Monday)

Pre-Cutover (Week before):
- Final data validation: All datasets match Tableau (Owner: Data Engineer, Due: Wednesday)
- User communication: Final reminder email (Owner: Change Manager, Due: Thursday)
- Backup: Full Tableau backup (Owner: IT, Due: Thursday)
- Dry run: Test cutover process with a small user group (Owner: Migration Lead, Due: Friday)

Cutover Day:
- 6:00 PM: Announce cutover in Slack/Teams
- 6:15 PM: Disable Tableau access
- 6:30 PM: Enable Superset for all users
- 6:45 PM: Monitor Superset performance, check for errors
- 7:00 PM: Send "Superset is live" email
- 7:00 PM–10:00 PM: Active support (Migration Lead + Data Engineer on call)

Post-Cutover (Days 1–7):
- Daily stand-ups (9 AM): Discuss issues, prioritise fixes
- Monitor performance: Dashboard load times, database query times
- Collect feedback: User issues, feature requests
- Fix critical bugs: Deploy fixes within 24 hours

Post-Cutover (Weeks 2–4):
- Weekly stand-ups: Discuss remaining issues
- Deprecate Tableau: Turn off Tableau Server, archive data
- Archive Tableau licenses: Reduce costs

Prepare Your Infrastructure

Before cutover, ensure your Superset infrastructure is rock-solid.

1. Sizing and Performance

Superset’s performance depends on:

• Database performance: If your queries are slow, Superset will be slow. Optimise your database queries before cutover.
• Superset server resources: For 100+ concurrent users, run Superset on at least 4 CPU cores and 16 GB RAM. Use a load balancer if you’re running multiple instances.
• Cache infrastructure: Use Redis for caching. Configure a TTL strategy that balances freshness and performance.

Load-test Superset before cutover. Simulate your peak load (number of concurrent users, dashboard views per second). Target: 95th percentile dashboard load time < 3 seconds.

2. Security and Compliance

If you’re pursuing SOC 2 or ISO 27001 compliance, ensure:

• Authentication: Use SAML, LDAP, or OAuth (not local usernames). This ensures single sign-on and centralized access control.
• Encryption: Enable SSL/TLS for all connections. Encrypt data at rest if sensitive.
• Audit logging: Enable Superset’s audit log. Log all user actions (login, dashboard view, data export). Retain logs for 1+ years.
• Access control: Use Superset’s role-based access control (RBAC). Restrict dashboard/dataset access by role.
• Data residency: Ensure Superset runs in the same region as your data (for compliance).

Documenting these controls is essential for audit readiness. Use a tool like Vanta to automate compliance evidence collection.

3. Backup and Disaster Recovery

• Database backups: Back up your Superset metadata database (PostgreSQL, MySQL, etc.) daily.
• Dashboard exports: Export all Superset dashboards and datasets as JSON. Store in version control (Git).
• Disaster recovery plan: Document how to restore Superset from backups. Test quarterly.

Execute the Cutover

On cutover day:

6:00 PM–6:30 PM: Pre-cutover checks

• Verify Superset is running and responsive.
• Verify all datasets are up-to-date (latest data loaded).
• Verify user access is configured (all users can log in).
• Verify backups are complete.

6:30 PM–7:00 PM: Disable Tableau, enable Superset

• Turn off Tableau Server (or set to read-only mode).
• Send email: “Tableau is offline. Superset is now live. Log in here: [Superset URL].”
• Monitor Superset: Watch for errors, slow queries, failed logins.

7:00 PM–10:00 PM: Active support

• Have your migration team (Data Engineer, BI Developer, Change Manager) on standby.
• Monitor Slack/Teams for user issues.
• Triage issues: Critical (blocks dashboard access) vs. Important (feature missing) vs. Minor (cosmetic).
• Fix critical issues immediately. Document and resolve important/minor issues within 24 hours.

10:00 PM–8:00 AM: Overnight support

• Have on-call rotation (1–2 people).
• Monitor Superset health (CPU, memory, database connections).
• If critical issues arise, escalate to migration lead.

8:00 AM (Day 2): Post-cutover stand-up

• Gather feedback from overnight support.
• Review error logs, slow queries.
• Prioritise fixes for the day.
• Send update email: “Cutover successful. [X] dashboards live, [X] users active. Known issues: [list].”

---

Post-Migration Optimisation

Monitor Performance

Post-cutover, performance is critical. Set up monitoring:

1. Dashboard load times

Use Superset’s built-in metrics or a tool like Datadog:

• Track 50th, 95th, 99th percentile load times.
• Alert if 95th percentile > 5 seconds.
• Target: < 3 seconds for most dashboards.

2. Database query times

Monitor your database:

• Track slow queries (> 10 seconds).
• Identify bottlenecks (missing indexes, inefficient joins).
• Optimise queries or create materialised views.

3. Superset server health

Monitor CPU, memory, disk space:

• Alert if CPU > 80% for > 5 minutes.
• Alert if memory > 90%.
• Alert if disk > 85%.

Optimise Query Performance

If dashboards are slow, optimise at the database level:

1. Add indexes

Identify columns frequently used in filters or joins. Add indexes:

CREATE INDEX idx_region ON sales_transactions(region);
CREATE INDEX idx_date ON sales_transactions(transaction_date);

2. Create materialised views

For complex aggregations, create materialised views:

CREATE MATERIALIZED VIEW sales_by_region AS
SELECT region, SUM(revenue) as total_revenue, COUNT(*) as transaction_count
FROM sales_transactions
GROUP BY region;

REFRESH MATERIALIZED VIEW sales_by_region;

Schedule the refresh (e.g., hourly or daily) using Airflow, dbt, or your database’s scheduler.

3. Use dbt for transformations

If you’re not already using dbt, this is a good time to start. dbt integrates seamlessly with Superset and keeps your transformation logic version-controlled and reusable.

4. Partition large tables

For very large tables (billions of rows), partition by date or another key column:

CREATE TABLE sales_transactions (
  id INT,
  region VARCHAR(50),
  transaction_date DATE,
  revenue DECIMAL(10, 2)
) PARTITION BY RANGE (YEAR(transaction_date)) (
  PARTITION p2021 VALUES LESS THAN (2022),
  PARTITION p2022 VALUES LESS THAN (2023),
  PARTITION p2023 VALUES LESS THAN (2024)
);

Consolidate and Deprecate

Post-cutover, you’ll have duplicate dashboards (some in Tableau, some in Superset). Clean this up:

Week 1–2: Parallel run. Users access both Tableau and Superset.

Week 3: Announce Tableau deprecation. Set a sunset date (e.g., 4 weeks from cutover). After that date, Tableau will be offline.

Week 4–7: Gradual Tableau shutdown.

• Week 4: Disable Tableau Server (read-only mode). Users can view but not edit.
• Week 5: Turn off Tableau Server. Announce final cutover.
• Week 6–7: Archive Tableau data, cancel licenses, decommission infrastructure.

Governance and Maintenance

Establish governance to prevent Superset from becoming as messy as Tableau:

1. Dashboard naming conventions

[Department]-[Function]-[Version]
Example: Finance-CashFlow-v1, Sales-PipelineTracking-v2

2. Dataset naming conventions

[Source]-[Entity]-[Grain]
Example: Snowflake-Customers-Daily, Postgres-Transactions-Hourly

3. Ownership and accountability

Assign each dashboard and dataset an owner. Owners are responsible for:

• Keeping documentation updated.
• Responding to user questions.
• Deprecating unused assets.
• Refreshing data definitions annually.

4. Deprecation process

When a dashboard is no longer needed:

1. Mark it as “Deprecated” in the title.
2. Add a note: “This dashboard is deprecated as of [date]. Use [new-dashboard] instead.”
3. Wait 4 weeks for users to migrate.
4. Delete it.

This prevents dashboard sprawl.

---

Common Pitfalls and How to Avoid Them

Pitfall 1: Underestimating Effort

The mistake: “We have 50 dashboards. At 4 hours per dashboard, that’s 200 hours. We can do this in 2 weeks.”

Reality: Dashboard rebuilds aren’t linear. The first dashboard takes 8 hours (learning curve). The 10th takes 4 hours. But complex dashboards with custom SQL, parameters, and RLS can take 12+ hours.

How to avoid it: Build a buffer. Estimate 6 hours per dashboard on average. For 50 dashboards, that’s 300 hours. With a team of 2 BI developers, that’s 150 hours of work = ~4 weeks (assuming 40 hours/week).

Pitfall 2: Data Mismatches

The mistake: You rebuild a dashboard in Superset. It shows different numbers than Tableau. Users freak out.

Reality: Data mismatches are common. Causes:

• Timezone differences (Tableau shows UTC; Superset shows local time).
• NULL handling (Tableau excludes NULLs in SUM; Superset includes them).
• Rounding differences in calculations.
• Filter logic differences.

How to avoid it: Validate every dataset before cutover. Run the Superset query, run the Tableau query, compare results. Document discrepancies and resolutions.

Pitfall 3: Ignoring User Adoption

The mistake: You launch Superset. 30% of users log in. The rest go back to Tableau or Excel.

Reality: Adoption requires intentional effort. Users need training, support, and a reason to switch.

How to avoid it: Start training 4–6 weeks before cutover. Run live sessions. Collect feedback. Address concerns. Post-cutover, have office hours and a Slack channel for support. Track adoption metrics (login rate, dashboard views, data exports). If adoption is low, investigate why and adjust.

Pitfall 4: Underestimating Infrastructure Costs

The mistake: “Superset is open-source. It’s free.”

Reality: Superset is free, but infrastructure isn’t. You’ll pay for:

• Superset server (compute, storage, network).
• Database (Postgres/MySQL for metadata).
• Redis (for caching).
• Monitoring and logging (Datadog, New Relic, etc.).
• Support and maintenance (if you don’t have in-house expertise).

Estimate $15k–$30k/year for a mid-market deployment. Still cheaper than Tableau, but not free.

How to avoid it: Build a detailed cost model. Include all infrastructure, support, and training costs. Compare to Tableau. Show the ROI.

Pitfall 5: Rushing Cutover

The mistake: You want to cut costs quickly. You shut down Tableau on day 1, before Superset is fully tested.

Reality: Cutover mishaps are expensive. A 4-hour outage can cost $50k+ in lost productivity. A data mismatch can invalidate decisions.

How to avoid it: Run a parallel cutover for 2–4 weeks. Validate data, train users, collect feedback. Only deprecate Tableau when you’re confident Superset is stable.

---

Real Timeline and Effort Estimates

Here’s a realistic timeline for a mid-market migration (50–100 dashboards, 100–200 users):

Small Deployment (10–25 dashboards, < 50 users)

| Phase | Duration | Effort | Notes | |-------|----------|--------|-------| | Assessment & Planning | 1 week | 40 hours | Audit Tableau, plan cutover, assemble team | | Data Source Remapping | 1 week | 60 hours | Create Superset connections, validate data | | Dashboard Rebuild | 2 weeks | 80 hours | Rebuild dashboards, test, iterate | | User Training | 1 week | 20 hours | Create materials, run sessions, office hours | | Cutover & Support | 1 week | 60 hours | Execute cutover, monitor, fix issues | | Total | 6 weeks | 260 hours | ~2 FTE for 6 weeks, or 1 FTE for 12 weeks |

Mid-Market Deployment (50–100 dashboards, 100–200 users)

| Phase | Duration | Effort | Notes | |-------|----------|--------|-------| | Assessment & Planning | 1–2 weeks | 80 hours | Audit Tableau, categorise dashboards, plan | | Data Source Remapping | 2 weeks | 120 hours | 30–40 data sources, validation | | Dashboard Rebuild | 4 weeks | 240 hours | Rebuild 50–80 dashboards, test, iterate | | User Training | 2 weeks | 60 hours | Multiple sessions, office hours, support | | Cutover & Support | 1–2 weeks | 120 hours | Cutover, monitoring, bug fixes, feedback | | Total | 8–10 weeks | 620 hours | ~2 FTE for 10 weeks, or fractional CTO + BI dev |

Enterprise Deployment (200+ dashboards, 500+ users)

| Phase | Duration | Effort | Notes | |-------|----------|--------|-------| | Assessment & Planning | 2–3 weeks | 160 hours | Complex Tableau estate, multi-team coordination | | Data Source Remapping | 3 weeks | 240 hours | 100+ data sources, RLS, extracts | | Dashboard Rebuild | 6–8 weeks | 480 hours | Rebuild 150–200 dashboards, phased rollout | | User Training | 3–4 weeks | 180 hours | Multiple departments, custom training paths | | Cutover & Support | 2–4 weeks | 240 hours | Phased cutover by department, ongoing support | | Total | 14–18 weeks | 1,300 hours | 2–3 FTE for 10–12 weeks, or outsourced partnership |

Cost-Benefit Analysis

Let’s say you’re a mid-market company:

Current state:

• Tableau licenses: $80k/year (50 users × $1.6k per user)
• Tableau Server infrastructure: $15k/year
• Support and maintenance: $10k/year
• Total: $105k/year

Post-Superset:

• Superset infrastructure: $20k/year
• Database/data warehouse: $30k/year (shared with other tools)
• Support and maintenance: $5k/year
• Total: $55k/year

Savings: $50k/year

Migration cost (one-time):

• Internal team: 620 hours × $100/hour = $62k
• Or outsourced: $80k–$120k (including fractional CTO, BI dev, change management)

ROI:

• If outsourced at $100k: Payback in 2 years. Year 3+, pure savings.
• If internal at $62k: Payback in 1.2 years. Year 2+, pure savings.

Most companies find the ROI compelling, especially if they’re spending > $100k/year on Tableau.

---

Post-Migration Support and Governance

Establish a Support Model

Post-cutover, you need ongoing support. Choose a model:

Option 1: In-house team

• Hire or dedicate 1 FTE (data engineer or BI developer) to maintain Superset.
• Cost: $80k–$120k/year.
• Best for: Large organisations with heavy BI usage.

Option 2: Fractional CTO or outsourced partner

• Engage a fractional CTO or AI automation agency for 10–20 hours/week.
• Cost: $30k–$50k/year.
• Best for: Mid-market companies with moderate BI needs.

Option 3: Hybrid

• 1 part-time internal person (10 hours/week) + fractional support (5 hours/week).
• Cost: $40k–$70k/year.
• Best for: Companies with growing BI needs.

At PADISO, we often work with venture studio partners and fractional CTO arrangements to provide ongoing Superset support alongside broader platform engineering and AI automation initiatives.

Create a Superset Roadmap

Superset is actively developed. New features arrive regularly. Plan how you’ll stay current:

Quarterly updates:

• Review new features in the latest Superset release.
• Evaluate if they’re useful for your use cases.
• Plan to upgrade (test in staging first).

Annual review:

• Assess Superset’s fit for your organisation.
• Evaluate new BI tools (if needed).
• Plan infrastructure upgrades (if user base is growing).

Documentation and Knowledge Sharing

Document everything:

1. Architecture documentation: How Superset connects to your databases, caching strategy, RLS rules.
2. Dashboard documentation: What each dashboard does, who owns it, when it was last updated.
3. Dataset documentation: What each dataset contains, how it’s calculated, refresh frequency.
4. Runbooks: Step-by-step guides for common tasks (add a user, create a dashboard, troubleshoot slow queries).
5. FAQ: Common questions and answers.

Store everything in Confluence, Notion, or GitHub. Make it searchable and easy to find.

---

Next Steps and Governance

Immediate Actions (This Week)

1. Audit your Tableau estate. Export a complete inventory of dashboards, data sources, and users. Categorise by criticality.
2. Assemble your team. Identify your migration lead, data engineer, BI developer, and change manager. If you don’t have these roles in-house, consider engaging a fractional CTO or venture studio partner.
3. Define success criteria. What does success look like? Timeline, dashboard parity, user adoption, cost savings. Write it down.
4. Create a high-level timeline. Based on your dashboard count and team size, estimate a timeline. Plan for 6–12 weeks depending on complexity.

Week 1–2: Planning Phase

1. Deep dive on data sources. Map every Tableau data source to a Superset connection. Identify extract replacements. Plan your data architecture.
2. Design your Superset infrastructure. Decide on hosting (cloud or on-prem), sizing, caching strategy, security controls. If you’re pursuing SOC 2 or ISO 27001 compliance, involve your security team.
3. Draft your cutover plan. Big bang or parallel run? Timeline? Rollback plan? Communicate with stakeholders.
4. Create a communication plan. When and how will you announce the migration? What training will you provide? How will you support users post-cutover?

Week 3–6: Execution Phase

1. Build Superset infrastructure. Deploy Superset, configure databases, set up caching, enable authentication.
2. Remap data sources. Create Superset connections, build datasets, validate data integrity.
3. Rebuild dashboards. Start with Tier 1 dashboards. Aim for 1–2 dashboards per week per developer.
4. Prepare training materials. Videos, guides, FAQs. Run beta sessions with power users.

Week 7–10: Validation and Cutover

1. Validate all dashboards. Compare Superset results to Tableau. Fix discrepancies.
2. Run parallel cutover. Enable Superset for all users. Keep Tableau running for 2–4 weeks. Collect feedback.
3. Train users. Run live sessions, office hours, support.
4. Monitor closely. Track adoption, performance, user issues. Fix bugs quickly.

Week 11+: Stabilisation and Optimisation

1. Optimise performance. Identify slow dashboards, optimise queries, add indexes.
2. Deprecate Tableau. Turn off Tableau Server, cancel licenses, archive data.
3. Establish governance. Define naming conventions, ownership, deprecation process.
4. Plan for the future. Superset roadmap, infrastructure growth, new features.

Key Success Factors

Migrations succeed when:

1. Leadership is aligned. Your CTO, CFO, and key stakeholders agree on the migration and are willing to invest time/resources.
2. You have a dedicated team. A part-time migration effort will drag on for months. Dedicate 1–2 FTE for the duration.
3. You prioritise ruthlessly. Don’t try to migrate every dashboard. Focus on Tier 1 and Tier 2. Deprecate Tier 4.
4. You communicate constantly. Overcommunicate. Share progress weekly. Address concerns immediately.
5. You invest in training. Users won’t adopt Superset if they don’t understand it. Provide multiple training formats and ongoing support.
6. You plan for cutover carefully. Cutover is high-risk. Run a parallel cutover. Validate data. Have a rollback plan.
7. You measure success. Track adoption, performance, cost savings. Share wins. Celebrate milestones.

When to Engage External Help

Consider engaging a fractional CTO, platform engineering partner, or venture studio if:

• You don’t have in-house BI expertise. A BI developer or data engineer can accelerate your timeline by 4–6 weeks.
• Your Tableau estate is complex. 200+ dashboards, custom extensions, RLS rules—this requires experienced hands.
• You’re pursuing compliance. If you need SOC 2 or ISO 27001 audit-readiness, a security-focused partner can ensure Superset is configured correctly from day one.
• Your team is stretched. If your data/engineering team is already overloaded, outsourcing the migration lets them focus on core work.
• You want to accelerate. A dedicated external team can compress a 12-week migration into 6–8 weeks.

At PADISO, we’ve helped Sydney-based startups and mid-market operators execute this migration successfully. We provide fractional CTO leadership, BI development, data engineering, and change management. We’ve reduced migration timelines by 30–40% and helped teams avoid costly mistakes. If you’re considering a Tableau-to-Superset migration, we’re happy to discuss your specific situation.

---

Conclusion

Migrating from Tableau to Apache Superset is a significant undertaking, but it’s absolutely achievable with the right plan, team, and execution discipline.

The teams that succeed do three things:

1. They plan ruthlessly. They audit their Tableau estate, categorise by criticality, and focus on what matters.
2. They execute with discipline. They assemble a dedicated team, follow a clear timeline, and communicate constantly.
3. They invest in people. They provide training, support, and a clear path for users to adopt Superset.

The payoff is significant: 50–60% cost savings, faster dashboards, control over your data, and alignment with your modern data stack.

If you’re ready to start your migration, begin this week with a Tableau audit and a conversation with your team. If you need help, PADISO’s fractional CTO and platform engineering services can accelerate your timeline and reduce risk.

Your Superset future is waiting. Let’s ship it.