How conversion works
The conversion pipeline has the following phases:
- Extract — If
--generatePrjis enabled, QV2QS launches QlikView Desktop to extract the QVW file into a PRJ folder. QV2QS uses the bundled portable engine unless a system installation of QlikView Desktop is detected. For details, see QlikView Desktop engine. - Parse — QV2QS reads the PRJ folder and parses every object definition, sheet layout, load script, variable, and document property. QV2QS also reads the QVW/QVF binary directly to extract metadata, variables, and any hidden load script embedded in the file.
- Convert — Each QlikView object is mapped to a Qlik Sense visualization type. Dimensions, measures, expressions, styling, and layout positions are translated into Qlik Sense JSON format.
- Write — QV2QS writes the converted app structure to the output folder as a set of JSON files.
- Deploy (cloud modes only) — QV2QS creates the app on the tenant, uploads media, builds the app, and optionally reloads the app with data.
- Report — QV2QS generates a conversion report summarizing outcomes, automation scoring, and any items that require manual follow-up.
The Deploy phase runs in Build to Qlik Cloud and Export QVF modes. In Local only mode, QV2QS writes the converted output to disk without connecting to Qlik Cloud. The Report phase runs in all modes.
Conversion modes
QV2QS supports three conversion modes. Select the mode on the Setup step of the wizard or with the corresponding CLI flag.
| Mode | CLI flag | Qlik Cloud required | Output | Deploy phase |
|---|---|---|---|---|
| Build to Qlik Cloud | (default) | Yes | App deployed to tenant | Yes — creates app, uploads media, builds, publishes sheets |
| Export QVF | --exportQvf
|
Yes | QVF file on disk | Yes — builds app in Qlik Cloud, exports as QVF, then deletes the cloud app |
| Local only | --unbuildOnly
|
No | Build folder and conversion report on disk | No |
Build to Qlik Cloud is the recommended mode for migration. Export QVF is useful for producing a portable file to share or import into a different tenant. Local only mode is intended for assessment and review. For details on Local only limitations, see the section below.
The user interface defaults to fixed canvas mode, reload enabled, and auto-binary enabled. The CLI defaults to dynamic grid mode, reload disabled, and auto-binary disabled. When moving from the wizard to the CLI, specify these flags explicitly to match the wizard behavior. For the full list of arguments and defaults, see Argument reference.
Local only mode
Local only mode (--unbuildOnly) performs the Parse, Convert, Write, and Report phases without connecting to Qlik Cloud. No tenant or API key is required. QV2QS generates the full conversion report, executive summary, and build output folder on disk.
Use cases
- Migration assessment — Run Local only mode to generate the conversion report, executive summary, automation score, and expression findings without requiring Qlik Cloud access. Evaluate conversion quality across an entire QVW estate before setting up tenant credentials.
- Pre-deployment review — Inspect the generated output (load script, object definitions, variables, dimensions) before committing to a cloud deployment. Organizations with change control processes can review the output as an intermediate artifact.
- Offline or restricted environments — When the machine hosting the QVW files does not have outbound internet access, run Local only mode to generate the conversion report locally. To deploy the converted app, copy the QVW files to a machine with Qlik Cloud access and run QV2QS in Build to Qlik Cloud mode from the connected machine.
Limitations
The Deploy phase handles several operations that qlik app build alone does not perform. Running Local only mode and then deploying the build/ folder manually with a standalone qlik-cli installation results in the following gaps.
- Media files are not uploaded. Background images and button images are extracted to the
images/folder but are not included in thebuild/folder. Theqlik app buildcommand does not process media files. All background images and button images will be missing from the deployed app. - Sheet and object background references are not resolved. QV2QS injects background image URLs into the sheet and object JSON files during the Deploy phase using the cloud app ID. The local build output does not contain background image references. Sheets and objects will have no backgrounds in the deployed app.
- Button image URLs contain placeholder strings. Button images in the local build output use internal placeholder values instead of resolved media URLs. The Qlik Sense engine cannot interpret the placeholder strings. Button images will appear broken.
- Alternate states are not created. Alternate state names are written to
cloud/alternate_states.jsonoutside thebuild/folder. Theqlik app buildcommand does not process alternate states. Objects referencing non-default states may not display correctly. - Sheets are not published. The
qlik app buildcommand creates sheets as personal objects visible only to the app owner. QV2QS publishes sheets as base sheets during the Deploy phase. In a shared space, other users will not see any sheets until the sheets are published manually.
For a complete deployment including media upload, background resolution, alternate state creation, and sheet publishing, use Build to Qlik Cloud mode or Export QVF mode instead of Local only mode.
Source file safety
QV2QS does not modify the contents of the source QVW or QVF file. During the Extract phase, QV2QS opens the source document through QlikView Desktop and saves a temporary copy to a system temp folder. QV2QS then closes the original and generates the PRJ folder from the temporary copy. After PRJ generation completes, QV2QS copies the resulting -prj folder back into the same directory as the source file and deletes the temporary copy. If a -prj folder already exists beside the source file, QV2QS replaces the folder with the newly generated version. All other conversion output is written to the separate output directory specified by --outputDir.
QlikView Desktop acquires a file lock on the source document while the temporary copy is being created. Running QV2QS against a file that is actively open in QlikView Desktop or served by QlikView Server can cause file-locking conflicts or failed PRJ generation. Files on shared network drives can cause the same conflicts. Writing the -prj folder back to a network share or read-only directory can also fail.
To avoid any risk to production environments, always work with copies of source documents. Do the following:
- Copy the QVW or QVF files to a local working folder on the machine where QV2QS runs.
- Point QV2QS at the copied files, not the originals.
- Close any running QlikView Desktop instances before starting the conversion. QV2QS requires exclusive access to QlikView Desktop.
Do not run QV2QS directly against QlikView Server document folders, production network shares, or files that are open in QlikView Desktop. Always use a local copy of the source documents.
Typical timing
QV2QS is designed for speed. The full pipeline completes in minutes, not hours. The following table shows typical durations for a single-app conversion.
| Phase | Typical duration | Notes |
|---|---|---|
| Extract (PRJ generation) | 5–15 seconds | Depends on QVW complexity. Skipped if a PRJ folder already exists. |
| Parse + Convert + Write | Under 30 seconds | The core XML-to-JSON conversion. Handles complex apps with hundreds of objects. |
| Deploy (cloud build) | 1–3 minutes | Includes app creation, media upload, and app build on the tenant. |
| Reload | Varies | Depends on data volume, data source latency, and tenant resources. A binary load of a typical QVW completes in under a minute. |
A single-app conversion with cloud deployment and data reload typically completes in two to five minutes end-to-end. Local-only conversions (--unbuildOnly) complete in under 30 seconds.
In batch mode, QV2QS converts multiple projects in parallel. Total batch time scales with the number of projects divided by the worker count. For a batch of 20 applications with four workers, expect roughly five times the single-app duration for the local conversion phase, plus cloud deployment time.
Output folder structure
The --outputDir argument specifies the output root. QV2QS creates a subfolder named after the QVW file (or PRJ folder) inside the output root. All conversion output for the project is written into that subfolder. If two QVW files share the same name, QV2QS appends _2, _3, and subsequent numbers to avoid collisions. This behavior matches batch mode, where each project also receives a dedicated subfolder.
<outputDir>/
<ProjectName>/
build/
images/
reports/
logs/
cloud/
qvf/
QV2QS creates the output folder if the folder does not already exist. If the folder exists from a previous run of the same QVW, QV2QS reuses the folder. Existing log files in the folder are preserved unless Clean logs is enabled. The output directory must not be the same as or a parent of any source directory. QV2QS validates the output path before starting the conversion and reports an error if the paths overlap. The project subfolder contains the following:
| Folder / file | Contents |
|---|---|
build/
|
Qlik Sense app structure for qlik app build. Contains config.yml (build manifest), script.qvs (load script), app-properties.json, connections.yml (data connections), dimensions.json (master dimensions), measures.json (master measures), variables.json, and an objects/ subfolder with one JSON file per sheet and visualization. |
images/
|
Extracted media files (de-duplicated by content hash) and backgrounds.json (background manifest). |
reports/
|
executive_summary.json, executive_summary.html, and the Excel conversion report (*_conversion_report_*.xlsx) if enabled. |
logs/
|
Per-run structured log files. |
cloud/
|
cloud_state.json (app ID, media hash, sheet ID mapping, timestamp) and alternate_states.json. Created during cloud deployment. |
qvf/
|
Exported QVF files (created when --exportQvf is used). |
.qv2qs_source
|
Marker file that records which QVW produced the subfolder. QV2QS uses the marker to detect name collisions and to reuse the correct folder on subsequent runs. |
Open the output folder directly from the wizard after a conversion completes.
After conversion
After a conversion completes, work through the following items grouped by priority.
Fix before publishing
- Open the Excel conversion report in the
reports/subfolder and review the Follow-up_Objects worksheet. Fix all items marked Error first (objects that failed to convert), then Placeholder (objects that need rebuilding), then Adjustments Required (objects that converted partially). - Review analysis findings on the Analysis worksheet, including macro references, Section Access usage, and load script patterns that may need manual attention.
- Verify that expressions evaluate correctly. QV2QS automatically fixes set analysis quoting issues during conversion. Review calculated dimensions, conditional coloring, and expressions using QlikView-only functions (
GetCurrentField(),MsgBox()) that require manual rewriting. - Check the Overflow_Actions worksheet for objects where excess dimensions or measures were moved to the alternatives collection.
Verify before publishing
- Open the converted app in Qlik Sense and verify that sheet layouts, object positions, and background images appear as expected.
- Confirm that tab container navigation (button strips or tabbed containers) switches between content areas correctly.
- Test drill-down and cyclic group cycling behavior on charts that use dimension groups.
- Verify that show conditions hide and reveal objects as expected.
- Check sort orders on listboxes and tables, particularly for date-like fields.
Polish
- Adjust fonts, colors, or object positioning in the Qlik Sense app editor as needed. For guidance on layout positioning, see Conversion layout settings.
For a complete description of report contents, see Conversion report.