How to export your data from Qlik Sense before the contract ends
If a renewal, a lifecycle deadline or an exit decision means your Qlik Sense apps must leave the platform, start with the Qlik Management Console (QMC), which exports apps as QVF files. Be aware that unpublished and published apps export different content: an unpublished app exports all of its content, while a published app exports only its published and approved content, along with related images in the AppContent folder. Extensions do not travel in the export, and ODBC data connections must be recreated at the destination. This page covers Qlik Sense Enterprise on Windows apps only. Qlik Cloud exports follow a different path and are not covered here.
Before you export, inventory what the QVF files will and will not carry. The QVF holds the data model, load script, sheets, stories and bookmarks, but the data itself is included only when you choose the export option that includes data. Confirm with your Qlik administrator which apps are published, which depend on custom extensions, and which rely on ODBC or other data connections that will need credentials and drivers rebuilt on the new platform. Also list any apps whose approved content is a subset of the working app, because the published copy is the one users see and the one you must reproduce.
Use the QMC for the export itself. A single app exports to your local download folder. For bulk work, the QMC can export up to 50 apps at a time to a temporary folder on the Qlik server under the Repository Exports path in ProgramData. Keep the QMC session open until the download finishes, because closing or logging out before then loses the export. Store the exported files in a controlled location, record a checksum for each file, and verify that every app opens in a test environment before your access to Qlik ends. Confirm the exact export options and retention behavior against Qlik's help for your release.
What Qlik Sense exports and in which format
This table shows what each Qlik Sense Enterprise on Windows export path includes, from single apps to bulk exports. Read each row against the app state (unpublished or published) and the export route you plan to use, since published apps carry less content than unpublished ones.
| Export item | What it includes | Where the file lands | Notes for migration |
|---|---|---|---|
| Unpublished app | All content of the app, exported as a QVF file | Local download folder for a single app export | Extensions are not included and ODBC data connections must be recreated at the destination |
| Published app | Only published and approved content, exported as a QVF file | Local download folder for a single app export | Content that was never approved is missing, so confirm the sheets and stories you need are published |
| Related images | Images stored with the app, kept in the AppContent folder | Alongside the app content in the export | Check that custom images used in sheets or the hub are present after the export |
| Single app export | One QVF file per app, started from the QMC | Local download folder on the machine running the browser | Keep the QMC open until the download completes, because closing or logging out loses the export |
| Bulk export (up to 50 apps) | Multiple QVF files, limited to 50 apps per run according to Qlik help | Temporary server folder under %ProgramData%\Qlik\Sense\Repository\Exports | Copy files off the server before the temporary folder is cleared, and plan batches of 50 or fewer |
| Extensions and data connections | Not included in app exports | Not applicable | Inventory extensions and ODBC connections separately and recreate them at the destination |
What does not leave Qlik Sense and how to recover it
A QVF export carries the app's data model and sheets, but several parts of a Qlik estate stay behind. The cards below cover the items most often missed in a migration and a practical way to recover each one before the source environment is retired.
Extensions are not exported
Qlik Sense app exports do not include extensions, so any custom visualization, mashup component or property panel your apps depend on will be missing at the destination. Start by inventorying every extension installed on the source site and noting which apps reference it. Keep the original extension packages in version control, because without them the affected sheets will show errors. Decide early whether each extension is replaced by a native chart in your target tool or rebuilt there.
ODBC data connections need recreating
Data connections are not carried in the app, so each ODBC connection must be created again at the destination. Record the DSN name, driver, host, database, port and the service account used, but keep passwords and tokens out of the migration file. Store the secrets in your organization's vault and have the destination owner enter them. Test every connection against the same source tables before you compare any numbers.
Load script logic must be rebuilt
The load script, with its transformations, joins, resident loads and variables, is the part of the app that defines how data reaches the model, and it does not translate automatically into SQL. Export the script text from each app and sort it by business purpose. Move the logic that cleans or joins data into the warehouse or a dbt model where it can be tested. Compare row counts and key totals between the old and new outputs before retiring any app.
Visualizations and set analysis are rebuilt
Sheets, charts, master items and set analysis expressions live in the app definition and must be recreated as dashboards, charts and SQL-based metrics in the target tool. Catalogue each sheet with its users and the measures it depends on, since many dashboards rely on associative selections that have no direct equivalent. Prioritize the sheets people open every week. Confirm the rebuilt numbers against the Qlik originals for a fixed set of filters.
Source data must be captured outside Qlik
Because a QVF file holds the model and the data only for certain apps, you cannot rely on it as the only copy of historical figures. Identify which apps include data and which published apps exclude it, then extract the source tables directly from the underlying systems. Write them to a location you control with a documented snapshot date. This gives you a reference set for validation even when an export is incomplete.
Published apps export partial content
A published app exports only its published and approved sheets and stories, so unpublished drafts and private sheets are left out unless you export the unpublished source app. Check each app's status in the QMC before the export and list the excluded content. Treat that list as part of the migration scope so that no working dashboard disappears without a decision. Images in the AppContent folder must be copied separately.
Export sequence for a complete Qlik Sense app inventory
This sequence produces a verified set of QVF files and matching AppContent images for every Qlik Sense Enterprise on Windows app in scope, so you can prove what was captured before any migration work starts. It runs from the QMC inventory through a single-app test, batched bulk exports and a comparison check on each file.
Inventory every app and its published status
Open the Qlik Management Console (QMC) and list every app in scope, recording the app name, owning stream, last reload date and whether each app is published. Note which published apps have unpublished changes, because only published and approved content of a published app is included in an export. Save the list as a spreadsheet owned by the migration lead. The step is done when the list has one row per app and a column that marks published status, and a second person has reviewed it.
Record the sheets, sources and extensions per app
For each app on the inventory, open it in the hub or the development environment and note the sheets, the data connections and load script sources, and any extensions or custom visualizations in use. Extensions are not included in app exports, and ODBC data connections must be recreated at the destination, so these items need their own rebuild list. The step is done when every app has a sheet count, a source list and an extension list recorded next to it.
Run a single-app export as a test
Choose one representative app, export it from the QMC to the local download folder and confirm the download completes. Keep the QMC session open until the browser shows the file. This test shows you the file name pattern, the file size and whether the export includes data for the app you chose, before you scale up. Confirm with the Qlik documentation for your release which export options are available, including whether data is included. The step is done when one QVF file opens in a test environment and its sheets match the original.
Export apps in batches of up to 50
Select apps for a bulk export in groups of no more than 50, following the QMC limit for bulk exports. The QMC writes the batch to a temporary server folder under the Qlik repository exports path, so confirm that the server has enough free disk space for the batch. Do not start the next batch until the current one is downloaded. The step is done when the export log or the folder listing shows every app in the batch as present.
Keep the QMC session open until download finishes
Stay signed in to the QMC and keep the browser tab open until the bulk download is complete. Qlik warns that closing the console or logging out before the download finishes loses the export, so the batch must be run again from the start. Mark each batch as complete only after the final file has arrived in the download location. The step is done when the transfer finishes with no error and the file count matches the number of apps selected.
Compare the exported file list to the inventory
Match the names of the QVF files against the inventory spreadsheet from the first step. Any app on the inventory without a matching file, or any file without an inventory entry, must be investigated before you continue. Check the file sizes and modified dates against the expected values in your records. The step is done when every in-scope app has exactly one QVF file and every exception has a documented reason and an owner.
Verify each QVF and the AppContent images
Open each QVF in a test environment and confirm that the sheets, visualizations and load script sources match the notes from the second step. For published apps, confirm that only published content was captured. Check that images referenced by the app appear in the AppContent folder that accompanies the export. Record the result for each app as pass, fail or needs rebuild, with the extensions and ODBC connections listed for rebuild. The step is done when every app has a recorded result and the rebuild list is complete.
Archive the verified set with its evidence
Store the verified QVF files, the AppContent folders, the inventory spreadsheet and the verification results in a controlled location with access limited to the migration team. Keep the QMC export logs with them so you can show when and how each batch was produced. This archive is the baseline for any later comparison with the destination. The step is done when the archive contains a manifest that lists every file with its checksum and matching inventory row.
Why a QVF export is not a full copy of the analytics
A QVF file is an app definition, not a complete copy of the analytics estate. It carries the app as Qlik stores it, including the load script, the data model and, for unpublished apps, all content. Published apps export only published and approved content, plus related images in the AppContent folder. Qlik's export does not include extensions, and ODBC data connections must be recreated at the destination. Anything that lives on the Qlik Sense server, such as data connection definitions, stream and app-level security rules, and the user and group assignments that decide who sees what, stays behind unless you capture it separately. Before you export, inventory these objects from the Qlik Management Console so you know what the QVF will not restore.
The practical consequence is that you need three sets of records kept outside the QVF. First, the load scripts and the source queries they run, saved as text in version control, because the script is what turns raw tables into the model your users see. Second, the list of data connections with their driver, host and credential owner, so each one can be rebuilt in the new stack. Third, the permission lists per app and per stream, mapped to the identity source your self-hosted tool will use. Confirm with your Qlik administrator whether these lists already exist in a current form, since a QVF export will not produce them for you.
The data itself has to be rebuilt, not carried over. The QVF may contain an in-memory copy of the data, but a self-hosted stack such as Apache Superset or Metabase queries your source systems or warehouse directly, so each dataset needs a live connection, a tested query and an agreed refresh behavior. Plan a reconciliation step where row counts and key figures from each rebuilt dataset are compared with values shown in the original Qlik app for the same filters and period. Where a source system is not reachable from the new environment, record that gap early, because it will set the order of the migration more than any export setting.
What to plan before the Qlik renewal or termination
The export itself is short compared with the decisions around it. Confirm what you run, when access ends, and who owns the export window, then plan the rebuild work that no export file carries across. Each card below is one decision or risk that should be settled while the license is still active.
Confirm the installed release and its support end
Check which client-managed Qlik Sense Enterprise on Windows release is installed, including its month-named version, and find its end-of-support date in Qlik's lifecycle documentation. An install close to end of support changes the plan, because a forced upgrade may land in the middle of your export work. Record the result in your inventory so every later decision refers to the same version.
Schedule the export while the license is active
Export while the license still works. Plan the QVF exports and the inventory for a window that closes well before the renewal or termination date, not on the last day. Treat the export as a project with a start, a checkpoint and a freeze on new app changes, so the files you download are the files you intend to migrate.
Agree the export window with Qlik
Confirm in writing with your Qlik account team or partner what access you keep during the exit period, which environment remains available for downloads, and how long read access continues after the license ends. Ask whether any support is included for the export itself. Do not assume that the contract end date is the same as the end of QMC access.
Reserve time for extensions and ODBC connections
App exports do not carry extensions, and ODBC data connections must be recreated at the destination. Build an inventory of every extension, custom visualization and data connection, with owners and credentials held in your vault. Then allocate engineering time for these rebuilds separately from the QVF export, since they are often the longest items on the plan.
Decide where QVF files and inventories live
Choose a storage location for exported QVF files, the app inventory and the list of published and unpublished content before the first download. Exports can contain sensitive business data, so set access rights, retention and encryption on that location first. Keep a checksum and a record of which app was exported from which stream and by whom.
Plan for QMC session interruptions
The QMC warns that closing or logging out before a download finishes loses the export. Schedule bulk exports from a stable admin workstation, avoid shared sessions, and confirm each file is complete before you start the next batch. Assign one named operator to watch the temporary export folder so no export is lost during the window.
Questions teams ask before exporting Qlik Sense apps
Can our admin team export Qlik Sense apps from the QMC without a partner?
Yes, for most estates the export itself is a task the admin team can run from the Qlik Management Console. The QMC exports a single app to the local download folder, and bulk exports of up to 50 apps go to a temporary server folder under %ProgramData%\Qlik\Sense\Repository\Exports. The harder work starts after the files leave Qlik: rebuilding extensions, recreating ODBC data connections, moving load script logic into SQL or dbt, and rebuilding selections in Superset or Metabase. Ask whether your team has the Qlik and target-platform skills for that rebuild, and whether a partner is needed for the parts you cannot staff.
How long does a Qlik Sense app export take?
The documented limits describe the mechanics, not a duration, so the timing depends on your environment. Qlik documents that bulk export handles up to 50 apps per run, and that closing or logging out of the QMC before the download finishes loses the export. The main drivers are the number of apps, whether you export with data, the size of the app files, and how many apps need rework after export. Run one test export of a representative app first, then time it on your own server.
Do Qlik Sense apps export with their data included?
You choose whether to export with or without data in the QMC, and that choice affects file size and what you must rebuild later. Export without data when the destination will reload from its own warehouse or database, which is the usual pattern for Superset or Metabase. Confirm with your data team which sources feed each app and whether the data in the QVF is needed for audit or history before deciding.
Are unpublished Qlik Sense apps safe to export?
Export behavior differs by app status, so check it before you plan the cutover. Qlik Sense exports all content of an unpublished app. For a published app, it exports only the published and approved content, together with related images in the AppContent folder. That means draft sheets, unapproved content and private work in a published app may be left out. Review each published app's sheets and approval status, and keep an inventory of any unpublished work your business users rely on.
What happens to Qlik extensions and ODBC connections during export?
Extensions and ODBC data connections do not move with the app, so both must be handled separately. Qlik documents that app exports do not include extensions, and that ODBC data connections must be recreated at the destination. Build an inventory of every extension used by each app and every ODBC source, with its owner and credentials process. Then decide whether each extension has an equivalent in the target tool, and whether each source will be reached through a native connector or a warehouse layer.
What should a migration partner scope before exporting Qlik apps?
A written scope should list the apps in and out, the export method, the target platform and the rebuild work per app. Ask the partner to name the deliverables, such as an app inventory, an export log, a dependency map of extensions and data connections, and a cutover plan tied to your Qlik release timeline. DeployOpen plans and implements self-hosted open-source platforms in your own infrastructure and works from a fixed scope agreed in writing before work starts, so the quote follows from that scope. Confirm which items are included and which remain your team's responsibility.
What drives the cost of exporting and rebuilding Qlik apps?
Cost follows the amount of work, and the main drivers are the number of apps, the count of extensions and data sources, the complexity of load scripts and set analysis, and how many users depend on each dashboard. Export itself is a small share of the effort. One-time costs include inventory, rebuild, testing and cutover, while recurring costs include hosting, warehouse load and support after go-live. Ask any provider for a quote that separates these items, and state the number of apps, extensions and sources in the request so the figures can be compared.
Who does the export and who must confirm the result
The Qlik administrator runs the export itself. In Qlik Sense Enterprise on Windows, that person uses the Qlik Management Console (QMC) to export a single app to the local download folder or to run a bulk export of up to 50 apps, which lands in a temporary server folder under %ProgramData%\Qlik\Sense\Repository\Exports. The administrator also owns the step most likely to fail silently: Qlik warns that closing or logging out of the QMC before the download finishes loses the export. Agree on one named person for each export run, and have that person confirm the file count and names against the app list before the session closes.
App owners decide whether an export is complete, and the administrator cannot make that call for them. For an unpublished app, the export carries all content. For a published app, only published and approved content comes across, with the related images in the AppContent folder. Each app owner should check their own sheets, bookmarks and stories against what they expect at the destination, and should record any content that is still in draft and therefore absent from the QVF. The data team holds what the QVF files do not contain: ODBC data connection details, credentials, load script sources and the extensions that must be recreated. Ask the data team for a written inventory of these connections and their owners before the export starts, because exports do not include extensions and data connections must be rebuilt at the destination.
The security team controls where the QVF files and their accompanying images sit after export, who can copy them and how long they remain on disk. A QVF can embed business logic and sometimes data, so treat the export folder as sensitive storage: restrict access, log transfers and delete staging copies once the import is verified. DeployOpen can run the export and verification work under a written scope, including the inventory, file checks and import testing. The client still owns the data, the approval of each app's content and the final decision to cut over, and the scope should name who signs off on each of those.
Where exported content can go next
A QVF export carries the app's data model and visible content, but not extensions or ODBC connections, so every path starts by deciding what gets rebuilt and what stays on Qlik. The cards below cover two self-hosted rebuild routes and two ways to keep Qlik running while the decision is made.
Rebuild in self-hosted Apache Superset
Superset queries your warehouse directly, so the load script logic in an exported app must be rebuilt as SQL datasets, virtual datasets or upstream transformations. Check which extensions and custom visualizations the app depends on, because those have no export path and need a Superset equivalent. Also confirm that the warehouse connections the ODBC data connections used can be recreated with a Python DB-API driver and SQLAlchemy dialect.
Rebuild in self-hosted Metabase
Metabase suits estates where most users consume dashboards and ask simple questions of connected databases. Exported published apps show which sheets and stories business users rely on, so start there. Confirm that the plan you need covers SSO and row and column level permissions, because those features sit in the paid Pro and Enterprise plans, not in the free Open Source edition.
Keep Qlik on a supported release
Exports are most reliable from an installed release that is still in support, so the QVF files and app content stay consistent with what the business uses today. Keep the QMC export steps on a schedule that finishes before any forced upgrade. Confirm with Qlik which release line your install is on and how long it remains supported before you set a migration deadline.
Move to Qlik Cloud
Qlik Cloud is the SaaS option hosted and managed by Qlik, so it changes where apps run rather than the app model itself. Exported QVF files and extensions still need review before they are imported, and ODBC connections must be recreated against the cloud environment. Ask Qlik how existing data connections, extensions and capacity licensing map to your current Qlik Sense Enterprise on Windows contract.
How DeployOpen scopes and delivers a Qlik export
DeployOpen treats a Qlik export as a fixed-scope piece of work agreed in writing before anything is touched. We inventory which apps, data connections and extensions must move, then deliver exported QVF files, a rebuild list and handover documentation that your team can act on.
How we scope
- Inventory of every app in scope, marked as unpublished or published, with and without data
- List of ODBD and ODBC data connections that must be recreated at the destination
- Register of extensions and custom objects, since app exports do not carry them
- Written agreement on which apps are exported in bulk and which are exported one at a time
How we build
- Export runs from the Qlik Management Console with each export checked for completion before download
- Verification that exported files open and that published apps contain the approved content expected
- Packaging of AppContent images and export files into a controlled, access-restricted store
- Rebuild notes for extensions, connections and any content that the export leaves behind
How we hand over
- Written handover covering the export inventory, file checksums and the export date for each app
- Step-by-step runbook for recreating ODBC connections and reinstalling extensions at the destination
- Documented gaps list naming what was not exported and who owns each open item
- Walkthrough with your Qlik administrators and the teams who will rebuild the apps
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
- Ongoing support, upgrades and continuous testing are available as a retainer
- Quotes follow from the written scope, so ask for the scope items that drive effort on your estate
- Confirm with your Qlik release and support status, since the export steps may change between client-managed releases
