Migrating from Mode to Superset for Mid-Market Organisations

Table of Contents

1. Why Mid-Market Teams Move from Mode to Superset
2. Scoping Your Migration: The Discovery Phase
3. Governance and Access Control Patterns
4. Cost Benchmarks and Budget Planning
5. Technical Architecture and Data Pipeline Design
6. Dashboard and Query Migration Workflow
7. The Cutover Pattern: Timing and Sequencing
8. Post-Migration Optimisation and Runbook
9. Common Pitfalls and How to Avoid Them
10. When to Partner with a Specialist

---

Why Mid-Market Teams Move from Mode to Superset {#why-migrate}

Mode Analytics has served mid-market organisations well for self-service SQL and business intelligence workflows. But as teams scale—especially those managing embedded analytics, multi-tenant reporting, or requiring tighter control over data governance—Mode’s per-seat licensing, closed-source architecture, and vendor lock-in create friction.

Superset, by contrast, is open-source, deployable on your own infrastructure, and scales cost-efficiently. A team of 50 analysts and stakeholders on Mode might pay $5,000–$15,000 per month. The same cohort on Superset, self-hosted on Kubernetes or a managed cloud platform, typically costs $2,000–$4,000 monthly in infrastructure and operational overhead.

But cost alone isn’t the driver. Mid-market organisations migrate for three core reasons:

1. Embedded Analytics and Multi-Tenant Reporting

If you’re building a SaaS product or white-label reporting platform, Mode’s licensing model breaks down. You cannot embed Mode dashboards into your product without paying per-user fees that scale with your customer base. Superset’s open-source nature allows you to embed dashboards, control branding, and manage tenant isolation directly. This is especially critical for fintech, insurance, and SaaS-as-a-service platforms.

2. Data Governance and Compliance

Organisations pursuing SOC 2 or ISO 27001 compliance require audit trails, role-based access control (RBAC), and data residency guarantees. Mode stores metadata and query logs in Salesforce’s cloud. Superset, running on your own infrastructure, gives you complete control over data lineage, audit logging, and where data physically resides. This is non-negotiable for regulated industries: healthcare, financial services, and critical infrastructure.

3. Customisation and Extensibility

Mode’s feature set is fixed. If you need custom visualisations, bespoke authentication integrations (LDAP, Okta, SAML), or proprietary business logic embedded in your analytics layer, you’re constrained. Superset’s open-source codebase allows you to fork, extend, and deploy custom plugins without waiting for vendor roadmap cycles.

The migration is not trivial—it requires careful planning around data architecture, access control, and user adoption. But for mid-market teams, the payoff is significant: lower per-user costs, tighter governance, and the ability to embed analytics as a core product feature.

---

Scoping Your Migration: The Discovery Phase {#scoping-migration}

Before touching a single dashboard, you need a clear inventory of what you’re moving and why. This discovery phase typically takes 2–4 weeks and sets the tone for the entire project.

Asset Inventory and Dependency Mapping

Start by cataloguing every Mode asset:

• Dashboards: Count them. Note which are active (used weekly), dormant (used quarterly or less), and orphaned (no owner). Aim to migrate only 60–80% of dashboards; the rest are candidates for retirement.
• Queries and Reports: Identify shared queries, scheduled reports, and alerting workflows. Mode’s query versioning and collaboration features have no direct equivalent in Superset, so you’ll need to decide how to replicate that workflow.
• Data Sources: List all databases, data warehouses, and APIs that Mode connects to. Note the authentication method (service accounts, IP allowlisting, VPN). Superset will need the same connectivity, so validate that your network policies permit it.
• Users and Roles: Export Mode’s user list and role assignments. Understand who owns which dashboards, who has admin access, and which users are inactive.
• Integrations: Mode integrates with Slack, email, and webhooks. Superset supports these natively, but the configuration differs. Document which integrations are actively used.

This inventory typically reveals that 20–30% of Mode dashboards are unused or owned by departed team members. Retiring these before migration reduces scope and simplifies governance on day one.

Governance and Access Control Requirements

Understand your current access model in Mode:

• Who can create dashboards? Typically a subset of analysts and data engineers, not all users.
• Who can modify shared queries? Is this restricted to data governance teams?
• How are dashboards shared? By team, by business unit, or globally?
• Are there data sensitivity tiers? Some organisations restrict raw PII or financial data to specific roles.

Superset’s role-based access control (RBAC) is more granular than Mode’s, but it requires explicit configuration. You’ll define roles like analyst, viewer, data_engineer, and admin, then map permissions at the dashboard, chart, and dataset level. This is an opportunity to tighten governance—but it also means upfront effort.

Cost and Timeline Estimation

Use this framework to estimate your migration effort:

Factor	Low Complexity	Medium Complexity	High Complexity
Active Dashboards	<50	50–200	>200
Data Sources	1–3	4–8	>8
User Base	<100	100–500	>500
Governance Requirements	Basic	Moderate (RBAC + audit)	Strict (data classification + compliance)
Estimated Effort	6–8 weeks	10–14 weeks	16–24 weeks
Team Size	1 FTE	2–3 FTE	4–6 FTE
Cost (excl. infrastructure)	$50K–$100K	$120K–$250K	$300K–$600K

These estimates assume a mix of internal staff and external support. If you’re running this entirely in-house with limited analytics engineering capacity, add 30–40% to the timeline.

---

Governance and Access Control Patterns {#governance}

Superset’s governance model is more sophisticated than Mode’s, but it requires intentional design. Here’s how to structure it for mid-market teams.

Role-Based Access Control (RBAC) Design

Define roles that map to your organisational structure:

• Viewer: Read-only access to dashboards and charts. Cannot modify or export data. Ideal for executives and stakeholders.
• Analyst: Can create and edit dashboards, write SQL queries, and export data. Can only access datasets they’ve been explicitly granted.
• Data Engineer: Full access to create datasets, modify connections, and manage data sources. Can approve new data sources and manage refresh schedules.
• Admin: Full system access. Manages users, roles, and infrastructure settings.

Superset allows you to assign permissions at multiple levels:

• Database level: Which users can query which databases.
• Schema level: Which users can access which schemas within a database.
• Dataset level: Which users can use which curated datasets in dashboards.
• Dashboard level: Which users can view, edit, or share specific dashboards.

For mid-market organisations, we recommend a dataset-centric approach: create curated datasets (tables or views) for each business function, then control access at the dataset level. This reduces the cognitive load on analysts and prevents accidental exposure of sensitive data.

Data Classification and Sensitivity Tiers

If your organisation handles sensitive data (PII, financial records, health information), implement a classification system:

• Public: Aggregated metrics, no PII. Accessible to all users.
• Internal: Business metrics, no external sensitivity. Accessible to all employees.
• Confidential: Contains PII or financial data. Restricted to specific roles (e.g., Finance, HR).
• Restricted: Highly sensitive data (e.g., executive compensation, M&A information). Restricted to named individuals.

In Superset, enforce this via:

1. Row-level security (RLS): Use Superset’s RLS feature to filter rows based on the logged-in user’s department or role.
2. Column masking: Use database views to mask sensitive columns for certain roles.
3. Audit logging: Enable Superset’s audit logging to track who accessed what data and when.

For organisations pursuing SOC 2 or ISO 27001 compliance via Vanta, this audit trail is essential. Vanta will ask for evidence of access controls and data lineage—Superset’s logging provides this natively.

Dataset Curation and Lineage

Create a data dictionary in Superset that documents:

• Dataset name and description: What does this data represent?
• Owner and steward: Who maintains this dataset?
• Refresh cadence: How often is it updated?
• Source tables: Which raw tables does this dataset depend on?
• Sensitive columns: Which columns contain PII or confidential data?

Superset’s dataset management interface allows you to add descriptions and tags. Use tags to categorise datasets by business function (finance, marketing, ops) and sensitivity tier (public, confidential).

This metadata becomes your data lineage—auditors and compliance teams will ask for it. If you’re using a data warehouse like Snowflake, BigQuery, or Redshift, consider integrating with a metadata tool like Apache Atlas or Collibra to automate lineage tracking. But for mid-market teams, a well-maintained data dictionary in Superset is often sufficient.

---

Cost Benchmarks and Budget Planning {#cost-benchmarks}

One of the primary drivers for migrating from Mode to Superset is cost. Let’s break down the real numbers.

Mode Licensing Cost

Mode charges per active user:

• Viewer tier: $50–$100 per user per month.
• Creator tier (for analysts and data engineers): $150–$300 per user per month.

For a mid-market organisation with 50 users (40 viewers, 10 creators), annual Mode costs are:

40 viewers × $75/month × 12 = $36,000
10 creators × $225/month × 12 = $27,000
Total: $63,000/year

Add 20% for support and training, and you’re at ~$75,000 annually.

Superset Hosting and Operational Costs

Superset is open-source, so there’s no licensing fee. You pay for infrastructure:

Option 1: Self-Hosted on Kubernetes (AWS EKS, GKE, AKS)

• Compute: 2–4 node Kubernetes cluster = $400–$800/month.
• Database: PostgreSQL or MySQL for Superset metadata = $100–$300/month.
• Object storage: S3 or GCS for exported reports = $50–$150/month.
• Monitoring and logging: Datadog or similar = $200–$400/month.
• Backup and disaster recovery: $100–$200/month.
• Operational overhead (1 FTE DevOps/SRE): $80K–$120K/year.

Total annual cost: ~$50K–$70K (including staffing).

Option 2: Managed Superset (Preset Cloud)

Preset, the company behind Superset, offers a managed hosting option:

• Standard plan: $1,500–$3,000/month for up to 100 users.
• Includes: Hosting, backups, monitoring, and support.
• No operational overhead.

Total annual cost: ~$18K–$36K.

Cost Comparison

Scenario	Mode	Superset (Self-Hosted)	Superset (Preset)
50 users (40 viewers, 10 creators)	$75K/year	$50–70K/year	$18–36K/year
100 users (80 viewers, 20 creators)	$135K/year	$60–80K/year	$25–45K/year
200 users (160 viewers, 40 creators)	$255K/year	$80–100K/year	$35–60K/year

For organisations with 50+ users, Superset (especially self-hosted) offers 30–50% cost savings. For organisations with embedded analytics, the savings are even greater—Mode would charge per-customer, while Superset’s cost is fixed.

Budget for Migration

The migration itself is an upfront cost:

• Discovery and planning: $10K–$20K (2–3 weeks).
• Infrastructure setup and security hardening: $15K–$30K (2–4 weeks).
• Dashboard and query migration: $30K–$80K (4–10 weeks, depending on complexity).
• User training and documentation: $5K–$10K (1–2 weeks).
• Testing and cutover: $10K–$20K (2–3 weeks).

Total migration cost: $70K–$160K.

For a mid-market organisation, this investment typically pays for itself within 12–18 months through licensing savings and operational efficiency.

---

Technical Architecture and Data Pipeline Design {#technical-architecture}

Superset’s architecture differs from Mode’s. Understanding these differences is crucial for a smooth migration.

Superset’s Core Architecture

Superset separates the analytics layer from the data layer:

1. Data Layer: Your data warehouse or database (Snowflake, BigQuery, Redshift, PostgreSQL, etc.).
2. Metadata Layer: Superset’s PostgreSQL database, which stores dashboard definitions, user roles, and query history.
3. Application Layer: The Superset web application, which renders dashboards and executes queries.
4. Caching Layer: Redis or Memcached, which caches query results to improve performance.

Unlike Mode, which tightly integrates with Salesforce’s infrastructure, Superset is stateless and horizontally scalable. You can run multiple Superset instances behind a load balancer, each pointing to the same metadata database.

Data Source Connectivity

Before migrating dashboards, ensure Superset can connect to your data sources. Superset supports 40+ database backends via SQLAlchemy. Common ones include:

• Cloud data warehouses: Snowflake, BigQuery, Redshift, Azure Synapse.
• Traditional databases: PostgreSQL, MySQL, Oracle, SQL Server.
• NoSQL and big data: Elasticsearch, Druid, Presto, Spark SQL.
• Data lakes: Dremio, Apache Iceberg, Delta Lake.

For each data source, configure:

1. Connection string: Host, port, credentials, database name.
2. SSH tunnelling (optional): If your database is behind a VPN or firewall, configure SSH tunnelling through a bastion host.
3. SSL/TLS certificates: Ensure encrypted connections.
4. Query timeouts: Set reasonable limits (30–300 seconds) to prevent runaway queries.
5. Connection pooling: Configure SQLAlchemy connection pool sizes based on expected concurrency.

For mid-market organisations using cloud data warehouses, we typically recommend a service account approach:

• Create a read-only service account in your data warehouse.
• Grant it access only to the schemas and tables needed for analytics.
• Rotate credentials every 90 days.
• Log all queries executed by the service account for audit purposes.

This approach aligns with SOC 2 and ISO 27001 requirements around least-privilege access.

Query Execution and Performance

Superset executes queries directly against your data warehouse. Unlike Mode, which may cache or optimise queries server-side, Superset’s performance depends entirely on your database’s performance.

For large queries (>1M rows, >10 second execution time), implement these patterns:

1. Materialised views or tables: Pre-compute expensive aggregations and refresh them nightly.
2. Star schema design: Organise your data warehouse with a fact/dimension model to optimise join performance.
3. Columnar compression: Use columnar formats (Parquet, ORC) to reduce storage and query time.
4. Query caching: Configure Superset’s Redis cache to store query results. Set cache expiration based on data freshness requirements (e.g., 1 hour for real-time dashboards, 24 hours for daily reports).

For organisations migrating from Mode, this often means rethinking query design. Mode’s query editor is optimised for ad-hoc exploration. Superset is optimised for dashboard performance, which requires more deliberate query optimisation.

Infrastructure and Deployment

For mid-market organisations, we recommend:

Option 1: Kubernetes (AWS EKS, Google GKE, Azure AKS)

• Pros: Highly scalable, cloud-agnostic, industry standard.
• Cons: Requires Kubernetes expertise.
• Cost: $400–$800/month for compute + $100–$300/month for managed database.

Option 2: Docker Compose (Single Server)

• Pros: Simple to deploy, minimal operational overhead.
• Cons: Not suitable for >500 users or mission-critical deployments.
• Cost: $100–$300/month for a single EC2 or VM instance.

Option 3: Managed Superset (Preset)

• Pros: No operational overhead, built-in backups and monitoring.
• Cons: Less control over infrastructure, potential vendor lock-in.
• Cost: $1,500–$3,000/month.

For organisations pursuing compliance, we recommend Option 1 (Kubernetes on your own AWS/Azure account) or Option 3 (Preset with SOC 2 attestation). This gives you audit control and data residency guarantees.

See our platform development services across Australia for guidance on architecting Superset deployments in compliance-sensitive environments.

---

Dashboard and Query Migration Workflow {#dashboard-migration}

Now that infrastructure is ready, migrate dashboards. This is the most time-intensive phase.

Exporting Mode Dashboards

Mode doesn’t have a native bulk export feature, so you’ll need to export dashboards manually or via the Mode API:

1. Manual export: For each Mode dashboard, take screenshots and document the SQL queries, filters, and visualisation types. This is tedious but thorough.
2. API-based export: Use Mode’s REST API to programmatically fetch dashboard definitions, queries, and metadata. This requires Python or JavaScript scripting but scales better for 50+ dashboards.

For each dashboard, document:

• Dashboard title and description.
• Owner and stakeholders.
• Refresh cadence (real-time, hourly, daily, weekly).
• Filters and parameters (date range, region, product, etc.).
• Charts and visualisations (bar, line, table, map, etc.).
• Data sources (which databases and tables).
• SQL queries (exact query text).

Recreating Dashboards in Superset

Superset’s dashboard creation workflow differs from Mode’s:

Step 1: Create datasets

Instead of writing raw SQL in each chart, Superset encourages creating datasets—reusable SQL queries or table definitions that power multiple charts. This reduces duplication and simplifies governance.

For each Mode query, create a Superset dataset:

-- Example: Orders by region (Mode query)
SELECT 
  region,
  SUM(revenue) AS total_revenue,
  COUNT(*) AS order_count,
  AVG(order_value) AS avg_order_value
FROM orders
WHERE order_date >= DATE_TRUNC('month', CURRENT_DATE)
GROUP BY region
ORDER BY total_revenue DESC

In Superset, this becomes a dataset called orders_by_region. You can then create multiple charts from this dataset without duplicating the query.

Step 2: Create charts

Superset has a visual chart builder. For each Mode chart:

1. Select the dataset.
2. Choose the visualisation type (bar, line, table, etc.).
3. Configure dimensions (x-axis, grouping).
4. Configure metrics (y-axis, aggregations).
5. Apply filters and sorting.

Superset’s chart builder is more intuitive than Mode’s for simple charts, but less flexible for highly customised visualisations. If you need custom visualisations, you can:

• Use Superset’s plugin architecture to develop custom chart types.
• Embed third-party libraries like Plotly or D3.js.
• Use Superset’s native visualisations (Echarts, Apache ECharts) and accept some styling limitations.

Step 3: Create dashboards

Organise charts into dashboards. Superset supports:

• Tab-based navigation: Organise charts into tabs within a dashboard.
• Filters and parameters: Add dashboard-level filters (date range, region, etc.) that cascade to all charts.
• Drill-down interactions: Click a bar chart to drill into detailed data.
• Scheduled emails: Set up nightly or weekly email delivery of dashboard snapshots.

Handling Mode-Specific Features

Mode has features that don’t map directly to Superset:

Mode: Saved queries and query versioning

Mode allows analysts to save and version SQL queries, with comments and collaboration. Superset doesn’t have built-in query versioning. Instead:

• Store queries in version control (GitHub) alongside your analytics codebase.
• Use dbt (data build tool) to manage SQL transformations and documentation.
• Reference dbt models in Superset datasets.

This approach is actually superior for mid-market organisations because it centralises analytics code and integrates with CI/CD pipelines.

Mode: Scheduled reports and alerts

Mode allows you to schedule dashboard snapshots to be emailed or sent to Slack. Superset supports this natively via:

• Alerts: Trigger notifications when a metric exceeds a threshold.
• Reports: Schedule dashboard snapshots to be emailed on a recurring basis.
• Slack integration: Send chart snapshots directly to Slack channels.

Configure these during the dashboard creation phase.

Mode: Embedded dashboards

If you’re embedding Mode dashboards in your product or internal tools, Superset offers better options:

• Superset embedded dashboards: Use Superset’s embedding API to embed dashboards in your application with full branding control.
• Row-level security (RLS): Automatically filter data based on the logged-in user, enabling multi-tenant dashboards.
• Guest access: Share dashboards with external users without requiring Superset accounts.

For SaaS organisations, embedded Superset dashboards are often the primary reason to migrate from Mode.

Quality Assurance and Validation

After recreating each dashboard in Superset, validate it:

1. Data accuracy: Do the numbers match Mode? Run the same query in both tools and compare results.
2. Visualisation accuracy: Do charts look the same? Check colours, labels, axes, and legends.
3. Filter functionality: Do dashboard filters work correctly? Test with multiple filter combinations.
4. Performance: Do dashboards load in <3 seconds? If not, optimise queries or add caching.
5. Accessibility: Do dashboards comply with WCAG 2.2 accessibility standards? Test with screen readers and keyboard navigation.

Create a QA checklist for each dashboard and have business stakeholders sign off before cutover.

---

The Cutover Pattern: Timing and Sequencing {#cutover-pattern}

Cutover is the moment when users switch from Mode to Superset. Timing and sequencing matter.

Phased Cutover Approach

Rather than a “big bang” cutover, use a phased approach:

Phase 1: Pilot (Week 1–2)

• Migrate 5–10 dashboards used by a single team (e.g., Finance or Marketing).
• Invite that team to use Superset in parallel with Mode.
• Gather feedback on usability, performance, and missing features.
• Fix issues and refine the process.

Phase 2: Expansion (Week 3–6)

• Migrate dashboards for 2–3 additional teams.
• Ensure teams are comfortable with Superset before moving on.
• Document common questions and create runbooks.

Phase 3: Full Cutover (Week 7–8)

• Migrate remaining dashboards.
• Set a date when Mode will be decommissioned.
• Ensure all users have access to Superset and have completed training.

Timing Considerations

Choose a cutover window that minimises disruption:

• Avoid quarter-end or fiscal year-end: Finance teams rely heavily on dashboards during closing periods.
• Avoid major product launches or campaigns: Marketing teams need stable reporting.
• Schedule for early in the week: If issues arise, you have the rest of the week to resolve them.
• Plan for 2–3 weeks of parallel running: Keep Mode accessible during this period so users can compare results and build confidence.

Decommissioning Mode

Once Superset is live and stable (typically 2–4 weeks post-cutover):

1. Announce the decommission date: Give users 1–2 weeks’ notice.
2. Archive Mode data: Export any dashboards, queries, or reports that might be useful for historical reference.
3. Cancel Mode subscription: Realise cost savings.
4. Document lessons learned: What went well? What would you do differently?

---

Post-Migration Optimisation and Runbook {#post-migration}

Migration doesn’t end on cutover day. The first 4–8 weeks post-migration are critical for stabilisation and optimisation.

Performance Tuning

Monitor dashboard load times and query performance:

1. Identify slow queries: Use Superset’s query log to find queries taking >10 seconds.
2. Optimise or cache: Either optimise the query (add indexes, materialise intermediate results) or increase cache TTL.
3. Set query limits: Prevent runaway queries by setting row limits and query timeouts.
4. Use pre-aggregated tables: For complex dashboards, consider pre-computing aggregations in your data warehouse.

Target metrics:

• Dashboard load time: <3 seconds for 90th percentile of users.
• Chart query time: <5 seconds for 95th percentile of queries.
• Cache hit rate: >70% (indicating effective caching).

User Training and Adoption

Superset’s interface is different from Mode’s. Invest in training:

1. Live training sessions: Conduct 30–60 minute sessions for each team, covering:
   • How to navigate dashboards.
   • How to use filters and parameters.
   • How to export data.
   • How to request new dashboards or datasets.
2. Self-service documentation: Create a wiki or knowledge base with:
   • Screenshots and walkthroughs.
   • FAQs.
   • Video tutorials.
   • Troubleshooting guides.
3. Office hours: Designate 1–2 hours per week for analysts and users to ask questions.

Track adoption metrics:

• Active users: % of users logging in weekly.
• Dashboard views: Total dashboard views per week.
• Query submissions: Number of new queries created per week.

Target: >80% of previous Mode users active in Superset within 4 weeks of cutover.

Runbook and Operational Procedures

Document operational procedures for your Superset instance:

1. Backup and recovery: How often are backups taken? How long does recovery take?
2. Monitoring and alerting: What metrics are monitored? What triggers an alert?
3. Incident response: What’s the process if Superset is down? Who do you contact?
4. Capacity planning: How do you know when to scale infrastructure?
5. Security patching: How often are Superset and dependencies updated?
6. Access management: How do you onboard new users? How do you offboard users?

Create a runbook (1–2 page document) that covers these procedures. Include:

• On-call contact: Who to call if Superset is down.
• Escalation path: Who to contact if on-call can’t resolve the issue.
• Maintenance windows: When is Superset unavailable for updates?
• Backup schedule: How often are backups taken and tested?

Continuous Improvement

Post-migration, establish a cadence for improvement:

1. Monthly retrospectives: Gather feedback from users. What’s working? What’s broken?
2. Quarterly roadmap planning: Prioritise new dashboards, datasets, and features.
3. Annual architecture review: Is the current infrastructure still appropriate? Should you scale up or down?

For organisations working with a specialist partner like PADISO, this might include quarterly strategy sessions and ongoing optimisation support.

---

Common Pitfalls and How to Avoid Them {#pitfalls}

Based on dozens of Mode-to-Superset migrations, here are the most common pitfalls and how to avoid them.

Pitfall 1: Underestimating Scope

The problem: You discover 50% more dashboards and queries than you initially inventoried. Timeline and budget blow out.

How to avoid it:

• Conduct a thorough asset inventory during discovery.
• Retire unused dashboards before migration (aim to migrate only 60–80% of Mode dashboards).
• Build 20% buffer into your timeline estimate.

Pitfall 2: Ignoring Data Governance

The problem: You migrate dashboards but don’t set up row-level security, audit logging, or data classification. Post-migration, you realise analysts have access to data they shouldn’t.

How to avoid it:

• Design your RBAC and data governance model before creating dashboards.
• Use Superset’s audit logging from day one.
• Implement row-level security for sensitive datasets.
• Conduct a security review before cutover.

Pitfall 3: Poor Query Performance

The problem: Dashboards load slowly in Superset compared to Mode. Users complain about performance.

How to avoid it:

• Profile query performance in Superset before cutover.
• Optimise queries in your data warehouse (add indexes, materialise views).
• Configure caching appropriately.
• Set query timeouts to prevent runaway queries.
• Monitor query performance post-migration and iterate.

Pitfall 4: Insufficient User Training

The problem: Users struggle to navigate Superset. Adoption stalls. You’re forced to keep Mode running longer than planned.

How to avoid it:

• Invest in training early and often.
• Create comprehensive documentation.
• Designate a “super-user” for each team who can help peers.
• Run office hours for the first 4–8 weeks post-migration.
• Gather feedback and iterate on training materials.

Pitfall 5: Inadequate Infrastructure Planning

The problem: Superset runs out of memory or CPU under load. You didn’t plan for growth.

How to avoid it:

• Capacity plan for 2x your current user base.
• Use load testing to simulate peak usage.
• Configure auto-scaling if using Kubernetes.
• Monitor infrastructure metrics (CPU, memory, disk) continuously.
• Plan quarterly reviews to assess capacity needs.

Pitfall 6: Losing Institutional Knowledge

The problem: Mode dashboards have comments and query explanations that don’t make it into Superset. New analysts don’t understand the data logic.

How to avoid it:

• Document dataset definitions, sources, and refresh cadences.
• Add descriptions to charts and dashboards in Superset.
• Maintain a data dictionary (wiki or spreadsheet) outside Superset.
• Use dbt to document SQL transformations.
• Conduct knowledge transfer sessions with domain experts.

---

When to Partner with a Specialist {#specialist-partner}

Migrating from Mode to Superset is complex. Depending on your team’s capacity and expertise, you may benefit from external support.

When to DIY

You have the capacity to migrate in-house if:

• You have 1–2 full-time analytics engineers or data engineers.
• You have <50 dashboards to migrate.
• Your data governance requirements are straightforward (basic RBAC, no row-level security).
• You have Kubernetes or DevOps expertise in-house (if self-hosting).
• Your timeline is flexible (8–12 weeks).

When to Partner

Consider external support if:

• You have >100 dashboards to migrate and limited in-house capacity.
• Your data governance requirements are complex (row-level security, data classification, compliance).
• You need to maintain uptime during migration (parallel running of Mode and Superset).
• You’re embedding Superset in a product and need to design multi-tenant architecture.
• You’re pursuing SOC 2 or ISO 27001 compliance and need audit-ready infrastructure.
• Your timeline is tight (4–6 weeks).

A specialist partner can:

• Accelerate discovery and scoping: Leverage experience from other migrations to identify risks early.
• Design governance and security: Ensure your Superset instance is audit-ready and compliant.
• Optimise infrastructure: Right-size compute, storage, and networking for your use case.
• Manage cutover risk: Execute phased migrations with minimal disruption.
• Provide ongoing support: Offer runbooks, training, and post-migration optimisation.

For mid-market organisations in Australia, PADISO offers platform development and data infrastructure services tailored to Mode-to-Superset migrations. We work with teams across Sydney, Melbourne, and Australia to design, build, and optimise Superset deployments, with particular expertise in embedded analytics, compliance, and multi-tenant architectures.

Our typical engagement includes:

1. Discovery and architecture design (2–3 weeks).
2. Infrastructure setup and security hardening (2–4 weeks).
3. Dashboard and query migration (4–10 weeks, depending on scope).
4. User training and documentation (1–2 weeks).
5. Cutover and post-migration support (2–4 weeks).

We’ve successfully migrated teams from Mode to Superset across finance, insurance, retail, and SaaS sectors. See our case studies for examples.

---

Summary and Next Steps

Migrating from Mode to Superset is a significant undertaking, but for mid-market organisations, the payoff is substantial: 30–50% cost savings, tighter data governance, and the ability to embed analytics as a core product feature.

Here’s your action plan:

Week 1–2: Discovery and Planning

• Inventory all Mode dashboards, queries, and data sources.
• Identify dashboards to retire (aim for 20–30% reduction).
• Define your RBAC and data governance model.
• Estimate timeline and budget using the framework in this guide.
• Decide whether to build in-house or partner with a specialist.

Week 3–4: Infrastructure and Security

• Set up Superset infrastructure (Kubernetes, Preset, or Docker).
• Configure data source connections.
• Implement RBAC and audit logging.
• Conduct security review.

Week 5–10: Dashboard Migration

• Create datasets for each Mode query.
• Recreate dashboards in Superset.
• Validate data accuracy and visualisation correctness.
• Set up scheduled reports and alerts.

Week 11–12: User Training and Cutover

• Conduct live training sessions.
• Run parallel Mode and Superset for 2–4 weeks.
• Execute phased cutover.
• Decommission Mode.

Week 13–16: Post-Migration Optimisation

• Monitor performance and fix issues.
• Gather user feedback.
• Optimise queries and infrastructure.
• Document runbooks and procedures.

If you’re ready to start your migration, or if you’d like to discuss your specific situation, reach out to PADISO. We offer free consultation calls to scope migrations and discuss whether in-house or partnered approaches make sense for your team.

For teams in Sydney and Melbourne, we offer platform development services with deep expertise in analytics infrastructure, compliance, and data governance. For teams across Australia, we work remotely and have experience with organisations of all sizes.

Your analytics infrastructure should be a competitive advantage, not a cost centre. Superset makes that possible.