Keep your QlikView investment. Change the engine.
Your load scripts, your data model and your users' habits took years to build. QlikView.work keeps them and replaces the engine with PostgreSQL, Parquet and DuckDB: open components, no per-user licences, and the same dynamic report your teams already know.
From the .qvw to the report
Three facts about QlikView, checked in October 2026
No new licences
Qlik stopped selling new stand-alone QlikView licences. Growth now means Qlik Cloud, with its own pricing.
12.90 reaches end of support
QlikView 12.90 reaches end of support on 31 October 2026. Each release gets about two years, and each upgrade is a project of its own.
The road leads to Qlik Cloud
Qlik's migration tooling converts .qvw files for Qlik Cloud. Your scripts and your data model do not come with you unchanged, and the licence meter restarts.
Sources: QlikView Product Lifecycle · Migrating QlikView to Qlik Cloud
None of this forces a rewrite. The logic inside your applications is still valid. What changes is the engine underneath it.
The work of years, running on open components
Each QlikView application is mapped, not rewritten. Users see the same report. IT sees standard SQL.
Load scripts and data model
Each QlikView load script becomes a documented silver layer in PostgreSQL, built with dbt. The tables, the keys and the business rules carry over.
The dynamic report
Dimensions and metrics chosen in a side panel, a totals row, rows for metrics that do not split by a dimension, saved reports, Excel and CSV export. Anyone who used QlikView recognises it.
Access rules
Permissions per role and filters per entity, enforced in the API, not in the client. Every user sees exactly what they saw before.
Response time
Each silver build exports a Parquet generation. A DuckDB service loads it in memory and answers aggregations in seconds, as QlikView did.
From a licensed engine to one you own
| QlikView today | With QlikView.work | |
|---|---|---|
| Licences | Per user and per server, with renewals that climb | None. PostgreSQL, DuckDB and Parquet are open source. |
| Engine | QlikView Server, a closed in-memory engine | DuckDB over Parquet, with PostgreSQL as the system of record. |
| Data ownership | Inside .qvd and .qvw files | Standard tables and columnar files you can query with any tool. |
| Support | Vendor lifecycle, about two years per release | Your team, or ours, on standard skills: SQL, dbt, .NET and React. |
| Evolution | Limited to what Qlik ships | New metrics, dimensions and reports added by your own people. |
Four steps from your .qvw files to a validated report
Inventory
We read your QlikView applications and load scripts, list every table, field, metric and report, and tell you what maps directly and what needs a decision.
Silver layer and Parquet
The data model is rebuilt in PostgreSQL with dbt, with reconciliation tables that show where the numbers come from. Every build exports a Parquet generation.
DuckDB service and report
A DuckDB analytics service loads the active generation. The dynamic report runs on it, with your dimensions, your metrics and your access rules.
Parity and go-live
Values are compared with QlikView, entity by entity and month by month, until they match. QlikView stays on until then, so there is no big bang.
Already running for a pharmacy group
values matched against QlikView
Sales with and without VAT, stock value, amount paid by the patient and average prescription value, per pharmacy and month, January to August 2026.
instead of minutes per aggregation
A per-product aggregation that took about 6 minutes in PostgreSQL is answered by DuckDB over Parquet while the user waits.
per-user licences
The whole stack is open source. The cost does not grow with the number of users.
See it on your own data
The demo runs on one of your QlikView applications, not on a sample.
Request a 30-minute demo
Tell us which QlikView application matters most. We show the dynamic report running on the new engine and explain what it takes to map yours.