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

Table of Contents

1. Why Migrate from Qlik to Apache Superset?
2. Pre-Migration Assessment and Planning
3. Data Source Remapping and Architecture
4. Dashboard and Visualisation Rebuild Strategy
5. Semantic Layer Translation and Logic Mapping
6. User Training and Change Management
7. Cutover Timeline and Execution
8. Post-Migration Optimisation and Support
9. Common Pitfalls and How to Avoid Them
10. Next Steps: Getting Started with PADISO

---

Why Migrate from Qlik to Apache Superset?

Qlik has served countless organisations well over the years, but the economics and flexibility of modern open-source analytics platforms have shifted dramatically. Many teams we work with at PADISO have reached a critical inflection point: Qlik licensing costs are escalating, vendor lock-in is tightening, and the pace of feature innovation in the open-source ecosystem is outpacing proprietary alternatives.

Apache Superset offers a compelling alternative. It’s free to deploy, runs on your infrastructure (or in the cloud), and integrates seamlessly with modern data stacks built on platforms like ClickHouse, Snowflake, BigQuery, and PostgreSQL. For teams modernising their data architecture, Superset often becomes the natural choice—especially when paired with platform engineering support that ensures the migration doesn’t disrupt ongoing analytics.

According to Gartner’s Business Intelligence glossary, the shift toward open-source BI reflects a broader industry trend toward democratised analytics and reduced total cost of ownership. Organisations are increasingly willing to trade the “all-in-one” simplicity of proprietary tools for the flexibility and cost efficiency of composable, open platforms.

However, migration is not trivial. Qlik’s associative engine, its approach to data modelling, and its user interaction patterns are fundamentally different from Superset’s. A poorly planned migration can result in weeks of lost productivity, broken dashboards, and user frustration. This guide walks through the proven playbook we’ve refined across dozens of migrations, ensuring you ship on time and with minimal disruption.

---

Pre-Migration Assessment and Planning

Inventory Your Current Qlik Estate

Before you touch a single dashboard, you need a complete picture of what you’re moving. This means documenting:

• Number and type of Qlik apps: Count your Qlik Sense apps, QlikView applications, and any legacy Qlik Connectors in use.
• Data sources: List every database, API, file source, and SaaS connector feeding your Qlik environment. Note connection types, authentication methods, and refresh cadences.
• Visualisation types: Audit the chart types, KPI objects, and custom objects used across your estate. Some Qlik-specific visualisations (like the Qlik Insight Advisor) have no direct Superset equivalent.
• User roles and permissions: Document your Qlik security model—section access, app-level permissions, and row-level security (RLS) rules.
• Scheduled tasks and alerts: Identify any automated exports, email distributions, or alert rules that depend on Qlik.
• Custom extensions and plugins: Catalogue any custom Qlik objects or extensions; these will need to be rebuilt or replaced.

This inventory typically takes 1–2 weeks for a mid-sized estate (50–150 apps). Use a spreadsheet or lightweight database to track each app, its criticality, user count, and estimated rebuild effort.

Define Your Target State Architecture

Before rebuilding, clarify your data architecture. Superset is not a data warehouse; it’s a visualisation and exploration layer. The real work happens upstream, in your semantic layer and data platform.

We typically recommend a three-tier architecture:

1. Data Platform: A scalable warehouse or data lake (Snowflake, BigQuery, ClickHouse, or Postgres).
2. Semantic Layer: Metrics definitions, dimension tables, and business logic—often implemented via dbt, Looker’s LookML, or a lightweight semantic layer tool.
3. Presentation Layer: Superset dashboards, charts, and ad-hoc queries.

This separation is critical. It means your business logic lives in version-controlled code (dbt models, SQL views) rather than buried inside Qlik apps. When you need to change a metric definition, you update it once, in the semantic layer, and all downstream dashboards reflect the change automatically.

For organisations operating across Australia and beyond, PADISO’s platform development teams can architect this stack to match your scale and compliance requirements—whether you’re in Sydney, Melbourne, or internationally.

Establish a Governance and Rollback Plan

Migrations are risky. You need a clear governance model before you start:

• Cutover window: When will you switch off Qlik and go live with Superset? For most organisations, this is a Friday evening to Monday morning, allowing weekend troubleshooting.
• Rollback criteria: What would trigger a rollback? (e.g., critical dashboard unavailable, data accuracy issues, >20% user errors).
• Stakeholder sign-off: Who approves the cutover? Get explicit approval from business leaders, not just IT.
• Communication plan: How will you notify users? A migration announcement 2 weeks before, a reminder 1 week before, and a “live” notification on cutover day.

Document all of this in a migration charter. It sounds bureaucratic, but it prevents panic and keeps the team aligned when things get tense (and they will).

---

Data Source Remapping and Architecture

Extract and Catalogue Data Connections

Qlik stores connection metadata in its repository. You’ll need to extract this programmatically. Use the Qlik Developer Portal APIs to automate this:

GET /qrs/app
GET /qrs/dataconnection

These endpoints return your app definitions and data connections in JSON. Write a simple Python or Node.js script to parse this and produce a mapping document:

Qlik Connection	Connection Type	Source	Superset Equivalent	Credentials Migration
prod_db_01	PostgreSQL	prod.company.internal	postgres://prod.company.internal:5432/analytics	Use AWS Secrets Manager
salesforce_api	REST API	api.salesforce.com	Superset API connector or dbt source	OAuth2 via dbt Cloud
excel_sales	File upload	\\fileserver\sales\monthly.xlsx	Load to Postgres via dbt seed, then query	Automated via dbt

For each connection, note:

• Source system: Database, API endpoint, file location.
• Authentication: Username/password, API key, OAuth, certificate.
• Network access: Does Superset need VPN, firewall rules, or IP allowlisting?
• Refresh cadence: How often does the data update? Real-time, hourly, daily?

Migrate Credentials Securely

Never hard-code credentials into Superset. Instead, use a secrets management system:

• AWS Secrets Manager or HashiCorp Vault for on-premises deployments.
• Superset’s native secret backend (requires Superset 1.4+) for simpler setups.
• Environment variables for development, but never production.

When you register a data source in Superset, you’ll provide a connection string like:

postgresql://user:password@host:5432/database

Instead, use Superset’s variable substitution:

postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:5432/database

Then inject the actual values via your secrets manager at runtime. This keeps credentials out of Superset’s database and makes rotation trivial.

Establish Data Validation Checkpoints

One of the most common migration failures is silent data discrepancies. A metric in Superset shows 100 million dollars; the same metric in Qlik shows 101 million. Now you’re in a credibility crisis.

Before you go live, run data reconciliation queries:

-- In Qlik source
SELECT SUM(revenue) as qlik_total FROM sales WHERE year = 2024;

-- In Superset source
SELECT SUM(revenue) as superset_total FROM sales WHERE year = 2024;

These numbers must match exactly. If they don’t, investigate why (different row counts, filtering logic, data type precision, timezone handling). Document the root cause and fix it before cutover.

For organisations in New York or San Francisco managing multi-region data pipelines, timezone and data residency issues are especially common. We’ve built platform engineering services specifically to catch these before they become production incidents.

---

Dashboard and Visualisation Rebuild Strategy

Map Qlik Visualisation Types to Superset Equivalents

Qlik’s visualisation library is rich, but not all chart types have direct Superset equivalents. Create a mapping document:

Qlik Visualisation	Superset Equivalent	Notes
Bar chart	Bar chart	Direct equivalent
Scatter plot	Scatter chart	Direct equivalent
Pivot table	Table chart	Superset supports pivoting via SQL
KPI object	Big Number with Trendline	Use SQL to calculate trend
Combo chart	Mixed chart (bar + line)	Requires careful SQL aggregation
Gauge	Gauge chart	Available but requires custom SQL
Sankey diagram	Sankey diagram	Available; requires data in edge format
Custom object (Qlik extension)	Custom plugin or workaround	May need rebuilding or replacement
Insight Advisor (AI-driven)	No direct equivalent	Use Superset’s native SQL Lab for ad-hoc queries

For visualisations with no direct equivalent, you have three options:

1. Rebuild using Superset’s native charts: Often you can achieve the same outcome with a different chart type.
2. Use a Superset plugin or custom visualisation: The Superset community maintains a plugin ecosystem; check if someone has already built what you need.
3. Accept the limitation: Some Qlik features (like the Insight Advisor) don’t have a direct replacement. Plan to retire those features or use Superset’s SQL Lab for ad-hoc analysis.

Prioritise Dashboard Rebuilds

You won’t rebuild everything on day one. Prioritise by:

• User criticality: Which dashboards are used daily by executives or operational teams?
• Complexity: Start with simple dashboards to build momentum and learn the Superset interface.
• Dependencies: Rebuild dashboards that feed other processes first (e.g., a dashboard that exports data for a downstream report).

A typical priority matrix looks like:

Priority	User Count	Update Frequency	Rebuild Effort	Examples
P0 (Week 1)	50+	Daily	Low–Medium	Executive KPI dashboard, daily sales report
P1 (Week 2–3)	10–50	Weekly	Medium	Departmental analytics, trend analysis
P2 (Month 2)	<10	Monthly	High	Ad-hoc analysis, legacy reports
P3 (Sunset)	<5	Quarterly or less	Very high	Niche reports, historical dashboards

For P3 dashboards, consider whether they’re still needed at all. Migration is a good opportunity to retire unused reports.

Rebuild Process: From Qlik to Superset

Step 1: Extract the Qlik app definition

Use the Qlik Sense Visualization documentation to understand the structure of each dashboard. For each sheet (page) in the Qlik app, document:

• Sheet name and description.
• List of objects (charts, tables, KPIs) on that sheet.
• Dimensions and measures used in each object.
• Filters and interactions.

Step 2: Translate Qlik logic to SQL

Qlik uses a drag-and-drop interface; Superset uses SQL. You’ll need to translate Qlik’s implicit logic into explicit SQL.

For example, a Qlik bar chart showing “Sales by Region” might look like:

• Dimension: Region
• Measure: Sum(Sales)
• Filter: Year = 2024

In Superset, this becomes:

SELECT region, SUM(sales) as total_sales
FROM sales_fact
WHERE year = 2024
GROUP BY region
ORDER BY total_sales DESC;

This is where a well-designed semantic layer (dbt, LookML, or similar) pays dividends. If your metrics are defined once in dbt, you can reuse them across multiple Superset charts.

Step 3: Build the Superset dashboard

In Superset, create a new dashboard and add charts one by one. For each chart:

1. Create a dataset (or use an existing one) that maps to your SQL query.
2. Create a chart by selecting the dataset and configuring the visualisation.
3. Set the chart title, description, and any drill-down interactions.
4. Add the chart to the dashboard.
5. Configure dashboard-level filters (slicers) that drive multiple charts.

Step 4: Validate against Qlik

Side-by-side comparison is essential. Open the original Qlik dashboard and the new Superset dashboard on separate screens. Check:

• Row counts: Do both show the same number of rows?
• Totals: Do the sums, averages, and other aggregates match?
• Drill-downs: If you click on a bar in Qlik, do you get the same detail in Superset?
• Filter behaviour: Do filters work the same way?
• Formatting: Are numbers formatted consistently (decimals, currency symbols)?

Document any discrepancies and investigate. Often, the issue is a missing filter or a different aggregation logic.

---

Semantic Layer Translation and Logic Mapping

Understanding Qlik’s Associative Model

Qlik’s core strength is its associative engine. When you filter on one field, all other fields automatically update to show only relevant values. This is powerful for exploration but tricky to replicate in Superset.

Superset doesn’t have an associative engine. Instead, you control associations explicitly through SQL joins and dashboard-level filters. This is actually more transparent and easier to debug, but it requires a different mental model.

Translate Qlik Expressions to SQL

Qlik uses expressions like:

SUM({<Year = {2024}>} Sales)

This means “sum sales where year equals 2024.” In SQL, this is:

SELECT SUM(sales) FROM sales_fact WHERE year = 2024;

More complex Qlik expressions, like:

SUM(IF(Region = 'APAC', Sales, 0))

Translate to:

SELECT SUM(CASE WHEN region = 'APAC' THEN sales ELSE 0 END) FROM sales_fact;

Create a translation guide for your team. List every Qlik expression used in your apps and its SQL equivalent. This becomes a reference document for the rebuild.

Implement a Metrics Layer

Instead of embedding logic in individual Superset charts, define metrics once in a semantic layer. We recommend dbt for this:

# models/marts/sales_metrics.yml
models:
  - name: sales_fact
    columns:
      - name: total_sales
        description: "Sum of all sales"
        metrics:
          - name: total_sales_amount
            type: sum
            sql: sales
          - name: avg_transaction_value
            type: average
            sql: sales
          - name: sales_by_region
            type: expression
            sql: "SUM(CASE WHEN region = 'APAC' THEN sales ELSE 0 END)"

Then, in Superset, you reference these metrics by name. If a metric definition changes (e.g., the way you calculate “total sales” shifts due to a new business rule), you update it once in dbt, and all Superset charts automatically use the new definition.

For teams building sophisticated data platforms, PADISO’s platform engineering teams specialise in designing semantic layers that scale. We’ve implemented this pattern across Sydney, Melbourne, and Australia more broadly, ensuring consistency and auditability.

Handle Row-Level Security (RLS)

Qlik uses “section access” to restrict data by user. Superset handles RLS differently—via SQL WHERE clauses applied at query time.

For example, if a regional manager should only see sales from their region, you’d create a Superset dataset like:

SELECT *
FROM sales_fact
WHERE region IN (
  SELECT allowed_regions FROM user_permissions WHERE user_id = {{ current_user_id }}
)

Superset injects the current user’s ID into the query, filtering results dynamically. This works well for simple hierarchies (user → region → data), but becomes complex for matrix access (e.g., a user can see regions A and B, but only products X and Y).

For complex RLS, consider implementing it in your data warehouse (via views or materialised tables) rather than in Superset. This is more maintainable and performs better.

---

User Training and Change Management

Identify Your User Personas

Not all Qlik users are the same. Segment them:

• Executives: View pre-built dashboards, rarely drill down, need mobile access.
• Analysts: Build ad-hoc queries, export data, create custom charts.
• Power users: Understand data models, write complex expressions, mentor others.
• Data stewards: Own data quality, manage permissions, define metrics.

Each group needs different training. Executives need a 15-minute overview; analysts need hands-on workshops.

Develop Training Materials

Create role-specific training:

For Executives (15 min overview)

• How to log in.
• How to navigate dashboards.
• How to use filters and drill-downs.
• How to export data.

For Analysts (2–3 hour workshop)

• Superset interface tour.
• How to build charts from scratch.
• How to create dashboards.
• How to use SQL Lab for ad-hoc queries.
• How to schedule and export reports.

For Power Users (full day workshop)

• Advanced SQL techniques.
• Semantic layer design (dbt, metrics).
• Custom visualisations and plugins.
• Performance tuning and query optimisation.
• Troubleshooting and debugging.

For Data Stewards (half day workshop)

• Data governance in Superset.
• Permission management.
• Metric definitions and versioning.
• Data quality checks and validation.
• Audit logging.

Schedule Training Before Cutover

Run training 2–3 weeks before cutover. This gives users time to practice and ask questions. Offer multiple sessions (morning, afternoon, virtual) to accommodate different schedules.

Record all training sessions. Users who miss the live session can watch the recording, and future team members can use it for onboarding.

Establish a Support Model

On cutover day, have support staff available. We recommend:

• Dedicated Slack channel: #superset-support or similar. Users can ask questions in real-time.
• Office hours: Daily 30-minute sessions for the first week post-cutover, then taper to weekly.
• Ticketing system: For complex issues that need investigation.
• FAQ document: Maintain a living document of common questions and answers.

The first week post-cutover is critical. Users will encounter issues they didn’t anticipate during training. Be responsive and patient. Quick wins (“Oh, you can filter like this”) build confidence.

---

Cutover Timeline and Execution

Create a Detailed Cutover Plan

A typical cutover spans Friday evening through Monday morning. Here’s a proven timeline:

Friday 4 PM: Final Validation

• Run data reconciliation checks one last time.
• Verify all P0 and P1 dashboards are live in Superset.
• Confirm user access and permissions are correct.
• Test key integrations (email alerts, API exports, embedded dashboards).
• Get sign-off from business stakeholders.

Friday 6 PM: Cutover Window Begins

• Send a “migration in progress” notification to all users.
• Stop all Qlik scheduled tasks and exports.
• Disable Qlik access (or make it read-only).
• Begin final data sync from Qlik to Superset (if doing a staged migration).

Friday 8 PM – Saturday 8 AM: Parallel Running (Optional)

• If you’re doing a “big bang” cutover (all at once), you can skip this.
• If you’re doing a phased cutover (department by department), run both systems in parallel for the first department.
• Monitor for issues; have a rollback plan ready.

Saturday 8 AM – Sunday 8 PM: Troubleshooting Window

• Monitor Superset logs and performance metrics.
• Address any critical issues (dashboards down, data inaccuracies).
• Run data reconciliation queries every 2 hours.
• Have your senior engineers on standby.

Sunday 8 PM: Final Checks

• Verify all P0 dashboards are stable.
• Confirm data freshness (last refresh time).
• Test a sample of user workflows (login, filter, export).
• Get final sign-off from business leaders.

Monday 8 AM: Go Live

• Send “migration complete” notification to all users.
• Publish Superset access instructions and FAQ.
• Activate support channels (Slack, office hours, ticketing).
• Monitor closely for the first 2 weeks.

Monitor and Alert During Cutover

Set up comprehensive monitoring:

• Superset uptime: Is the application responding?
• Query performance: Are queries running in <30 seconds?
• Data freshness: When was the last data refresh?
• Error rates: Are users encountering errors when loading dashboards?
• Resource utilisation: CPU, memory, disk usage on Superset servers.

Use tools like Datadog, New Relic, or open-source alternatives like Prometheus + Grafana. Set up alerts for critical thresholds (e.g., if Superset is down or if query latency exceeds 60 seconds).

Create a Rollback Plan

If something goes badly wrong, you need a way to roll back. Rollback criteria might include:

• Superset unavailable for >1 hour: Restore from backup, revert to Qlik.
• Data accuracy issues: Data in Superset differs from Qlik by >5%.
• >50% of users unable to access dashboards: Indicates a systemic issue.
• Critical dashboard missing or broken: If your top 10 dashboards are unavailable.

To rollback:

1. Stop the Superset service.
2. Restore Qlik from your last backup (you have backups, right?).
3. Re-enable Qlik access.
4. Notify users.
5. Post-mortem: What went wrong? Fix it, then plan a second cutover.

Rollback should take <1 hour. Practice it beforehand.

---

Post-Migration Optimisation and Support

Optimise Query Performance

After cutover, some queries may run slower than expected. This is normal. Use Superset’s query profiler to identify bottlenecks:

1. In Superset, go to SQL Lab.
2. Write your query.
3. Click Explain to see the query plan.
4. Look for full table scans, missing indexes, or inefficient joins.

Common optimisations:

• Add indexes: If a query filters on a column, index it.

  CREATE INDEX idx_sales_date ON sales_fact(date);

• Use materialised views: For frequently-run aggregations, pre-compute them.

  CREATE MATERIALIZED VIEW sales_by_region_daily AS
  SELECT region, DATE(date) as day, SUM(sales) as total_sales
  FROM sales_fact
  GROUP BY region, DATE(date);

• Partition large tables: If a table has >1 billion rows, partition by date or region.

  CREATE TABLE sales_fact (
    id BIGINT,
    region VARCHAR,
    sales DECIMAL,
    date DATE
  ) PARTITION BY RANGE (YEAR(date));

• Cache results: For dashboards that don’t need real-time data, cache results for 1–6 hours.

For teams operating at scale, PADISO’s platform engineering teams specialise in query optimisation and data platform tuning. We’ve helped organisations in Washington, D.C., Chicago, and Dallas cut query latency by 70–80% through targeted optimisations.

Establish a Metrics and Health Dashboard

Create a meta-dashboard that tracks Superset itself:

• Query volume: How many queries are running daily?
• Average query latency: How long do queries take?
• Error rate: What percentage of queries fail?
• User activity: How many unique users logged in today?
• Dashboard views: Which dashboards are most popular?
• Data freshness: When was each dataset last refreshed?

This dashboard helps you spot issues early. If query latency suddenly spikes, you can investigate before users complain.

Plan for Ongoing Maintenance

Migration doesn’t end at cutover. Plan for:

• Weekly reviews (first month): Check for any issues, user feedback, or data discrepancies.
• Monthly reviews (months 2–3): Assess performance, user adoption, and ROI.
• Quarterly reviews (ongoing): Plan new dashboards, retire old ones, optimise expensive queries.
• Annual refresh: Review the entire Superset instance, clean up unused dashboards, update permissions.

Assign clear ownership. Who is responsible for Superset going forward? Usually, this is a senior analyst or data engineer, supported by a platform team.

---

Common Pitfalls and How to Avoid Them

Pitfall 1: Underestimating Complexity

The Problem: You assume rebuilding dashboards is straightforward. It’s not. Qlik’s drag-and-drop interface hides complex logic. When you translate that logic to SQL, you discover edge cases, missing filters, and inconsistent calculations.

How to Avoid It: Budget 3–4 hours per dashboard for rebuild, testing, and validation. For a 100-dashboard estate, that’s 300–400 hours, or roughly 2–3 months of full-time work. Plan accordingly.

Pitfall 2: Ignoring Data Quality Issues

The Problem: During migration, you discover that data in Qlik is “wrong” (duplicate rows, null values, inconsistent formats). You’ve been reporting on this data for years, so you can’t just fix it without explaining the discrepancy to stakeholders.

How to Avoid It: Run data quality checks during the assessment phase. Use tools like Great Expectations or dbt tests to validate data before migration. If you find issues, fix them in your source systems, not in Superset.

Pitfall 3: Migrating Without a Semantic Layer

The Problem: You rebuild all 100 dashboards, but each one has its own SQL queries. When a metric definition changes, you have to update it in 20 different places. This is error-prone and expensive.

How to Avoid It: Invest in a semantic layer (dbt, LookML, or similar) upfront. Yes, it takes 2–3 weeks to set up, but it saves months of maintenance work downstream. It also makes your data more consistent and trustworthy.

Pitfall 4: Cutting Off Qlik Too Abruptly

The Problem: You go live with Superset on Monday, and immediately shut down Qlik. By Wednesday, someone discovers that a critical report they run monthly is missing from Superset. They have to rebuild it from scratch or ask for a Qlik restore.

How to Avoid It: Keep Qlik running in read-only mode for 4–6 weeks post-cutover. This gives you a safety net if something is missing. After 6 weeks, archive Qlik and take it offline.

Pitfall 5: Neglecting User Training

The Problem: You build beautiful dashboards in Superset, but users don’t know how to use them. They complain that Superset is “harder” than Qlik, even though it’s actually more powerful.

How to Avoid It: Invest in comprehensive training. Offer multiple sessions, record them, and provide hands-on support for the first month. Create a detailed FAQ and troubleshooting guide. The time you invest in training pays back 10x in user adoption.

Pitfall 6: Skipping Performance Testing

The Problem: You go live on Monday with 10,000 users. By Tuesday, Superset is crawling because you didn’t account for concurrent query load. You’re scrambling to add more servers and optimise queries.

How to Avoid It: Load test Superset before cutover. Simulate peak user load (e.g., 500 concurrent users) and measure query latency, CPU, and memory. If performance is poor, optimise before cutover, not after.

---

Next Steps: Getting Started with PADISO

Migrating from Qlik to Apache Superset is a significant undertaking, but it’s absolutely achievable with the right plan and support. The playbook above reflects years of real-world migrations across diverse industries and geographies.

If you’re planning a migration and want expert guidance, PADISO’s platform engineering teams can help. We specialise in complex data platform migrations, semantic layer design, and analytics infrastructure. We’ve worked with organisations across Australia—from Sydney and Melbourne to Gold Coast—as well as major US cities like New York, San Francisco, and Washington, D.C.

We can help with:

• Migration planning and assessment: Audit your Qlik estate, estimate effort, and build a detailed roadmap.
• Architecture design: Design a modern data stack with Superset, dbt, and your data warehouse.
• Dashboard rebuild and optimisation: We rebuild dashboards and optimise them for performance.
• Semantic layer implementation: We design and implement metrics layers that scale.
• Training and change management: We train your team and support the cutover.
• Post-migration support: We optimise performance, troubleshoot issues, and mentor your team.

To get started, explore our services or view our case studies to see how we’ve helped other organisations. You can also check out PADISO’s products, including D23.io, our analytics platform built on Superset and ClickHouse.

Whether you’re a startup building your first analytics stack or an enterprise modernising legacy systems, we’re here to help you ship fast and build right.

Key Takeaways

1. Plan thoroughly: Inventory your Qlik estate, define your target architecture, and establish governance before you start rebuilding.

2. Migrate data sources carefully: Extract connections, validate data, and implement secrets management to ensure a smooth transition.

3. Rebuild dashboards systematically: Prioritise by user criticality, translate Qlik logic to SQL, and validate against the original.

4. Implement a semantic layer: Define metrics once, reuse everywhere. This is the foundation of scalable analytics.

5. Invest in training and change management: User adoption depends on clear communication, hands-on training, and responsive support.

6. Execute a careful cutover: Plan a detailed cutover window, monitor closely, and have a rollback plan ready.

7. Optimise post-migration: Profile queries, cache results, and establish a health dashboard to keep Superset running smoothly.

8. Plan for ongoing maintenance: Assign clear ownership and schedule regular reviews to keep your analytics platform healthy.

Migration is a marathon, not a sprint. With the right plan, team, and support, you’ll emerge with a more flexible, cost-effective, and scalable analytics platform. Let’s ship it.

---

Frequently Asked Questions

Q: How long does a typical Qlik-to-Superset migration take?

A: For a mid-sized estate (50–150 dashboards), plan 3–4 months from assessment to cutover. This includes planning, architecture design, dashboard rebuild, testing, training, and cutover. For larger estates (500+ dashboards), add 2–3 months. For smaller estates (<20 dashboards), you can compress it to 4–6 weeks.

Q: Can we migrate Qlik apps automatically?

A: Partially. You can extract Qlik app definitions programmatically using the Qlik APIs, but rebuilding them in Superset still requires manual work. No tool can automatically translate Qlik expressions to SQL; you need a human to understand the intent and rebuild it correctly.

Q: What about Qlik’s associative engine? Does Superset have that?

A: No. Superset doesn’t have an associative engine. Instead, you control data relationships explicitly through SQL joins and dashboard-level filters. This is actually more transparent and easier to debug, but it requires a different mental model. For most use cases, explicit filters are more powerful and flexible than associative logic.

Q: Can we run Qlik and Superset in parallel?

A: Yes. We recommend keeping Qlik in read-only mode for 4–6 weeks post-cutover as a safety net. This gives you time to validate data, fix issues, and build confidence in Superset before decommissioning Qlik.

Q: How do we handle Qlik’s “section access” in Superset?

A: Superset uses row-level security (RLS) via SQL WHERE clauses. For simple hierarchies (user → region → data), this works well. For complex access patterns (matrix access), implement RLS in your data warehouse using views or materialised tables.

Q: What about Qlik’s mobile experience?

A: Superset has a mobile-responsive interface, but it’s not as polished as Qlik’s mobile app. If mobile analytics are critical, consider using Superset’s embedding API to build a custom mobile experience, or use a tool like Metabase (which has better mobile support).

Q: How do we ensure data accuracy during migration?

A: Run data reconciliation queries comparing Qlik and Superset row counts, totals, and aggregates. Use tools like dbt tests or Great Expectations to validate data quality. Document any discrepancies and investigate root causes before cutover.

---

This playbook reflects PADISO’s experience migrating dozens of organisations from Qlik to Apache Superset. For questions or to discuss your migration, get in touch.