Three migration paths. Real technical traps. The guide the market never published: scripts, syntax differences, and exactly what breaks at each stage.
Qlik announced end of support for QlikView in 2025. NPrinting has no meaningful roadmap evolution. And Qlik Sense on-premises is in maintenance mode while Qlik Cloud receives all new capabilities.
The result: companies that built their BI on QlikView over the last 15 years are facing a three-stage migration - and each stage has its own set of technical traps.
"The biggest trap in Qlik migrations is not technical. It is the assumption that the load script will behave the same way. It will not. And NPrinting even less so."
Qlik Sense load script syntax is largely compatible with QlikView - but there are critical differences that fail silently.
// QlikView handles NULL more
// permissively in associations.
// NULL fields participate in joins
// without explicit configuration.
LOAD * FROM sales.qvd (qvd);
// Declare NULL behavior explicitly
SET NullInterpret = '';
SET NullDisplay = '-';
NullAsValue Field1, Field2;
LOAD * FROM sales.qvd (qvd);
In QlikView, Section Access uses NTNAME, OMIT and ACCESS fields configured via QMC. In Qlik Sense the model is different: USER.EMAIL or USER.USERID replace NTNAME, and the OMIT field has been discontinued.
Section Access;
LOAD * INLINE [
ACCESS, NTNAME, REGION, OMIT
ADMIN, DOMAIN\admin, *,
USER, DOMAIN\anna, West, COST
USER, DOMAIN\john, East, COST
];
Section Application;
Section Access;
LOAD * INLINE [
ACCESS, USERID, REGION
ADMIN, anna@company.com, *
USER, john@company.com, East
USER, pedro@company.com,West
];
// OMIT discontinued:
// use Row-Level Security via
// filter field in the data model
Section Application;
The TOTAL qualifier without a field specification ignores all chart dimensions on both platforms. QlikView and Qlik Sense behave identically here - basic TOTAL syntax migrates without change.
// TOTAL without field: ignores
// all chart dimensions
// (same behavior on both platforms)
Sum(Sales) / Sum(TOTAL Sales)
// With field: restricts which
// dimensions TOTAL ignores
// (syntax available on both)
Sum(Sales) /
Sum(TOTAL <Region> Sales)
// Genuine migration edge cases:
// 1. Set Analysis nested with TOTAL
// - evaluation order can differ
Sum({<Year={2024}>} TOTAL Sales)
// 2. Master Visualizations in Qlik Cloud
// - selection context may interact
// differently with the TOTAL
// qualifier in certain scenarios
Qlik Cloud replaces the Streams model with Spaces - and understanding the difference between them is the first step toward a rework-free migration.
In Sense on-prem, integrations use Virtual Proxies with certificates or JWT. In the Cloud, the standard is OAuth 2.0 with declared scopes.
Authentication via OAuth 2.0 - Qlik Cloud API# Get access token (Client Credentials)
curl -X POST https://YOUR_TENANT.us.qlikcloud.com/oauth/token \
-H "Content-Type: application/json" \
-d '{
"grant_type": "client_credentials",
"client_id": "YOUR_CLIENT_ID",
"client_secret": "YOUR_CLIENT_SECRET"
}'
# Use the token to reload an app
curl -X POST \
https://YOUR_TENANT.us.qlikcloud.com/api/v1/apps/APP_ID/reloads \
-H "Authorization: Bearer ACCESS_TOKEN" \
-H "Content-Type: application/json"
On-premises QVDs live in file shares or local directories. In the Cloud, they require a Data Connection pointing to S3, ADLS Gen2, GCS, or Qlik Data Gateway for on-premises sources.
LOAD * FROM
[lib://QVD_Store/sales_$(vYear).qvd]
(qvd);
// Data Connection: "S3_DataLake"
// configured in the Data Space
LOAD * FROM
[lib://S3_DataLake:sales/$(vYear).qvd]
(qvd);
// Or via Qlik Data Gateway
// for QVDs on corporate network
This is the most underestimated path. Many teams assume "NPrinting will keep working" after moving apps to the Cloud. It will not - NPrinting only connects to Qlik Sense on-premises.
NPrinting has no support for Qlik Cloud. If your apps migrate to the Cloud, your report distribution must migrate too.
Templates: Excel, Word,
PowerPoint, HTML, PDF
Distribution: Email, Folder,
NewsStand
Bursting: by user field
in connection (user filter)
Scheduling: cron-like via
NPrinting Scheduler
Pixel-perfect: yes, via
detailed Office template
Templates: Qlik Sense app
(Office templates do not import)
Distribution: Email via
Qlik Application Automation
Bursting: loop in Automation
+ dynamic Section Access
Scheduling: Automation
(time or event-based triggers)
Pixel-perfect: via PDF export
configured in the app
In NPrinting, bursting was declarative: point to a field and it generated one PDF per value. In the Cloud, bursting is imperative via Automation:
Bursting logic - Qlik Application Automation (pseudocode)// Block: Start (Trigger: Schedule - daily at 6am)
// 1. Fetch list of regions via REST API
GET /api/v1/apps/{appId}/data
→ returns list of values for field "Region"
// 2. Loop through each region
FOR EACH region IN region_list:
// 3. Apply selection via Engine API
POST /api/v1/apps/{appId}/reloads
body: { selections: [{ field: "Region", values: [region] }] }
// 4. Export PDF from configured sheet
POST /api/v1/apps/{appId}/sheets/{sheetId}/export
body: { outputFormat: "pdf" }
→ returns URL of generated PDF
// 5. Send by email
Email: to = lookup_email(region)
subject = "Report - " + region
attach = PDF_URL
For critical pixel-perfect reports (regulatory, financial), evaluate a hybrid on-prem Sense approach or a complementary reporting solution while Cloud Reporting matures.
Every migration starts with an honest inventory. Run this before opening any project ticket:
QlikView sitting idle for years waiting to migrate? NPrinting nobody knows how to replace? Sense on-prem with an end-of-support date approaching?
Tell me in the comments where you are on this journey. I have been through all three paths in production.
#Qlik #QlikSense #QlikCloud #QlikView #NPrinting #DataGovernance #BusinessIntelligence #BI #DataEngineering #CloudMigration