What the Qlik Sense end of support date forces you to decide
A team running an older client-managed Qlik Sense Enterprise on Windows release has to choose a path before support ends: upgrade to a current release, move to Qlik Cloud, or replace Qlik with a self-hosted tool such as Apache Superset or Metabase. Each client-managed release is supported for two years, so an install that has fallen behind the current release line faces a forced upgrade or a exit. The month-named releases, such as November 2025 and May 2026, are the reference points for checking where your installed version sits. Confirm the exact end-of-support date for your build with Qlik's release lifecycle documentation and your account team, because the date is set per release and is not something to estimate from the release name.
Upgrading keeps your current model: the same client-managed server, the same QMC administration, the same apps and the same license relationship with Qlik. Moving to Qlik Cloud changes hosting and the commercial model, and it moves your data and access controls into a service that Qlik operates. Replacement with Apache Superset or Metabase changes the application layer entirely, so your load scripts, set analysis and associative selections must be rebuilt as SQL datasets, questions or dashboards. That rebuild and the export of QVF files are the work that cannot be finished in the last weeks before a deadline. Start an inventory of apps, data connections and active users now, and decide the path before the support date forces it.
The first decision is whether your estate is mostly developer-built apps with complex scripts or mostly published dashboards used by readers. The second is whether your warehouse can serve the queries those dashboards need without the in-memory model. Ask Qlik to confirm, in writing, which upgrade paths and Qlik Cloud options apply to your current release and license type. For any replacement, run a staged pilot on one high-use app while the Qlik install is still supported, so the cutover is a planned step rather than an emergency.
Requirements the end of support deadline imposes
Each card is a decision or check that a Qlik Sense Enterprise on Windows estate faces before its client-managed release leaves support. Work through them in order: fix the target release, inventory what depends on it, choose the hosting model, then export and cut over while support still runs.
Pick a supported release
Client-managed Qlik Sense Enterprise on Windows ships in month-named releases, such as November 2025 and May 2026. Each release has a published end of support date, and an install outside its support window faces a forced upgrade. Confirm the exact end of support dates for your version in Qlik's lifecycle documentation, then map them to your budget and change calendar. Choosing the target release early sets the upgrade path and the window available for any replacement.
Inventory apps, connections and users
List every published app, data connection, extension and user group in the QMC. Note which apps feed scheduled reloads, which use ODBC connections, and which depend on custom extensions, since those items must be rebuilt by hand. Record the owner of each app and who has opened it recently. Apps nobody uses can be retired before migration, which shrinks both the export and the rebuild scope. This inventory is the baseline for every estimate you request.
Decide the hosting model
Three paths remain: upgrade the client-managed install, move to Qlik Cloud Analytics, which Qlik hosts and manages, or self-host a replacement such as Apache Superset or Metabase in your own infrastructure. Each path carries different recurring costs and assigns patching, backup and access control to different owners. Ask Qlik for a written description of what upgrading and cloud migration involve for your estate, and confirm where data and metadata must reside under your policies before deciding.
Size the replacement runtime
A self-hosted Superset deployment needs a metadata database, and its configuration documentation lists PostgreSQL 10 to 17 and MySQL 5.7 and 8.x as supported versions. Alerts, reports, async queries and dashboard thumbnails also need a caching layer and Celery workers, with Redis common in installs. Metabase recommends PostgreSQL for its application database. Confirm which components your platform team supports and whether they fit your hosting standards before the pilot starts.
Export Qlik content before cutoff
Export QVF files from the QMC while the install still receives support, then test that each file opens in a restored environment. Exports include app logic and load scripts, and whether data travels with them depends on the export option you choose. Confirm that your data classification rules allow the export to be stored outside Qlik. Keep exports in controlled storage with a checksum log, and confirm that administrators hold the rights the export requires.
Run a parallel cutover
Plan a cutover that finishes exports, rebuilds priority dashboards and retires Qlik access before the support end date, with a buffer for rework. Run the replacement beside Qlik with the same users and compare key figures against agreed reference values. For Superset, back up the metadata database, test each upgrade in staging and check UPDATING.md for breaking changes. Switch off the Qlik install only after written sign-off from the business owners.
How upgrade, Qlik Cloud and replacement compare on effort and control
Upgrading a client-managed Qlik Sense Enterprise on Windows install keeps your data, server and apps inside infrastructure your team runs. Qlik supplies the installers, release notes and documentation. The effort falls on your team: scheduling the outage window, testing apps and extensions on the new release, and confirming that connectors and ODBC drivers still work. Because each release has a fixed support window, this path also recurs, since you must repeat the cycle for every future release.
- Control: Data, the server and the application layer stay in your Windows environment.
- Qlik hosts: Nothing in production. Qlik provides software and documentation only.
- Recurring work: Tracking each release's end-of-support date, planning upgrades ahead of it, and retesting apps after every cycle.
- Hidden effort: Custom extensions, data connections and scheduled tasks often need rework or validation on the new release.
- Licensing: Confirm in writing that your current entitlement covers the target release and any maintenance terms.
Before committing, check the end-of-support date for your installed release in Qlik's documentation and build the upgrade plan around that date.
Qlik Cloud is a SaaS option hosted and managed by Qlik. You trade infrastructure control for a vendor-operated platform. Your team still manages tenant configuration, spaces, identity integration and access policies, but Qlik runs the servers, storage and platform operations. The migration is a rebuild rather than a file move, because apps, data connections and automations must be recreated for the cloud model, and any on-premises source must be reachable from it through a route you design and secure.
- Control: Tenant settings, spaces and user roles remain with your administrators.
- Qlik hosts: Application servers, the analytics engine, storage and platform patching.
- Recurring work: Reviewing consumption against your plan, maintaining identity and data gateway connections, and reviewing Qlik service changes.
- Data path: Connectivity from the cloud to internal databases needs network design, approval and monitoring.
- Compliance evidence: Ask Qlik which audit logs you can export and where the tenant runs.
Ask Qlik for written documentation on hosting location and log access, then have your compliance and security teams review it against your own requirements.
Apache Superset is released under Apache-2.0 and has no paid edition. Replacing Qlik with Superset moves the platform, the data flow and the operating burden into your infrastructure. You choose the deployment model, the metadata database and the authentication setup. Qlik's in-memory associative logic and load scripts do not carry over directly, so transformations move into SQL datasets in your warehouse or a transformation tool, and dashboards are rebuilt on top of them. Cost shifts toward engineering time, hosting and support.
- Control: Full control over deployment, authentication, secret keys and upgrade timing.
- You host: The web application, a PostgreSQL or MySQL metadata database, and, for alerts, reports and async queries, the caching and Celery worker components.
- Recurring work: Patching, running database upgrades after each version change, backing up the metadata database, and monitoring workers.
- Rebuild: Load script logic becomes warehouse SQL, and set analysis becomes metrics in the semantic layer.
- Deployment choice: The Kubernetes Helm chart is marked deprecated in current development docs, so confirm which installation method your team will standardize on.
Run a pilot with a representative set of dashboards in a staging environment before setting a cutover date.
Metabase is open core. The Open Source edition is AGPL-licensed and self-hosted, while SSO, row and column level permissions and some identity features sit in paid plans. Replacing Qlik with Metabase suits estates where most users consume dashboards and ask questions of connected databases. Your team owns the application server, the application database and the upgrade process. Control is high, but your access model must fit the plan you choose.
- Control: You run the JAR or Docker image and the application database on infrastructure you manage.
- Plan limits: SSO and row-level permissions require Pro or Enterprise, so the free edition may not meet your access requirements.
- Recurring work: Upgrades run database migrations automatically, so back up the application database first and plan for a single node during major upgrades.
- Release track: LTS releases are supported for 14 months, while non-LTS releases usually reach end of life after about 2 months.
- Air-gapped use: Only the Enterprise plan offers air-gapped deployment, so confirm this requirement early.
Map your access rules and identity provider to a specific plan, and confirm that plan in writing with Metabase before you design the rollout.
Which option fits which Qlik estate
This table compares the main paths for a client-managed Qlik Sense estate: upgrading to a current release, moving to Qlik Cloud, or replacing Qlik with Apache Superset or Metabase. Read each row against your own apps, data sources and user groups. The main takeaway is that the open-source options change how logic is built, so confirm feature parity for your specific apps before you commit.
| Option | Hosting | Licensing and user management | Trade-offs |
|---|---|---|---|
| Qlik Sense upgrade | Your own Windows servers, client-managed | Existing Qlik licensing; confirm entitlement and upgrade path with Qlik | Keeps the associative engine and load scripts; each release has a finite support window |
| Qlik Cloud Analytics | SaaS hosted and managed by Qlik | Capacity-based subscription; confirm tiers and data residency with Qlik | Removes Windows server management; apps still need review and data connections must be re-established |
| Apache Superset | Self-hosted in your infrastructure; metadata in PostgreSQL or MySQL | Apache-2.0 with no paid edition; database, LDAP and OAuth sign-in | Requires SQL datasets in place of associative load scripts; cross-filters must be rebuilt |
| Metabase Open Source | Self-hosted from the open-source image; PostgreSQL recommended for production | AGPL-3.0 edition with unlimited users; SSO and row-level permissions need paid plans | Suits users who explore questions and dashboards; complex set analysis moves into SQL |
| Metabase Pro or Enterprise | Self-hosted; air-gapped deployment only on Enterprise | Paid plans add SSO and row and column permissions; Enterprise is quoted | Choose when row-level security is required; confirm plan scope against your access model |
| Feature parity for your apps | Applies to every option | Confirm each sheet, expression, extension and access rule before choosing | Test your heaviest apps in a staging copy before setting any migration deadline |
Export Qlik content while support still runs
This sequence gives you a complete inventory of Qlik apps, connections, extensions and access rules, plus tested exports and a rehearsed import, so the move off an unsupported release is a controlled cutover rather than an emergency.
Inventory apps, streams and data connections
Start by listing every app, stream and data connection on the Qlik Sense Enterprise on Windows site, using the Qlik Management Console (QMC). Record the owner, last reload time, the data sources each app reads and whether any app depends on another app's output. Your Qlik administrator should own this step, with input from the business owners who can say which dashboards are still used. It is done when you have one register that maps every app to its sources and its owner, and each app is marked keep, retire or rebuild.
Export QVF files from the QMC
For each app marked keep, export a QVF file from the QMC, deciding whether to include data. Exports without data are smaller and move the logic, visualizations and load script, but the data must then be reloaded from the source systems after import. The sibling how-to page on exporting Qlik Sense apps covers the export options and bulk export limits, so follow its steps rather than improvising. Store the files in a controlled location with checksums and an export log. It is done when every keep app has a QVF file and a log entry showing who exported it, when and with which data option.
Extract load scripts and business logic
Open each exported app in a development environment and copy its load script, variables, master items and set analysis expressions into a text inventory. Load scripts usually hold the transformations that will move into your warehouse, dbt models or SQL datasets, so this record drives the rebuild estimate. Your data engineers should review it and flag logic that depends on Qlik-specific behavior, such as associative selections. It is done when every keep app has a script file and a list of calculations that must be reimplemented.
Record extensions and ODBC connections to recreate
Document every extension used in the apps, every custom visualization and every ODBC or OLE DB data connection defined in the QMC. Exported QVF files do not carry these connection definitions in a form you can reuse directly, so each one must be recreated on the target platform with its credentials handled through a secrets store. Note the driver version, the connection string pattern (without secrets) and the network path from Qlik to each source. It is done when each connection and extension has a line in the register with its target replacement and an owner for its credentials.
Capture user, group and access rules
Export the list of users, groups and the security rules that control stream and app access from the QMC. Map each Qlik group to the role it needs on the target, and note any section access rules that restrict data rows. Confirm with your identity team how the target platform will authenticate users, since this determines whether groups carry over through LDAP, OAuth or manual assignment. Row-level restrictions need an explicit design on the target, so flag them for security review. It is done when you have an access matrix that lists each group, its apps and the data rules that apply.
Rehearse the import in a non-production environment
Import a representative set of QVF files, or rebuilt equivalents, into a non-production environment that mirrors your production data sources as closely as your policies allow. Reload data, compare key figures and row counts against the production Qlik app, and test that the access matrix behaves as designed. Record every difference and every manual fix, because those become the cutover checklist. Keep Qlik running in production until the rehearsal has produced matching results. It is done when the rehearsal log shows agreed figures for each sampled app and the cutover checklist lists every open item with an owner.
Questions buyers ask before replacing Qlik Sense
How much does it cost to replace Qlik Sense?
Replacement cost has four main parts: licenses, infrastructure, rebuild effort, and the people and support that keep the platform running. Apache Superset carries no license fee because it is licensed under Apache-2.0 and has no paid edition, so recurring spend moves to servers, the metadata database, and the warehouse queries that dashboards will run directly. Metabase's free Open Source edition also has no license fee, but its paid Starter and Pro plans list $100 and $575 per month before annual billing, and Enterprise is quoted starting at $20,000 per year, according to Metabase's pricing page. Most one-time cost sits in rebuilding apps and load script logic. Ask for a written quote that separates each line and states what recurs every year.
Is upgrading Qlik Sense cheaper than replacing it?
Upgrading is usually the smaller change, because apps, load scripts and users stay on the same platform, but it creates a recurring commitment. Each client-managed Qlik Sense release is supported for two years, so an upgrade buys a fixed support window and leaves the exit question open. Replacement costs more up front because dashboards, load scripts and set analysis logic must be rebuilt, but it removes the license dependency on Qlik. A fair comparison prices both options over the same period, covering several support windows, upgrade testing, any Qlik Cloud subscription and staff time. Ask each provider to show those assumptions in writing.
How long does a Qlik to Superset or Metabase migration take?
No duration figure is available for this work, so treat any number you hear as a claim to verify. The length depends on how many apps are in scope, how many load scripts hold transformation logic that must move into the warehouse or dbt, how many set analysis expressions need SQL rewrites, and how many users need training. Superset also needs its metadata database, caching layer and worker processes in place before dashboards go live, and Metabase needs its application database moved off the embedded H2 default for production. Parallel running and a cutover completed before your release reaches end of support add further time. Ask for a written plan with phases, a per-app inventory and a fixed scope.
What does the work need from our internal team?
Your team must own the business definitions, data sources and access decisions, because only your people know which metrics the business trusts and who may see which rows. Platform staff must provide hosting, network paths to the warehouse, identity integration and backup windows. Superset requires a SECRET_KEY before it starts, and its upgrade guidance calls for a metadata database backup, then superset db upgrade and superset init, with staging tests before each production change. Name a reviewer for each dashboard, a sign-off owner for cutover, and someone who reads the breaking-change notes between versions before every upgrade.
Can we migrate off Qlik Sense ourselves?
Yes, a team with SQL skills, container or Kubernetes operations experience and a clear inventory can do it without an outside partner, but the work is more than installing software. Superset installs from PyPI or the SQLite default are not recommended for production, which needs PostgreSQL or MySQL as the metadata database and, for alerts, reports and async queries, a caching layer and Celery workers. The hardest part is rewriting logic that lived in Qlik load scripts and associative selections. If internal capacity is thin, DeployOpen plans, implements, migrates, hardens and documents self-hosted platforms in your own infrastructure under a fixed-scope written agreement, and can continue under a retainer for upgrades and support.
Which Qlik Sense features do Superset and Metabase not cover?
The main gap is Qlik's in-memory associative engine and its load script environment, which neither Superset nor Metabase reproduces directly. Superset queries the warehouse at request time, so performance depends on the database behind it, and dashboards that relied on in-memory speed need a warehouse or modeling layer that answers quickly. Metabase's SSO, row and column level permissions and usage analytics are included only in its Pro and Enterprise plans, so the free edition may not cover access rules you depend on in Qlik today. Check each feature in your inventory against current documentation before committing to a platform.
How do we export Qlik content before end of support?
Start with an inventory of every app, its data connections, users and scheduled reloads, then export the apps you intend to keep while your current release is still supported. Qlik Sense Enterprise on Windows exports apps as QVF files from the QMC, but extensions and ODBC data connections generally must be recreated, so record them during the inventory. Keep the load scripts as text, since they hold the transformation logic you will rebuild in SQL or dbt. Confirm the export options for your specific release in Qlik's documentation, and test one app end to end before starting bulk work.
Evidence to keep for the decision and the cutover
The upgrade-or-replace decision and the cutover both rest on records you can show later. The six artifacts below connect the inventory, the exports, the access model, the reconciliation, the database backups and the approval, so each cutover step can be traced back to a recorded decision. DeployOpen prepares this evidence, but auditors and certification bodies issue any assessment outcome.
App and data connection inventory
List every Qlik Sense app, its owner, its last use, its published or private status, and each data connection it depends on, including ODBC connections, extensions and load script sources. This inventory sets the scope for the decision: apps nobody opens can be retired, while apps tied to fragile connections need rebuilding in SQL before cutover. Record the Qlik release in use, since the forced upgrade question depends on it. Ask the business owner to sign off on each app's disposition.
Exported QVF files and checksums
Keep a copy of each exported QVF file, with the export date, the Qlik release, and whether the export includes data. Compute a checksum for each file and store the checksum list apart from the files, so you can later show that a restored copy matches the original. Note any apps that could not be exported and the reason. Exports are most useful when they are taken while the release is still supported, so record that timing too.
User and group mapping record
Document how Qlik users, groups and access rights map to the roles and groups in Superset or Metabase, and which identity source supplies them. For Superset, this covers AUTH_ROLES_MAPPING for LDAP or OAuth groups. For Metabase, confirm which plan provides SSO and row-level permissions before you commit to a mapping, because those features are limited to the Pro and Enterprise plans. Keep the reviewer's sign-off for each group.
Parallel-run reconciliation results
During a parallel run, compare key figures from the Qlik app with the same measures built on the warehouse query in Superset or Metabase. Record the reference date, the filters applied, the tolerance you accepted and every mismatch with its cause. Load script transformations and set analysis expressions are the most common sources of drift, so log each rebuilt calculation separately. A dashboard is ready to retire only when its reconciliation log shows the agreed tolerance was met.
Metadata database backup records
Keep records of backups for the Superset or Metabase metadata database, including the backup time, the storage location, the restore test result and the version of the application that wrote it. Superset documents backing up the metadata database before superset db upgrade. Metabase recommends backing up the application database before upgrades and warns that migrations run automatically. A backup you have never restored is not evidence, so log the restore test as its own entry.
Signed change approval
Record the approval for each cutover step with the named approver, the change scope, the rollback plan and the date. Tie the approval to the inventory, the checksums and the reconciliation log it relies on, so the decision can be traced later. Your change board's own template should govern this record. Confirm with your internal audit or compliance lead which approval format they expect, because an external assessor will ask for it.
What to confirm with Qlik and your own environment
Start by confirming the end of support date for your installed release in Qlik's own lifecycle documentation and in your Qlik Management Console, because the client-managed product is released under month-named versions and each one is supported for a fixed period. Record the exact build, not only the release name, and check whether a patch can extend your current install long enough to finish an export or a pilot. Ask Qlik in writing which upgrade path it supports from your version, and whether that path includes a license key change or a new license backend connection, since both affect the timeline more than the software itself.
Next, test whether Qlik Cloud meets your hosting and data residency rules before you treat it as the upgrade option. Confirm where tenants are hosted, how the data gateway connects to your on-premises sources, which identity provider you can use, and what audit and key management controls Qlik documents for your region. Compare that answer with the self-hosted option your security team has already approved, so the decision rests on evidence rather than on the lower effort of staying with the same vendor.
Then inventory what will not carry over. List every custom extension, mashup, widget and data connection, along with each load script and its dependencies on specific ODBC drivers or stored procedures. Mark which items Qlik's export tooling captures and which you must rebuild by hand, and confirm the same for the warehouse side: run the heaviest dashboards against your warehouse or reporting database to see whether it can absorb the query load and concurrency your users generate, because a direct-query tool moves that load from Qlik's in-memory engine onto your database.
How DeployOpen plans a Qlik exit under a fixed scope
DeployOpen approaches a Qlik Sense Enterprise on Windows end of support decision as an implementation project inside your own infrastructure, starting with a written inventory of apps, data connections and users. Engagements are fixed-scope, so the deliverables, the exit path and the handover are agreed in writing before any work begins.
How we scope
- Inventory every Qlik app, data connection, extension and user group on your Windows servers before choosing a path.
- Confirm which Qlik release each server runs and where it sits against its end-of-support date.
- Agree in writing whether the work covers upgrade, Qlik Cloud review, or replacement with Apache Superset or Metabase.
How we build
- Export QVF files and published app content while the current installation still supports the export steps.
- Rebuild load script logic as SQL views or dbt models in your warehouse, with tests against the figures Qlik currently shows.
- Stand up the target platform in your own cloud account or data center, with authentication connected to your identity provider.
How we hand over
- Deliver a cutover plan that runs old and new dashboards in parallel, with a rollback path and named owners for each step.
- Document each rebuilt dashboard, its source tables, its refresh schedule and the access rules that apply to it.
- Provide runbooks for backup, upgrades and secret rotation so your team can operate the platform without us.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Upgrades of the chosen platform follow the vendor's documented upgrade steps, tested in staging first.
- Ask for the retainer scope, response expectations and upgrade cadence in writing before you sign the fixed-scope agreement.
