Migrate from Qlik Sense to Metabase when most users only consume dashboards
If most of your Qlik users open published apps, filter them and export views but rarely build their own analyses, the move to Metabase is mostly a rebuild of dashboards and saved questions on top of your existing databases. The harder work sits upstream: Qlik load scripts and set analysis have to be rewritten as SQL against a warehouse or database, because Metabase does not run an in-memory associative engine. Start by inventorying which apps are used only through Analyzer-style sheets and which contain transformation logic that users depend on. A Metabase question is a saved query over a connected database, so each Qlik expression that aggregates across associated tables needs an explicit join or a view that carries the same logic. Usually an internal data team does this work, often with an implementation partner who sets up the Metabase deployment, the PostgreSQL application database and the upgrade routine. The effort is moderate for a small set of apps and grows with the number of load scripts and custom expressions. The risk is mainly in numeric drift between old and new figures, so plan parallel runs for the metrics executives watch.
Your Metabase plan decision follows from two requirements you should settle before building. The free Open Source edition covers self-hosting with unlimited users and dashboards, but according to Metabase's pricing page, SSO and row and column level permissions are included only in the Pro and Enterprise plans, and Starter does not include them either. If your Qlik estate restricts data by section access or user group, confirm whether you need row-level permissions in Metabase, and if you need SAML or OIDC sign-in, confirm which plan provides it. Ask Metabase which plan includes the features you need, and get that in writing with the quote. Cost components to model include the Metabase subscription if you buy one, the database and hosting you already run, the time to write SQL for each migrated app, and ongoing upgrades of the application. Check the Metabase version support page to match your upgrade cadence to an LTS release.
What maps from Qlik Sense to Metabase feature by feature
This table compares the Qlik Sense capabilities that Analyzer users rely on with their Metabase equivalents. Each row is marked clean, needs rework or gap, so you can see which dashboards move directly and which need redesign in SQL or permissions setup before cutover.
| Qlik capability | Metabase equivalent | Status |
|---|---|---|
| Sheets and dashboards | Metabase dashboards built from saved questions, with filters wired to cards | Clean for chart-based sheets; confirm layout fidelity with users |
| Analyzer selections | Interactive dashboard filters and drill-through; ad hoc exploration in the query builder | Needs rework; associative selections must become explicit filters or SQL |
| Bookmarks | Saved questions with stored filter values, or dashboard filter defaults | Needs rework; bookmarks have no one-to-one object |
| Published apps and streams | Collections for organizing content, with collection-level permissions | Clean for organization; streams as publishing gates have no direct match |
| Access control on apps and data | Groups with data permissions and collection permissions; row-level rules need Pro or Enterprise | Gap on Open Source and Starter; confirm plan before design |
| Set analysis expressions | SQL questions or saved metrics in the semantic layer, written against the warehouse | Needs rework; expressions must be rewritten as SQL |
| Load script transforms | SQL in the warehouse, dbt models or views feeding Metabase tables | Needs rework; transforms move out of the app |
| Extensions and custom visuals | Limited native equivalent; confirm chart types or plan iframe or embedded alternatives | Gap; inventory each extension before migration |
| Embedding into other apps | Embedding documented in Metabase's embedding introduction; confirm plan and setup | Clean for supported embedding; confirm against your use case |
Which exports and integrations to move, and which to rebuild
Qlik content reaches Metabase through three paths: the app export, the SQL behind each app, and the people and connections around them. Each path has a different owner and a different finish line, so inventory them before you build anything.
QVF exports are an inventory, not a migration
Qlik Sense apps can be exported as QVF files from the QMC, and the export is the first document to keep. A QVF holds the data model, load script, sheets and visualizations, but Metabase cannot open it. Use each file as the specification for the questions and dashboards you rebuild, and record which sheets, measures and filters each app actually serves. Confirm with the QMC administrator whether each export includes data or only the app definition, because the answer changes the source-data plan. Treat the QVF as a blueprint, not as the migrated app.
Recover the SQL behind each app
Each Qlik app loads its data through a load script, which may read database tables, SQL SELECT statements, QVD files or flat files. Metabase queries the database directly, so every source behind an app must exist as a table, view or query in your warehouse. Trace each LOAD and SELECT statement to its origin and note transformations such as joins, concatenations and calculated fields. Where the logic lives only in the script, rewrite it as a view or a saved SQL question before you build the dashboard on top of it.
User and group lists to recreate
Export the user accounts and groups from Qlik and map each group to a Metabase group that carries the same viewing rights. Metabase's open source and Starter plans include Google sign-in and LDAP, while SSO through JWT, OIDC or SAML, advanced LDAP group sync and SCIM provisioning require the Pro or Enterprise plan. Confirm which identity provider your organization uses and whether group membership must sync automatically or can be maintained by hand. Plan the access model before you invite users, because each collection and dashboard permission must be set again in Metabase.
Data connections to re-point
Qlik data connections, such as ODBC or OLE DB sources defined in the Qlik management console, do not carry over. Create a matching database connection in Metabase for each source, using a read-only service account, and test each one before any dashboard depends on it. Do not assume a connector exists for your source. Check the database list on Metabase's documentation for your database type and version, and confirm any driver you need with Metabase before the project plan commits to a date.
The Metabase application database
Metabase stores its own objects, including questions, dashboards, collections, permissions, users and connection settings, in an application database. It does not store Qlik apps or data. Metabase ships with an embedded H2 database for demonstrations, so if your trial used H2, migrate it to PostgreSQL or MySQL with the load-from-h2 command using the same Metabase version that last wrote the file. Back up the application database before every upgrade, and upgrade release by release from any version older than 40.
Where Qlik load scripts and set analysis need rework in SQL
Qlik load scripts and set analysis do not move across as they are. Qlik's associative engine and in-memory data model resolve relationships and selections inside the app, while Metabase sends each question to the database as SQL. So every transform in a load script has to land somewhere explicit: a SQL view on the warehouse, a dbt model if you already run dbt, or a physical table built by a scheduled job. Joins, field renames, derived columns and the logic in Resident or Concatenate style loads all need a new home before any dashboard is rebuilt. Set analysis expressions, such as those with explicit set modifiers or Aggr calls, become SQL aggregations with the right grouping, or Metabase metrics and saved questions that business users can reuse. Pick the layer deliberately, because it decides who maintains the logic later.
Start with an inventory of expressions sorted by complexity, not by app. Simple sums and counts that filter on one field are usually quick to restate. Expressions that depend on the current selection state, on alternate states, on cross-table aggregation at a different granularity, or on inter-record comparisons need careful design and a written definition of the intended result. Export the QVF files for each app first, as described in the export guidance, so the expression text and load script are preserved for reference. Then, for each high-use chart, record the Qlik output for a set of filter combinations and compare the same numbers from the new SQL or Metabase question. Differences in null handling, rounding, date boundaries and distinct counts are the usual cause of mismatches. Confirm the sign-off owner for each metric before cutover, and keep the Qlik values as the baseline until both sides agree.
How to sequence the Metabase cutover from Qlik
This sequence moves Qlik Sense users to Metabase in controlled stages, so each dashboard is inventoried, proven against Qlik numbers, and retired only after its audience has switched. It ends with Qlik decommissioned once the installed release reaches its support limit.
Inventory apps, users and expressions
Qlik administrators export a list of every app, its owner, its last-used date and its data connections from the QMC, and record which apps are published and which are personal sheets. Analysts then tag each sheet by audience and list the set analysis and load script logic it depends on, since those expressions decide what must be rewritten in SQL. The output is a single inventory sheet with one row per dashboard, its users, its data source and its rework effort, approved by the business owners who will sign off on the pilot.
Set up the Metabase application database
Deploy the open-source Metabase image in your infrastructure and point its application database at PostgreSQL, which Metabase recommends for production, instead of the embedded H2 file used for demos. Confirm the chosen version against the Metabase version support page so you know whether it is LTS or non-LTS and when it reaches end of life, then take a backup of the application database before the first start. The output is a running instance with a documented version, a tested backup and a named owner for upgrades.
Pilot a few high-use dashboards
Choose a small set of high-use Qlik dashboards that consumers open most often and rebuild them in Metabase as questions connected to the warehouse, grouped into a dashboard per audience. Use SQL for logic that lived in load scripts or set analysis, and keep the definitions in version-controlled files where your team can review them. The pilot is complete when a small group of business users has used these dashboards for their routine work and has confirmed that filters, drill paths and exports behave as they expect.
Run Qlik and Metabase in parallel
For a fixed period agreed with the business owners, run the same reporting questions in Qlik and Metabase and compare the outputs for each measure, filter combination and period. Investigate every mismatch to its cause, which is usually a join, a null handling rule or a date boundary that was implicit in the Qlik data model. The output is a signed reconciliation log that lists each dashboard, the checks performed, and the differences found and resolved.
Configure SSO and row-level access before go-live
Confirm which Metabase plan covers the sign-in and permission model you need, because SSO and row and column level permissions are listed only on the Pro and Enterprise plans, not on Open Source or Starter. Map Qlik section access and group rules to Metabase groups and data permissions, and test that each role sees only its permitted rows. The output is a written access matrix checked by security and the data owners, with test accounts for each role.
Cut over by audience
Move one audience at a time, starting with the group whose dashboards passed reconciliation, and set the Qlik app for that audience to read-only or remove its access once users have confirmed the Metabase version. Publish a short guide for users that covers where each dashboard now lives and how to request changes, and keep a rollback path to Qlik until the audience has completed a full reporting cycle. The output is a cutover record per audience showing the date, the users moved and the rollback status.
Decommission Qlik after the last release is supported
Once all audiences are on Metabase, archive the final QVF exports and the reconciliation logs, and confirm which Qlik Sense Enterprise on Windows release is installed and when it reaches its support limit. Remove the Qlik server, its data connections and its license activation only after the archive is verified and retention obligations are met. The output is a decommissioning record that lists the archived artifacts, the removed components and the Metabase upgrade plan that follows.
How the migration differs by estate size and starting point
If your estate runs Qlik Sense Enterprise on Windows, you control the server, the Qlik Management Console and the data connections the apps use. The migration starts with an inventory of apps, connections and extensions taken from that environment, so you know what must be rebuilt before any cutover date is set. Qlik describes this product as its client-managed option, which keeps the source files and access paths on infrastructure you run. See Introducing Qlik Sense Enterprise for the deployment model.
- Export access: Confirm that the administrator account can export app files and list data connections before setting any timeline.
- Connection inventory: Map each ODBC or OLE DB connection to a database Metabase can query directly, and record which credentials must be entered again.
- Extensions and custom visuals: Plan to rebuild these as Metabase questions or dashboards, because they do not move with the app file.
- Application database: Plan a PostgreSQL application database for production, since Metabase's embedded H2 database is meant for demos.
- Hosting ownership: Your own servers also mean your team patches Metabase and its database, which adds recurring operating work.
Check which Qlik release your servers run and which apps still depend on the Windows host before you plan the cutover.
If your estate runs on Qlik Cloud, Qlik hosts and manages the platform, so your starting point is the tenant, its spaces and the export options Qlik provides within it. The analytical logic is the same as on a client-managed server, but the file and permission paths differ, and you depend on the tenant settings your role can use. Ask Qlik and your administrator which content your account can export before you assume a complete copy exists.
- Tenant export rights: Confirm which spaces and apps your role can export, and whether the export includes data or only the app structure.
- Contract timing: Your capacity commitment sets when you can exit. Check the end-of-term terms in your contract rather than assuming a date.
- Data location: Metabase connects to the warehouse or databases behind the apps, not to Qlik Cloud, so confirm the network route from Metabase to those sources.
- Identity mapping: Cloud users and groups must be mapped to Metabase groups by hand or through a sync feature, and that sync depends on the plan you choose.
- Operating responsibility: Once you self-host Metabase, your team takes on upgrades and backups that Qlik previously handled.
Ask Qlik which export formats your tenant offers before you commit to a migration timeline.
Estate size changes the work more than the tool does. A small set of apps that read directly from a database can often be rebuilt as Metabase questions and dashboards by a single analyst. A large estate with many shared load scripts needs that transformation logic moved into SQL views or a warehouse layer first, or every dashboard repeats the same work and drifts apart over time.
- Small estate: Rebuild each app as saved questions and then a dashboard. The free Open Source edition includes unlimited users and dashboards, so cost is driven by hosting and effort rather than licenses.
- Shared scripts: Logic reused across apps should become SQL views or dbt models in the warehouse before Metabase questions depend on it.
- Set analysis: Catalog the expressions early, because many apps often repeat the same measure and each duplicate can collapse into one SQL definition.
- Paid user tiers: Starter includes 5 users and Pro includes 10 users on the published monthly prices, with additional users at $6 (Starter) or $12 (Pro) per month, as stated on the Metabase pricing page.
- Team size: Count active viewers and editors, since that count determines whether the free edition or a paid plan fits.
Before choosing a plan, count your apps, shared scripts and active users so the scope and tier are based on your numbers.
Identity and data-level access needs decide which Metabase plan you need. Open Source and Starter support Google sign-in and LDAP. Single sign-on through JWT, OIDC or SAML, and row and column level permissions, are included only in the Pro and Enterprise plans. If your Qlik estate restricts data by user, those rules must be rebuilt in Metabase permissions or in the database itself before users can see the same content.
- Google sign-in or LDAP only: The free and Starter plans cover this, which suits small internal teams with no row-level rules.
- OIDC or SAML: These require Pro or Enterprise. Documented setups exist for Auth0, Entra ID, Google, Keycloak and Okta.
- Row-level permissions: These require Pro or Enterprise. Test them with sample users from each region or business unit before cutover.
- Group and provisioning sync: Advanced LDAP group and attribute sync and SCIM provisioning also require Pro or Enterprise.
- Air-gapped operation: Only the Enterprise plan offers air-gapped deployment, and it is priced by quote, starting at $20,000 per year according to the Metabase pricing page.
Confirm your identity provider and the data-level rules your estate enforces before you select a plan.
What drives the cost and duration of the Metabase migration
This table lists the factors that set the effort of moving a Qlik Sense estate to Metabase, why each one matters and how to shrink it. Read it before requesting a quote, because the one-time migration work and the recurring Metabase plan, hosting and upgrade costs follow different drivers.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Number of apps and expressions | Each Qlik app carries sheets, charts and set analysis expressions that must be rebuilt as Metabase questions or dashboards. Expression count, not app count alone, sets the rebuild effort. | Inventory apps by usage from the Qlik logs. Retire unused apps and rebuild only the dashboards that active Analyzer users consume. |
| Load script complexity | Transformations in Qlik load scripts, such as joins, resident loads and mapping tables, must move into SQL views, a warehouse or a transformation tool. Heavily scripted apps take the most time. | Move logic into the warehouse or dbt models once, then point several Metabase questions at the same clean tables. |
| Warehouse readiness | Metabase queries your databases directly, so apps that relied on Qlik's in-memory model may have no governed source yet. Missing tables, unclear keys or duplicated business rules add work before any dashboard is built. | Confirm the target tables, grain and join keys with data owners before rebuild starts. Document metric definitions once and reuse them. |
| Number of row-level rules | Row-level permissions depend on the Metabase plan. Each rule needs mapping to a group, attribute or sandbox, and each must be tested for every affected user group. | Consolidate rules into a small set of group or attribute patterns. Test with representative accounts from each business unit. |
| Identity integration | SSO through SAML, OIDC, JWT or SCIM sits in paid tiers, and group mapping from your directory into Metabase groups adds configuration and testing. Qlik section access rules may need translation into Metabase groups. | Map directory groups to Metabase groups before migration. Confirm which identity method your plan supports before design starts. |
| Embedded and shared content | Dashboards embedded in portals or shared through links need the embedding setup, signing and access checks retested. Breakage here often reaches end users first. | List every embed and external share early. Treat them as a separate test scope with named owners. |
| Data volume and query performance | Large fact tables queried live from Metabase can slow dashboards that Qlik served from memory. Cache, aggregation and warehouse sizing decide whether users see acceptable response times. | Pre-aggregate heavy views, set caching for common dashboards and size the warehouse for concurrent users, not only storage. |
| Team SQL skills | Question building is mostly point and click, but complex logic, custom expressions and governed views need SQL. A team without this skill set will need outside help or training. | Assess SQL skills early. Pair analysts with the engineers who own the warehouse and record reusable query patterns. |
| One-time migration work (recurring costs excluded) | Discovery, rebuild, testing, user training and cutover are paid once. Scope set in writing with a fixed list of apps and rules keeps this bounded. | Ask for the fixed scope, the list of apps and rules covered, and acceptance criteria in the quote. |
| Recurring costs (plan fees, hosting, upgrades) | Metabase plan fees, database and application hosting, backups and upgrades continue after cutover. Plan tier choice, number of users and the upgrade cadence drive this total. Check current prices on the Metabase pricing page. | Choose the plan that matches your SSO and permission needs, budget upgrade windows for LTS releases and ask for an itemized recurring estimate in the quote. |
What usually goes wrong in a Qlik to Metabase move
Most failed BI migrations fail on assumptions made early: what the export contains, whether the numbers still match, and whether the chosen plan and database setup can carry production use. The cards below cover the risks we see most often in Qlik estates moving to Metabase, each with a check to run before cutover.
Assuming the QVF carries the data
A QVF export is the app definition and, depending on the export option, may or may not embed the loaded data. Teams often assume the file is a full copy of the analytics and discover later that the source connections, load script logic and any ODBC data connections must be rebuilt. Confirm which export mode you used, list every data connection the app depended on, and verify that each source table is reachable from Metabase before retiring the Qlik app.
Mismatched numbers between Qlik and SQL
Qlik set analysis and associative calculations can produce totals that differ from a straightforward SQL aggregate, especially around distinct counts, null handling, date buckets and time zones. Users notice the difference immediately and lose trust in the new dashboards. Pick a set of reference figures from the Qlik app, rebuild them as Metabase questions, and reconcile each one to the cent or unit with stakeholders before any user is moved.
Choosing a plan without SSO or row-level permissions
Open Source is free and supports unlimited users and dashboards, but SSO and row and column level permissions are reserved for paid plans. A Qlik estate that restricts data by section access may find the free edition cannot enforce the same rules. Map each current Qlik section access rule and identity provider integration to a Metabase feature, then confirm which plan includes it before you commit budget or design the rollout.
Running the H2 database in production
Metabase ships with an embedded H2 application database that suits demos and tests. Running production dashboards, users and saved questions on H2 makes backups, scaling and recovery harder, and moving later requires a dedicated load step. Provision PostgreSQL or MySQL as the application database from the start, and test the backup and restore process on that database before go-live.
Upgrading across many versions without a backup
Metabase runs application database migrations automatically at upgrade time, so an upgrade that goes wrong can leave the application database in a state that is hard to reverse. Estates that have not been upgraded for a long time may need to move release by release. Back up the application database first, plan a single node for major upgrades, and record the version path you will follow before starting.
Questions teams ask before moving from Qlik Sense to Metabase
What does a move from Qlik Sense to Metabase cost?
The software itself can cost nothing: the Metabase Open Source edition is free to self-host with unlimited users and dashboards. The real cost sits in the components around it: the servers or cloud accounts that run Metabase and its PostgreSQL application database, the warehouse capacity that now answers every query directly, the rework of Qlik load scripts and set analysis into SQL, and the people who maintain it. If you need SSO or row-level permissions, the Pro plan is priced per month on Metabase's pricing page, and Enterprise is priced by quote starting at $20,000 per year. Ask any implementation partner for a fixed-scope quote that lists each of these components separately.
How long does a migration from Qlik Sense to Metabase take?
No supplied figure gives a reliable duration, and it depends on the number of apps, the complexity of their load scripts and set analysis, the data sources involved, and how many dashboards must be rebuilt rather than retired. A practical way to size it is to inventory your apps, group them by data source, and mark which ones are consumed mostly as dashboards by Analyzer users. Those are usually the fastest to rebuild as Metabase questions and dashboards. Ask for a timeline in the written scope, with phases for export, rebuild, permissions and cutover.
What does the migration need from our internal team?
Expect to need a few roles throughout the project: someone who owns the Qlik apps and knows which dashboards business users rely on, a data engineer or DBA who can confirm the source tables and warehouse access, an identity administrator for SSO and group mapping, and an operator who will run Metabase, its database and its upgrades after go-live. Analysts who understand the set analysis logic are needed to validate that the SQL produces the same numbers. Qlik's client-managed export through the QMC can provide QVF files, but Metabase does not import them, so the business logic must be recreated.
Can our own team do the migration without an outside partner?
Yes, if your team already runs SQL-based reporting, has someone who can operate a Java-based application with a PostgreSQL database, and can take ownership of the rebuilt content. Metabase's open-source edition is self-hosted and documented, so a capable team can start with a pilot of a few high-use dashboards. Teams often bring in outside help for the parts that are slow to get right: script conversion at scale, the identity integration, permission design for row-level access, and a tested backup and upgrade routine. DeployOpen plans, implements and supports self-hosted platforms in your own infrastructure under fixed-scope agreements, and the scope is agreed in writing before work starts.
Which Metabase plan covers SSO and row-level permissions?
SSO and row and column level permissions are included only in the Pro and Enterprise plans, according to Metabase's pricing page. The Open Source and Starter plans do not include them. Google sign-in and LDAP are available on Open Source and Starter, while JWT, OIDC, SAML and SCIM provisioning require Pro or Enterprise. Confirm the current plan contents and fees on the pricing page before you budget, because plan details can change between releases.
What are the limits of the free Metabase Open Source edition?
The open-source edition is free to self-host with unlimited users and dashboards, which makes it a strong fit for internal reporting. The limits are functional and operational rather than seat-based. It does not include SSO beyond Google sign-in and LDAP, row and column level permissions, multi-tenant data segregation, or usage analytics and auditing. Support is not part of the free edition, so you will need internal expertise or a support arrangement. Air-gapped deployment is offered only on the Enterprise plan, so isolated networks should confirm this before choosing the path.
How are Metabase upgrades and the H2 migration handled?
Metabase runs application database migrations automatically during upgrades, so back up the application database first. For major upgrades, the documentation recommends reducing a cluster to a single node because of a migration lock, and upgrading release by release if you are coming from a version older than 40. Metabase LTS versions are supported for 14 months, while non-LTS versions usually reach end of life after 2 months. If a trial instance used the embedded H2 database, move it to PostgreSQL or MySQL with the one-time load-from-h2 command, run with the same Metabase version that last updated the H2 file. Plan that step before any production data is loaded, and test it on a copy.
How DeployOpen scopes and runs a Qlik to Metabase migration
A Qlik to Metabase migration starts with a written, fixed scope. DeployOpen agrees the scope, deliverables and timeline in writing before work begins, and the scope should name the Qlik apps in play, the user groups that consume them, the data sources they read and the Metabase edition and deployment target. The first deliverable is an inventory of every Qlik Sense app, sheet and published stream, recording which dashboards are opened by Analyzer users, which apps are still edited, which load scripts feed them and which data connections they depend on. That inventory sorts the estate into three groups: dashboards to rebuild as Metabase dashboards built on saved questions, logic to move into SQL or the warehouse, and content to retire. A pilot then rebuilds a small set of representative dashboards so the team can test filters, drill paths and row-level behavior before committing to the full list. Ask the vendor for the inventory format and the pilot acceptance criteria in writing before signing.
The target environment runs in your own cloud account, data center or private network, and DeployOpen deploys Metabase with the application database on PostgreSQL rather than the embedded H2 database, which Metabase's documentation positions for demos. Hardening covers the items your security team will check: TLS termination, network placement relative to the warehouse, service accounts with read-only database access, and the sign-in path. Confirm with your identity team which Metabase plan includes the SSO method you use, because SSO and row-level permissions appear only in the Pro and Enterprise plans on the pricing page, and SAML or SCIM setups are gated the same way. Backups must cover the application database, which holds questions, dashboards, permissions and sync settings, on a schedule and with a restore test that is recorded as evidence. Upgrades are a recurring task, so the plan should follow Metabase's version support page and run application database migrations after a backup, as the upgrade documentation advises.
Documentation and handover close the engagement. Deliverables typically include the inventory, the mapping of each Qlik object to its Metabase equivalent, the SQL and data model changes, the runbook for backups, upgrades and access reviews, and training for the analysts who will own collections after go-live. Optional retainers can cover upgrades, monitoring, security testing and support after handover, and they are priced separately from the fixed-scope build. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, so ask your auditors which evidence they expect from the access, backup and change records. Before you request a quote, ask for a written list of assumptions about data volume, source systems and who signs off each phase.
