How to migrate from Qlik Sense to Apache Superset before support ends
If your estate runs Qlik Sense Enterprise on Windows on a client-managed release nearing end of support, or a Qlik Cloud renewal is under review, plan the move as a data and logic rebuild, not a file conversion. BI engineers working with the owners of the data warehouse usually carry it out, because the valuable work sits in the load scripts, the data model and the set analysis expressions, not in the dashboards themselves. A QVF export carries the app definition, sheets, visualizations and script, but it does not carry a transferable engine, so Superset cannot open it and reproduce the in-memory associative model. Apache Superset is licensed under Apache-2.0 and has no paid edition, which means the cost question shifts to infrastructure, warehouse capacity and people rather than access licenses.
Effort and risk depend mainly on how much of the Qlik app logic lives in the script. Apps that pull raw tables and do light joins are usually simpler to rebuild as SQL datasets with cross-filters. Apps with heavy transformation, many QVD layers or complex set analysis need those steps moved first into the warehouse or into dbt models, and that work should be scoped before any dashboard is touched. Ask your team to inventory every app, data connection and script section, then mark which metrics users rely on for decisions. Confirm the Qlik release and its end-of-support date in your own Qlik Management Console, and check whether any app depends on extensions or ODBC connections that must be recreated.
Plan the cutover around support, not around the rebuild. Run the old Qlik apps and the new Superset dashboards in parallel for a defined set of business users, reconcile key figures between the two, and only retire a Qlik app once its numbers match. Keep QVF exports, with and without data where the policy allows, in a controlled archive so you can answer questions about past reports after the license lapses. Before go-live, confirm the Superset metadata database, SECRET_KEY handling and authentication approach with your security team, since those settings are required for a production install.
Which Qlik Sense capabilities map cleanly to Superset and which need rework
This table compares Qlik Sense building blocks with their closest Apache Superset equivalents and marks each as clean, needs rework or gap. Read the rows as a planning checklist: the further a Qlik feature depends on the in-memory associative model, the more rebuild effort it implies. The main takeaway is that data logic moves into SQL or a semantic layer, while dashboards and access rules move more directly.
| Qlik Sense capability | Apache Superset equivalent | Migration status |
|---|---|---|
| Load script extraction and transformation | Warehouse SQL, dbt models or views feeding Superset datasets | Needs rework: script logic must be rewritten as SQL or dbt, not copied |
| Associative engine and field selections | SQL WHERE clauses, dashboard native filters and cross-filters between charts | Gap: selections do not carry over one to one; each filter path must be designed |
| Set analysis expressions | SQL aggregates with explicit filters, or metrics defined in a semantic layer | Needs rework: set analysis becomes SQL or semantic logic, validated against Qlik outputs |
| Sheets and visualizations | Dashboards with charts built on datasets | Needs rework: layout and chart types are rebuilt manually, with no automated conversion assumed |
| Published apps and streams | Dashboards published to roles, with ownership held by Superset admins | Needs rework: sharing models differ, so audience lists must be mapped and tested |
| Qlik user access and section access | Row-level security filters on datasets and roles assigned per dataset | Needs rework: row rules must be re-expressed and tested against each role |
| Authentication and group mapping | Database, LDAP or OAuth login, with groups mapped to roles through AUTH_ROLES_MAPPING | Clean: group-based access can be configured, but group names must be confirmed in your identity provider |
| Ad hoc exploration and SQL access | SQL Lab for analysts who write queries against permitted databases | Clean for SQL-literate users; business users need saved charts and dashboards instead |
What the QVF export gives you and what it leaves behind
The QVF export captures the app definition, not the environment around it. From the Qlik Management Console (QMC), you export each app as a QVF file, and the export can be made with or without the app's data. The file holds the load script, the data model, sheets, visualizations, bookmarks and variables, which makes it the most useful single artifact for inventorying what each app does. It does not carry the source systems the script reads from, so the database connections, ODBC data connections, file paths and credentials must be documented separately. Extensions and custom objects are also not reliably self-contained, so list every one that an app references. Confirm the exact export options, the bulk export limit and how published apps behave against the Qlik Sense release documentation for your installed version before you plan the inventory.
Treat the QVF as an inventory input and a logic reference, not a file Superset can import. Apache Superset has no path to load a QVF, so nothing in it moves over as a dashboard. What you take from it is the load script logic, the field definitions, the calculated dimensions and measures, and the set analysis expressions, which you rewrite as SQL views or dbt models and then as Superset datasets, charts and dashboards. Record which apps are exported with data, because embedded data is a snapshot that will not match the warehouse after cutover. For each app, note its owner, its users, its refresh path and the data sources it depends on, so the rebuild has a checklist rather than a guess. Plan the rebuild against the warehouse you will query, and validate the numbers of each rebuilt chart against the Qlik app before any user relies on them.
Which data, scripts and connections need to move
A Qlik Sense app bundles data loading, data connections, visual content and access rules in one file. In Superset these split into separate layers: the warehouse, SQLAlchemy connections, datasets and charts, and roles. Map each component to its target before you export anything, because the QVF file carries the app logic but not the data-side plumbing.
Load scripts to SQL views
Qlik load scripts reshape raw sources into the in-memory model through joins, resident loads, mappings and calculated fields. In Superset, each transformation should live in the warehouse as a SQL view or a dbt model, so datasets point at stable, tested tables. Review each script line by line, because implicit behavior such as Qlik's null handling and join semantics does not carry over automatically. Confirm with your analytics engineers which team owns the transformed layer after cutover.
Data connections to database connections
Qlik data connections, including ODBC and OLE DB sources, must be recreated as Superset database connections. Superset connects to any SQL datastore with a Python DB-API driver and SQLAlchemy dialect, so confirm that a driver exists for each source and that it is approved for your network. Credentials should be stored as secrets in your secret manager, not copied from QMC configuration. Document each connection string pattern for your platform team.
Extensions and custom visualizations
Qlik extensions and custom visualization objects have no direct equivalent in Superset. Most standard bar, line, pivot and map views map to native Superset charts, while bespoke extensions need a rebuild as a Superset chart plugin or a replacement with an existing chart type. Inventory every extension in the app before estimating work, and ask your implementation partner to classify each one as native, configurable or custom build.
User and group mappings to roles
Qlik section access and stream permissions must be re-expressed as Superset roles, and row-level restrictions as Superset row-level security filters. Superset supports database, LDAP and OAuth authentication through Flask AppBuilder and can map LDAP or OAuth groups to roles with AUTH_ROLES_MAPPING. Confirm which directory groups currently grant Qlik access, and test each role against real data in staging.
Scheduled reloads to warehouse jobs
Qlik reload tasks refresh the in-memory data on a schedule, which in Superset becomes a dependency on the warehouse refresh. Move the reload trigger into your orchestrator or dbt schedule so charts read fresh tables, and confirm that the refresh finishes before any dashboard or report is generated. Superset caching settings also affect how quickly new data appears, so review them with the platform owner.
Alerts and subscriptions
Qlik alerts and report subscriptions must be rebuilt as Superset alerts and reports. Alerts and reports, async queries and dashboard thumbnails depend on the caching layer and Celery worker components, so these services must be deployed and monitored before the cutover. Confirm delivery channels, recipient lists and ownership of each subscription, since these are often undocumented.
The migration sequence from inventory to decommission
This sequence moves Qlik Sense content to Apache Superset in controlled stages, so each app is proven against known numbers before users depend on it. It ends with a decommission record that lets the organization prove what was retired, what was kept and why.
Inventory apps, data sources and users
Start by listing every Qlik Sense app, its streams or spaces, its load script sources, its data connections and the groups that open it. Pull usage logs from the QMC or the Qlik audit data so that high-use apps and dormant apps are visible. Assign each app an owner who confirms whether it is still needed. The output is a dependency map that links each app to its sources, downstream sheets, scheduled reloads and consuming groups. The step is done when every app has an owner and a disposition: migrate, merge, retire or keep on Qlik for now.
Export QVF files and script logic
Export the apps you intend to migrate as QVF files from the QMC, and save the load scripts, variables and any master items as text so the transformation logic survives the platform change. Record which extensions and ODBC or OLE DB connections each app needs, because those must be recreated on the Superset side. Store exports in a controlled location with checksums. The output is an export manifest listing each QVF, its checksum, its script version and its missing components. The step is done when a second person has opened the manifest and confirmed nothing on the dependency map is absent from it.
Move script transformations into the warehouse
Rewrite each load script transformation as SQL in the warehouse or as dbt models, with tests on keys, nulls and row counts. Associative selections and set analysis expressions become explicit joins, filters and metric definitions, so the logic sits in a version-controlled layer that Superset queries directly. Confirm which calculations depend on Qlik's in-memory behavior and document how each is reproduced. The output is a versioned set of SQL or dbt models with a mapping table from each Qlik script section and expression to its replacement. The step is done when the models build in a non-production environment.
Build and reconcile a pilot on one high-use app
Choose one high-use app with a clear owner and rebuild it in Superset as SQL-backed datasets, charts and dashboards, using cross-filters where users relied on associative selection. Run the same key figures from the Qlik app and the Superset dashboard for the same filters and period, then investigate every difference until its cause is known. Confirm that Superset's metadata database, SECRET_KEY, authentication mapping and caching are configured as the production design requires. The output is a reconciled pilot dataset with a difference log and the owner's written acceptance. The step is done when the difference log has no unexplained variances.
Run both platforms in parallel
Keep the remaining Qlik apps and the new Superset content live together for a defined period agreed by the business owners, with the same reports checked against each other on a schedule. Track reload failures, row count drift, access requests and user questions in one issue log. Use the reconciliation method from the pilot for each migrated app. The output is a parallel-run log with pass or fail results per app and a list of open defects with owners. The step is done when every migrated app has a sustained record of matching results and no open high-severity defects.
Cut over by user group
Move consumers in groups rather than all at once, starting with the group whose apps reconciled cleanly. Map Qlik access to Superset roles through the LDAP or OAuth group mapping, and test row-level restrictions before each group moves. Announce the cutover date, provide a short guide to the new dashboards and keep a fallback path to Qlik for the agreed period. The output is a signed cutover record per group that lists the apps moved, the roles assigned, the approver and any accepted exceptions. The step is done when each group's owner has signed the record and support tickets for the group are back to baseline.
Decommission with archived QVFs and retained evidence
Once every app in scope is retired or migrated, archive the final QVF files, scripts, export manifest, reconciliation logs and cutover records in write-protected storage with an index that maps each archived item to its original app and owner. Remove the Qlik apps, data connections and service accounts from production, and confirm with the license administrator what must be released or returned under the contract. Keep the evidence for the retention period your records and audit policies require. The output is an archive index and a decommission record signed by the data owner and the security lead. The step is done when the archive has been verified by restoring one sample item and the decommission record is filed.
How the migration changes by estate size and starting point
A client-managed Qlik Sense Enterprise on Windows install that is approaching the end of its support window has the least room for sequencing mistakes. The work is usually paced by the support date rather than by the team's preferences, so the first steps are inventory and export while the vendor's tooling still works. Teams often run the export and the Superset build in parallel and keep the Qlik server available as a reference until the business signs off on the replacements.
- Export first: Confirm which apps can be exported as QVF files from the QMC, and record which ones include data and which do not.
- Triage by usage: Rank apps by who opens them and how often, so the most important dashboards are rebuilt first.
- Keep Qlik readable: Leave the server running in read-only use during the rebuild, and note what must be recreated, such as extensions and ODBC connections.
- Decide early on the fallback: Agree what happens to any app that is not rebuilt before the date, and who approves that outcome.
- Check the release calendar: Confirm your installed version and its end-of-support date with Qlik before setting milestones.
Check with your Qlik administrator which release is installed and when its support ends, then compare that date with the realistic time needed to rebuild your highest-priority apps.
Qlik Cloud Analytics is a SaaS product hosted and managed by Qlik, so the export path and the infrastructure picture differ from a client-managed install. There is no Windows server to retire, but the data, apps and any scheduled reloads still sit in the vendor's tenant until they are moved. Effort tends to concentrate on confirming what can be taken out of the tenant and on the connections that feed the apps, not on decommissioning hardware.
- Confirm the export route: Check with Qlik which app content, data and metadata can be exported from your tenant, since this varies by app type and tenant configuration.
- Map data connections: List every source and connector the apps use, and confirm each one is reachable from your own warehouse or database.
- Plan for reloads: Move scheduled reloads into the warehouse or into dbt jobs so that data freshness does not depend on the tenant.
- Govern access: Map Qlik spaces and permissions to Superset roles and, where you use a directory, to the group mappings in AUTH_ROLES_MAPPING.
- Set an exit date for the tenant: Agree when the tenant is switched to read-only and when subscription renewal ends.
Confirm with Qlik which export options your tenant includes and whether any of your content falls outside them before you commit to a rebuild order.
An estate built around many QVD files and long load scripts carries most of its logic outside the dashboards. In this case the migration is largely a data engineering task: the transformations, joins and incremental loads have to be rebuilt in SQL, usually in the warehouse or in dbt, before any Superset dataset can be trusted. Dashboard work comes after the data model is stable, so the schedule should start with the pipelines.
- Inventory the scripts: List each load script, the QVDs it writes and the apps that read them, and mark which transformations are business rules and which are leftovers.
- Move logic into dbt or the warehouse: Rebuild joins, derived fields and incremental loads as models with tests, so that Superset queries a governed layer.
- Retire the QVD layer deliberately: Decide which QVD files still have consumers, and remove the rest only after those consumers move.
- Validate totals against Qlik: Reconcile key measures between the old apps and the new datasets before any user sees them.
- Plan the scheduler: Replace Qlik reload tasks with orchestrated jobs and set alerting for failed runs.
Review how many QVD files and load scripts your estate contains and which of them feed numbers that finance or regulators rely on, since those drive the validation effort.
An estate made mostly of dashboards that are opened and filtered but rarely changed has a different center of gravity. The data pipelines may already be stable in a warehouse, so the work is concentrated in rebuilding the visual layer and in reproducing associative selections as SQL-driven filters and cross-filters. Users often notice the difference first in interactivity, so testing with real consumers matters more than scripting.
- Catalog dashboards by use: Identify the sheets that users open weekly and the ones that have not been opened in a long time, and retire the latter.
- Rebuild selections as filters: Map each associative selection to a Superset filter or cross-filter backed by a dataset query, and document where behavior differs.
- Test with consumers: Have named business users check each rebuilt dashboard against the Qlik version using the same filters and date ranges.
- Standardize datasets: Create shared datasets so that several charts use the same definitions instead of duplicating logic.
- Define the cutover per team: Move one business area at a time so that feedback from the first group shapes the rest.
Identify which dashboards are used every week and by which teams, since those users will decide whether the rebuilt views are accepted.
What usually goes wrong and how to prevent it
Most failed Qlik to Superset migrations break in the same few places: logic that was never rebuilt, numbers that do not match, and a production install that was never hardened. Each card below names one risk and the check that catches it before users notice.
Assuming associative selections reproduce
Qlik's associative engine lets users click any field and see excluded values in grey without writing a join. Superset has no equivalent, so each dashboard needs explicit SQL datasets and cross-filters for the relationships users rely on. Before cutover, list every selection pattern the business uses on each app and confirm a Superset dataset and filter covers it. Expect some patterns to be dropped on purpose, and get the owner to sign off on those.
Unreconciled numbers between Qlik and SQL
Load script transformations, set analysis expressions and Qlik's null handling often produce totals that differ from the same metric written in SQL. A mismatch found by a finance user after go-live erodes trust in the whole platform. Pick a set of reference KPIs per app, run them in both systems on the same date range, and document every variance down to the row level before any user sees the Superset version.
Warehouse load from unoptimized datasets
Qlik loads data once into memory, so a poorly designed chart costs little after the reload. Superset sends every query to the warehouse, and a dashboard with many unfiltered charts can repeat heavy scans on each refresh. Materialize the heavy transformations in dbt or the warehouse, aggregate to the grain users actually filter on, and set query timeouts and cache rules. Ask the warehouse team for the query cost profile before enabling dashboards for all users.
Superset on SQLite or the Compose container in production
The SQLite default used by Quickstart and PyPI installs, and the PostgreSQL container from Docker Compose, are not recommended for production according to the architecture documentation. Teams that move a pilot into use without rebuilding the metadata store lose dashboards, users and permissions during the first incident. Run the metadata database on a managed or clustered PostgreSQL or MySQL service that is tested with Superset, and confirm the supported versions in the configuration docs before you deploy.
Skipping backups before upgrades
Superset upgrades run database migrations, and a failed run can leave the metadata store in a state that is hard to reverse. The upgrade guidance calls for a metadata database backup, then superset db upgrade and superset init, with a staging test first and a review of UPDATING.md for breaking changes. Build those steps into the runbook, keep the SECRET_KEY recorded in your secrets store, and time the first upgrade after cutover, not during it.
Cutting over before users are trained
Qlik users know a selection-driven interface, and Superset asks them to build charts from datasets and filters. If the Qlik app is switched off before those users can answer their own routine questions, reporting stops and shadow spreadsheets return. Run the old and new versions side by side for a defined period, train each role on the Superset paths that replace their Qlik habits, and set the Qlik decommission date only after the reference KPIs match and the trained users sign off.
What drives the cost and duration of this migration
The largest cost in a Qlik Sense to Apache Superset move is usually internal BI and data engineering time, not software. Apache Superset is Apache-2.0 with no paid edition, so the budget question is who does the work and what the platform costs to run. Most of the effort falls into four buckets: exporting and inventorying QVF files, moving load script logic into the warehouse or dbt models, rebuilding associative selections as SQL datasets with cross-filters, and validating that figures match the Qlik originals. Ask any partner or internal team to estimate each bucket separately by app count and by the number of load script lines that carry business logic. Qlik export steps and the components that must be recreated, such as data connections, are covered elsewhere on this page, so the estimate should reference them rather than repeat them.
Warehouse compute is the cost most teams underestimate. Superset issues SQL directly against your warehouse, so dashboards that Qlik once served from in-memory data now generate recurring queries. Before cutover, measure query volume and concurrency for the top dashboards, and confirm with your warehouse vendor how that load is billed. On the Superset side, plan for the metadata database, which must be PostgreSQL or MySQL for production, and for the optional caching layer and Celery workers. Alerts, reports, async queries and dashboard thumbnails depend on those components, and most installations use Redis and Celery. Each adds hosting, patching and monitoring work, and each is a line item to request in any quote.
The split between one-time and recurring cost matters for the business case. Rebuild work, testing and user acceptance are one-time. Hosting the metadata database, cache and workers, monitoring, backups and the upgrade cycle are recurring. Superset requires backing up the metadata database, running superset db upgrade and superset init, testing in staging and checking UPDATING.md for breaking changes on each version, so budget staff time for every upgrade, not only the first install. Keep the Helm chart versus Kubernetes Operator decision in view early, because the current development documentation marks the Helm chart as deprecated. Finally, decide who provides support after go-live and get that commitment in writing, since a fixed-scope build and an ongoing retainer carry different costs.
Questions teams ask before they migrate from Qlik Sense to Superset
Can QVF files be imported directly into Apache Superset?
No. Superset does not read QVF files, so there is no direct import path from a Qlik Sense app into a Superset dashboard. A QVF export (with or without data, as set in the Qlik Management Console) gives you the app's load script, sheets and visualizations as a reference, but the working logic has to be rebuilt. The load script is the part worth keeping, because its transformations move into SQL in your warehouse or into dbt models. Superset then points at those tables or views as datasets, and its charts, dashboards and filters are recreated on top of them. Plan the rebuild around the data model, not the app file.
How long does a Qlik Sense to Superset migration take, and what drives the timeline?
The timeline depends on how many apps you have, how complex their load scripts and set analysis expressions are, how clean your source data is, and how many people need to validate numbers before cutover. Apps that mostly reshape a few tables into a single dashboard are usually far quicker to rebuild than apps that join many sources and carry a deep library of master measures. Ask any partner to base its estimate on a written inventory of apps, data sources, users and measures, and to state the assumptions behind each duration. DeployOpen sets timelines in the written scope before work starts.
Can our team do the migration without outside help?
Yes, if you have people who can write SQL, model data in a warehouse or dbt, administer a Python web application and run a database. Superset itself is approachable for analysts, but the hard work sits upstream: rewriting associative logic as SQL, deciding where measures live and proving that totals match the old app. Teams that lack one of these skills often bring in outside help for a fixed scope, such as the data model and the authentication setup, while keeping dashboard ownership in house. Whichever path you choose, agree on who signs off numbers before work begins.
What does Apache Superset cost in licensing?
Superset has no license fee. It is licensed under Apache-2.0 by the Apache Software Foundation, and the project has no paid edition. Your costs are the infrastructure to run it, which includes the web application, a PostgreSQL or MySQL metadata database and, if you enable alerts, reports or async queries, a caching layer and Celery workers. Your warehouse compute, staff time, hosting, backups, support and any implementation work are separate line items. Ask any vendor to separate those components so you can compare them with your current Qlik licensing and capacity charges.
How do we upgrade Superset without breaking dashboards?
Treat each upgrade as a tested change. Back up the metadata database first, because dashboards, datasets and permissions live there. Then upgrade in staging, run superset db upgrade to apply schema migrations and superset init to refresh roles and permissions, and check the breaking-change notes in UPDATING.md for every version between your current and target release. Only then promote to production. Keep your SECRET_KEY stable across the change, and use PREVIOUS_SECRET_KEY if you rotate it. Verify key dashboards against saved figures from Qlik before you call the upgrade complete.
Which Superset release should we target for a new deployment?
Pick a stable, supported release rather than a pre-release. The PyPI listing shows 6.0.0 published on December 18, 2025 and 6.1.0 on May 13, 2026, while the GitHub releases page lists 7.0.0rc2 as a pre-release on October 16, 2026. Confirm the current stable line against the release page on the day you start, and review its UPDATING.md before you freeze the version. Also check whether your chosen install method, such as the Helm chart or the Kubernetes Operator, is current for that release.
What should we ask a partner for in a migration quote?
Ask for a written scope that lists the apps in scope, their data sources, the number of users and roles, and which measures and load script logic will be rebuilt. Request the deliverables by name, such as the data model, datasets, dashboards, the authentication setup and the runbook. Ask how numbers will be reconciled against Qlik outputs, who signs off, what is excluded and how post-cutover support is priced. Confirm the timeline, the hosting location and who holds the admin credentials. DeployOpen issues its quote from that written scope, and does not publish a price list.
How DeployOpen scopes and runs the migration
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, whether that is their cloud accounts, data center or air-gapped network. For a Qlik Sense to Apache Superset move, that means DeployOpen works on the Superset deployment itself, the metadata database, the connection to your warehouse, the authentication setup and the cutover plan, all running where your data already lives. Most engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before any work starts. DeployOpen does not publish a price list, so a quote follows from that written scope.
The scope document is where the Qlik-specific decisions get made. It should list which QVF apps are in scope, which load script transformations move into the warehouse or dbt, which dashboards are rebuilt as SQL datasets with cross-filters, which Qlik data connections are replaced, and who signs off on each dashboard's numbers. It should also name the Superset components to be installed, including whether the caching layer and Celery workers are needed for alerts, reports and async queries, and which metadata database version is used. Ask for the staging and rollback steps, the superset db upgrade and superset init procedure, and the backup of the metadata database before each upgrade. Ask for these items explicitly, because they determine what the quote covers.
Ongoing support, upgrades and continuous testing are available as a retainer. That matters after cutover, when Superset releases, dashboard changes and warehouse schema changes keep arriving. Before you sign either a fixed-scope project or a retainer, confirm with DeployOpen in writing which items are one-time deliverables and which recur, and who owns the Superset configuration, dashboards and documentation at handover. DeployOpen prepares systems and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work.
