Are you the type of person who deploys Qlik apps by simply exporting a QVF, renaming it, and then importing it to your target environment? If so you’re not alone! In fact, in almost every Qlik team we’ve worked with this is actually a common practice. And in almost every single case, they’ve had to deal with the fallout when something goes wrong and they have to deploy an app in a rush to fix a problem. So for anyone that has “not had to manually remove a broken deployment after trying to deploy a QVF file, while trying to meet a business critical deadline” — congratulations. You’re in the minority.

The fact that we have to manually deploy stuff to production doesn’t necessarily mean that things are broken. No, manual deployments work. They work until they stop working. They stop working when the wrong version is deployed. They stop working when a Friday afternoon deployment breaks a critical dashboard that 200 users rely on for work on Monday. They stop working when the need to roll back to the previous deployment hits when there is nothing to roll back to.

This guide provides information on the processes involved in deploying stable Qlik environments, while having an unstable development environment. This guide applies whether you are a solo developer with five applications or a development team of ten, managing 100 or more applications.

1. Separate Your Environments — And Mean It

Every Qlik deployment should flow through at least three environments:

• Development (DEV) — where developers build and experiment freely
• Testing / QA (TEST), the stage where the upcoming changes are validated before deployment.
• Production (PROD) — where end users consume dashboards and reports

One of the more common misunderstandings in the DevOps world is treating DEV and PROD as the same server. Publishing to the stream that the end users see is not a deployment process, it’s simply publishing.

Best practice: We recommend that you use separate sites in Qlik Sense (or separate tenants in Qlik Cloud) for each environment. If budget constraints make it impossible to have separate servers, then we recommend at least having separate streams and strict publish rights.

The golden rule: There should be no developer with publish access to the Production stream. Period.

2. Never Deploy from a Developer’s Desktop

One of the most common Qlik deployment anti-patterns:

1. Developer opens Qlik Sense Desktop
2. Builds or modifies an app
3. Exports QVF from Desktop
4. Imports QVF into the server environment
5. Publishes to a stream

Every step in this chain is a risk:

• The Desktop version might differ from the server version
• Data connections on Desktop don’t match server connections
• Section Access might reference local groups instead of server groups
• Nobody knows which Desktop export is the “real” current version

Best practice: Always develop in the DEV environment from the server, and never from the Desktop. If the former is not possible in specific situations then the latter should be used but only up to the point that the application is re-deployed to the DEV server for further testing before it is promoted to the TEST environment.

3. Create a Deployment Checklist

Before any app moves from one environment to another, verify:

• Data connections are referring to the correct environment. DEV databases vs PROD databases
• Section Access rules are correct for the target environment
• All variables reference the right paths and servers
• Load script doesn’t contain hardcoded paths from another environment
• The application deployed successfully in the source environment
• Test results have been provided for the proposed changes
• A non-developer member has reviewed the changes (if applicable)

A written checklist helps catch the typos and errors that often fall through the cracks of memory. It’s an easy one to make better: print it out, pin it to a spot above your keyboard so it’s always in view, and use it every single time.

4. Version Your Apps — Even If You Do It Manually

The minimum viable version control for Qlik apps:

1. Before every deployment, export the current production QVF
2. Name it with a date and version: Sales-Dashboard_v2.3_2026-03-15.qvf
3. Save the file to a Team Shared Folder that everyone can see
4. Keep at least the last 5 versions

This is not great. But this is infinitely better than having no option to roll back at all.

QVF files are binary format, so you can’t diff them. You can’t look at the changelog between versions, say, v2.2 and v2.3 and wonder what changed. If you need to roll back to an older version, you can only hope the blob that made it into the next version isn’t drastically different.

All the above methods have some drawbacks. The best method is to split your application into human readable JSON/YAML sources and commit those to Git. This gives you proper version control of your application. All changes to formulas and variables will appear as single line changes in Git Diff, and you can do proper branching and merging of code (as you would with any other project code in your company). This is where QOps can help, in transforming the Qlik binary format into a more Git friendly, human readable format.

5. Standardize Your Promotion Process

Have a clear definition of how applications move from one environment to another, and make this process approachable to be easily deployed through automated tools, and to be straightforward enough for any member of the engineering team to deploy by hand in an emergency, without relying on “tribal knowledge”.

A solid promotion process looks like:

DEV → (export) → TEST → (validate) → PROD
↓                    ↓
Change log          Sign-off
updated             required

For each promotion:

• The developer initiates the request (not self-approves)
• The change is documented: what changed, why, and what to test
• Someone validates in TEST before production publish
• The application for PROD should be done by the team member assigned to this task and not by the developer themselves

Who benefits from separation of duties? Anyone whose site experiences unintended changes following a “deploy of the day”. The reason the application was created, is being lost in a single person being both author and deployment specialist. Every time a change is deployed, there are always typos, missing variables or misplaced tags. Even having a second pair of eyes catch these little errors has proven to be a remarkable improvement to reliability.

6. Handle Data Connections Per Environment

One of the trickiest parts of Qlik deployment: data connections.

Your application points to the development database in DEV, and to the production database in PROD. When you export a QVF from DEV and import it into PROD, the application references will include the data connections for the wrong database.

Options for handling this:

1. Convention for named connection — We would name the connection in each environment the same, but configure each server to point to a different database. So in our app we’d refer to Sales_DB in every environment. However, on DEV it would be pointing to dev-sql01 and on PROD pointing to prod-sql01.
2. Variable-based connections — Store the connection string in a Qlik variable and set the variable for each environment in the properties file or include script.
3. Automated substitution — Use deployment tooling to automatically swap out the connection references for the production environment during deployments.

We probably don’t need to say this, but manually editing connections after each import is error-prone and won’t scale.

7. Don’t Skip Testing

“It works in DEV” is not a deployment sign-off.

Before promoting to production, verify in the TEST environment:

• Data loads complete successfully — same data volumes, same schedules
• All visualizations render correctly — check for broken expressions, missing dimensions
• Section Access works — Login as different roles to test access
• Performance is acceptable — TEST should have similar data volumes to PROD. This means that data should be both recently and historically synchronised between environments to maintain accuracy and enable effective testing.
• No regression — features that worked before still work after the change

If you can’t test, you can’t deploy. An untested deployment into production may be expensive enough to buy all the time in the world.

8. Keep a Change Log

For every deployment to production, record:

• Date and time of deployment
• Who deployed the change
• What changed — specific apps, specific modifications
• Why — the business reason or ticket number
• How to roll back if something goes wrong

This change log becomes invaluable when:

• An executive asks “what changed last week?”
• Something breaks and you need to identify which deployment caused it
• An auditor asks for evidence of change management controls

It doesn’t really matter how you document this information; a shared spreadsheet, wiki page or even a Git commit history of the work that has been done will suffice.

9. Automate What You Can

Manual deployments don’t scale. Where this holds true is with small organisations with 5 applications and a handful of administrators who are willing and able to follow a small checklist. However with 50+ applications in a deployable software estate and a similar number of people trying to deploy to it on a daily basis, errors will creep in and manual procedures will fall apart.

What can be automated in Qlik deployments:

• App export and import — via Qlik Sense Repository API or PowerShell
• Data connection configuration — environment-specific config files
• Reload scheduling — task creation via API after deployment
• Notification — Slack/Teams message when a deployment completes or fails
• Rollback — the ability to automatically roll back to the previous version if the new one cannot be loaded

Full CI/CD for Qlik Sense (or any Qlik product) is a topic that gets debated a fair bit, and with the help of the Repository API and the power of QOps, we can confirm that Full CI/CD is possible. Here is a basic breakdown of what a Full pipeline would typically look like:

1. Developer commits changes to Git
2. Pipeline runs: exports the app, runs validation checks
3. App is deployed to TEST automatically
4. After manual sign-off, pipeline promotes to PROD
5. Post-deployment reload verifies the app works

This isn’t theoretical — teams are running this today.

10. Plan for Rollback Before You Deploy

This one is really straightforward. Every time you deploy something to production you should be prepared for the question “What happens if this breaks production?” Every deployment should have an answer to this, that is part of the process of doing a deployment in the first place.

Minimum rollback plan:

• Keep the previous QVF export accessible
• Document which version was running before the deployment
• Know how to re-import and re-publish the previous version
• Know the data connection state of the previous version

Better rollback plan:

• Automated one-click rollback (re-deploy previous version from Git)
• Deployment history that shows exactly what was running at any point in time
• Instant diff between the broken version and the last working version

DatalabsUa builds DevOps tools for Qlik analytics. QOps brings Git-based version control and CI/CD automation to Qlik Sense, Qlik Cloud, and QlikView.