Migrating to Qlik Cloud: The Complete Guide (2026)

Qlik releases a new update every Tuesday. On-premises environments also receive updates, but much less frequently and much later.

That is why migrating to Qlik Cloud is on the agenda at so many organizations I speak with. Not because their current environment is broken—it often runs perfectly well—but because product development is happening elsewhere. Organizations that remain on QlikView or Qlik Sense Enterprise Client-Managed miss out on Qlik Answers, Qlik Predict, Qlik Automate, and the governance improvements introduced in recent years.

The technology is rarely the problem. Moving apps with the Qlik Analytics Migration Tool (QAMT) is relatively easy. I repeatedly see problems arise when organizations underestimate how differently governance, licensing, and administration work after migration. This ends up requiring more time and budget than initially planned.

This guide shows what a Qlik Cloud migration involves in practice: what you can and cannot bring, which steps you need to take, and when it makes sense to bring in outside help—or when it does not.

In short: Qlik’s product investment is focused on the cloud. On-premises environments remain supported but do not receive new features. Migration involves more than moving apps: governance, licensing, and administration change fundamentally. The free Qlik Analytics Migration Tool (available from Qlik starting in May 2025) lowers the barrier, but it does not migrate everything. Good preparation starts with cleaning up.

Table of Contents

• When is migrating to Qlik Cloud the right choice?

• What can you bring to Qlik Cloud, and what can’t you bring?

• The migration steps in practice

• What changes in your environment

• The most common mistakes

• The first 90 days after go-live

• Should you do it yourself or bring in a partner?

• Frequently asked questions

When is migrating to Qlik Cloud the right choice?

Qlik Cloud is where product investment is focused. That is the honest reason to migrate: not because your current environment is broken, but because otherwise you will fall behind as new features are developed.

The three main drivers are:

Cloud-first roadmap

New features are released first, and sometimes exclusively, in Qlik Cloud. Examples include Qlik Answers (generative AI), Qlik Predict, Qlik Automate, Data Lineage, and advanced collaboration features. On-premises environments remain supported, but they are not the product development team’s priority.

Infrastructure overhead

For growing environments, the cost of on-premises hardware, licenses, and management can sometimes exceed the cost of moving to the cloud. This is not universally true: moving smaller, stable environments to the cloud is not necessarily cheaper.

Scalability

Qlik Cloud scales with usage. Peak loads no longer require additional hardware.

When is it not urgent?

Not every organization needs to migrate right now. Do you have a smaller, stable environment, a strong internal team, and little need for new cloud features? Then there is no pressing urgency.

I see partners and vendors recommend otherwise too often. But a migration without a concrete business case rarely delivers the desired result. “It’s simply the direction things are going” is not a business case.

Are you unsure whether Qlik Cloud is truly the right move for your organization, or would you like an existing migration proposal reviewed? A Second Opinion Data & Analytics gives you an independent assessment of the chosen direction, assumptions, and risks.

If you are still using QlikView

Anyone still running QlikView in 2026 probably has a reason for doing so. Perhaps the environment works perfectly well. Perhaps there has never been enough capacity to migrate. Both are understandable.

It is important to know that a QlikView migration differs from a Qlik Sense migration. It is not a move; it is a rebuild. QlikView apps are fundamentally structured differently from Qlik Sense apps. You cannot convert them automatically. They need to be redesigned, sometimes completely.

Want to understand the scale of the task first? Qlik offers the SaaS Readiness App, a QlikView application that runs against your environment and identifies within minutes which apps are ready for migration, including session usage and data lineage. It is a useful starting point before deciding on the front end.

For the data and scripting layer, you use QAMT: load scripts, variables, and master items are carried over. For the front end, you need a separate tool—the QlikView to Qlik Sense Converter—which automatically converts sheets, visualizations, layout, and styling. The two tools currently operate separately: integration of front-end conversion into QAMT is only planned for a future release, so until then, you need to coordinate the two yourself. Otherwise, you will have to rebuild the front end manually.

A manual rebuild is not necessarily a problem. After years of QlikView, redesigning the presentation layer is often a good idea. The downside is user acceptance: people want to recognize their familiar environment, and for many users, a completely new interface feels like more change than they expected.

Download the QlikView to Qlik Sense Converter Tool

When Power BI is the better choice

Not every organization benefits from Qlik Cloud. We work with both platforms, so our preference follows yours: which platform best suits your situation?

Does your organization operate primarily within the Microsoft ecosystem? Do you already have a Microsoft 365 license and no need for complex self-service data exploration? Then Power BI is probably the more affordable and logical choice.

Signs that Power BI may be a better fit include an IT environment fully driven by Microsoft, relatively static dashboards, and little need for ad hoc analysis of large or complex datasets.

Does this sound familiar, but is the decision still open? With an independent BI tool selection, we assess Qlik Cloud, Power BI, and, if relevant, Microsoft Fabric against your requirements, users, and existing architecture.

Read our guide to migrating from Qlik to Power BI or Microsoft Fabric

What do you bring to Qlik Cloud, and what do you leave behind?

The free Qlik Analytics Migration Tool (QAMT, available since May 2025) significantly lowers the technical barrier. The tool migrates apps, users, streams, data connections, and user content. It also automatically repairs Lib-Connect references in load scripts.

But QAMT does not migrate everything.

What QAMT does not do

Three categories always require manual work:

Security Rules

On-premises security rules are not mapped to Qlik Cloud. You must manually reconfigure them using spaces and roles.

Task chains

Reload chains are not migrated by QAMT. You rebuild them in Qlik Cloud, where you can configure them natively using the built-in task chain functionality for reloads.

Section Access

Section Access works differently in the cloud, and migration is manual. There is also a technical detail that is often overlooked.

In Qlik Sense Enterprise Client-Managed, Section Access uses the USERID column with a value such as DOMEIN\gebruiker. In Qlik Cloud, USERID maps to the IdP subject, which is often a hash or GUID rather than a readable name. In the cloud, preferably use the USER.EMAIL column. It is more stable and easier to understand.

What does not carry over

These features are either unavailable or only partially available in Qlik Cloud:

NPrinting

Qlik Cloud Reporting provides a partial replacement: QAMT migrates Excel and PixelPerfect templates, but the functionality is not complete. In addition, the number of reports is limited by default, so you will probably need an additional license. In our experience, Mail & Deploy provides by far the most comparable experience to NPrinting in the cloud as a one-to-one replacement.

ODBC/OLE connectors

Custom Windows connectors are not available in the cloud. You need a Data Gateway, or you must move the data to cloud storage.

Offline access

Not available in Qlik Cloud.

Backup and rollback

A complete version history for apps is not available yet. However, you can recover an accidentally deleted app: Qlik Cloud has a soft-delete feature that allows deleted apps to be restored for up to 14 days after deletion. This covers “accidentally deleted,” but not “I want to return to last week’s version.”

Alternative: Bitmetric Backup for Qlik Cloud

Two common misconceptions

Extensions and dev/test/prod separation often appear on the list of things that “aren’t possible in the cloud.” Neither claim is entirely accurate.

Download the Qlik Analytics Migration Tool (QAMT)

Extensions

Like on-premises extensions, visualization extensions run in the browser and will largely continue to work, provided that references to external domains are permitted through the Content Security Policy. Extensions that use Server-Side Extensions (SSE) to connect the Qlik engine to external Python or R scripts, or to other custom services, do not work: Qlik Cloud does not yet provide an integration point for this.

Dev/Test/Prod separation

The capacity model includes 5 tenants by default, so separate dev, test, and production environments are indeed possible without having to negotiate with Qlik Sales. Note that all tenants draw from the same capacity, so a resource-intensive test environment reduces the capacity available for production. A lighter alternative is to separate environments using Spaces within a single tenant, without setting up separate tenants.

In my experience, this assumption itself is the most underestimated source of delays: people assume the worst-case scenario (“surely that isn’t possible in the cloud”) instead of checking. Extensions and dev/test/prod separation are the clearest examples, but assess what you have for each component rather than adopting assumptions.

Migration steps in practice

A Qlik Cloud migration always follows the same phases, regardless of the size of the environment. The complexity varies; the structure does not.

Step 1: Assessment

Inventory everything before you begin: apps, QVDs, data connections, extensions, users, licenses, and security rules. Use the 4-R framework for this:

• Retain: migrate the app without changes
• Redesign: extensively rebuild the app for the cloud
• Refactor: modify the app without completely rewriting it
• Retire: archive the app because no one uses it anymore

That last point is more important than it may seem. Clean up before you migrate. Outdated, duplicate, and unused apps take up migration time, increase the testing burden, and distort the apparent size of the environment. Clean environments migrate faster.

Step 2: Planning and preparation

Choose your identity provider (IdP). Qlik Cloud supports one interactive IdP per tenant: OIDC or SAML. This is a fundamental architectural decision. Will you use Azure AD, Okta, or another provider? This choice affects your Section Access configuration, user provisioning, and SSO setup. Where possible, configure SCIM for automatic provisioning: users you add or remove in your directory, such as Azure Entra ID, will then automatically appear in Qlik Cloud without having to sign in first.

Also define your Spaces structure before you migrate. Streams in Qlik Sense become Spaces in Qlik Cloud. But Spaces involve more than a name change: they also contain data, connections, and experiments. The structure that made sense for Streams is not always the best structure for Spaces.

Plan your data connectivity early. There are three options:

1. Direct cloud-to-cloud connection (the simplest option)
2. Move data to cloud storage such as Azure Blob or Amazon S3
3. Qlik Data Gateway (for on-premises data sources you do not want to move)

Is the Qlik Cloud migration part of a broader modernization of your data environment? A data strategy can help you develop the desired architecture, priorities, and transition path as a coherent whole.

Step 3: Migration and testing

Use QAMT for apps, users, and connections. Configure Security Rules, task chains, and Section Access manually. Test after every batch, not just at the end.

Choose your approach carefully: a big bang or a phased migration by business unit. In my experience, a phased approach works better. You learn from each batch, can make adjustments, and give the organization time to adapt. A big bang creates more pressure, greater risks, and less room for correction if something goes wrong.

Hybrid mode: a transition period, not an end state

Not all apps need to migrate at the same time. Qlik normally provides a transition period during which you can run on-premises and cloud environments side by side, allowing you to migrate in phases without moving the entire organization at once.

Do not treat this as a permanent architectural choice. Hybrid deployments are increasingly falling out of favor: Qlik’s product investments are focused on the cloud, while on-premises remains supported but is not being developed further. Keeping part of your environment on-premises because migration is difficult at that point only postpones the inevitable.

What does make sense is to temporarily keep apps with complex architectures that are not yet cloud-ready running on-premises while the rest of the organization migrates. App Distribution Service supports synchronizing apps between environments during this transition period.

What changes in your environment?

After a migration, the environment changes across three dimensions: governance, licensing model, and administration. Anyone who underestimates this will quickly run into problems.

Governance: Spaces and roles

Streams and security rules disappear. They are replaced by Spaces and role-based access control. This is not more complex, but it is fundamentally different.

In Qlik Sense Enterprise Client-Managed, you manage access through security rules with conditions based on user attributes. In Qlik Cloud, you manage access through Space memberships and roles. The logic shifts from “who can see what” at the script level to “who belongs to which Space and with which role.”

Anyone accustomed to the flexibility of security rules will need to rethink their approach. The permissions structure that has worked for years cannot simply be transferred to Qlik Cloud.

Licensing model: from named users to capacity

Qlik Cloud works differently from on-premises licensing. The shift from named users to capacity-based licensing has budget implications that almost always surprise organizations.

The model is not necessarily more expensive, but the costs arise in different areas. They also scale differently. Have the financial impact calculated before the contract negotiations, not afterward.

Management: infrastructure out, releases in

The infrastructure goes away. No servers, no patches, no hardware-level backups. That is a relief for many IT departments.

But Qlik Cloud introduces something new: weekly feature releases, every Tuesday (Qlik, release cadence documentation). In an on-premises environment, you decide when to upgrade. In the cloud, this happens automatically. This requires a structured release impact analysis: what is changing, and how will it affect my extensions, API integrations, or workflows?

Management does not disappear after the migration. It shifts.

Data Gateway: two options

For on-premises data sources, you need a Qlik Data Gateway. There are two types:

• Direct Access Gateway: runs real-time queries on on-premises data and runs on Windows
• Data Movement Gateway: moves data to cloud storage for processing and runs on Linux

Which one you need depends on your architecture and whether you want to move the data or query it in place. Both require planning, installation, and management. They are routinely overlooked in the preliminary phase.

The most common mistakes

The costliest mistakes in a Qlik Cloud migration are not technical. They are organizational.

Involving NPrinting too late

Qlik Cloud Reporting is not a complete replacement for NPrinting: its functionality is limited, as is the standard number of reports. Anyone who discovers this only after go-live has a problem that cannot be resolved quickly. Take inventory of your NPrinting usage during the assessment phase. Options include switching to Mail & Deploy (a similar experience in the cloud), simplifying reports, or temporarily continuing to run NPrinting on-premises.

Not planning the Data Gateway early enough

Installing a Gateway may seem straightforward. In practice, firewall rules, network segmentation, and Windows versions all play a role. Plan this early and test it thoroughly before the rest of the migration depends on it.

Not calculating the impact of the licensing model

The switch to capacity-based licensing has financial implications. Anyone who only notices this when the first invoice arrives faces an unpleasant surprise that cannot be reversed quickly.

Changes to the existing environment during the migration phase

Once the migration begins, you “freeze” the on-premises environment. Any production changes made after that must also be implemented in the cloud. This takes more work than it may seem and leads to version conflicts.

No user acceptance testing before go-live

Everything works technically, but users cannot find their apps, navigate differently than expected, or lack permissions. A round of UAT prevents support calls during the first week after go-live.

The mistake I see most often? Organizations go live before users know what has changed. Communication and training are not nice-to-haves. They are prerequisites for a successful go-live.

The first 90 days after go-live

Most problems with a Qlik Cloud migration occur in the first 90 days. Not because the migration has failed, but because the environment is still being configured and users are still adjusting.

Monitoring

Are the apps being used? Are there errors in reload tasks? Who is using the Gateway? Put monitoring in place before you go live, not after.

Refining governance

Space memberships are not always right the first time. Users report having too little or too much access. Make adjustments based on what you observe, not on what you initially thought was right.

Release impact analysis as an ongoing activity

A new Qlik Cloud release arrives every Tuesday. Make assessing it a regular activity: what has changed, does it affect our extensions or API integrations, and is any action required? Organizations that do not establish this process only discover problems when users report them.

Onboarding users

Not everyone adapts automatically. Create short guides, organize a Q&A session, or appoint an internal point of contact. Navigation in Qlik Cloud differs from Qlik Sense Enterprise Client-Managed. For some users, that can feel like an unexpected hurdle.

The first 90 days determine whether a migration is perceived as successful, even if everything went smoothly from a technical perspective.

Explore our Qlik Support & Management services

Do it yourself or bring in a partner?

Whether you can carry out the migration yourself depends on three factors: scale, in-house expertise, and available capacity.

When doing it yourself is realistic

• Small environment (fewer than 20 apps)
• Experienced in-house Qlik team with cloud experience
• Simple architecture: few extensions, no NPrinting, and no complex security rules

When a partner is essential:

• Large app portfolio or complex architecture
• NPrinting is in use
• Tight deadline with little room for recovery
• No internal team or insufficient cloud expertise
• Section Access with complex logic
• Multiple data sources and Gateway configurations

A good Qlik migration partner does more than carry out the technical migration: they also transfer knowledge. After go-live, your team must be able to manage the environment. A partner that does not include this creates dependency rather than self-sufficiency.

Explore our Qlik consulting services

Frequently asked questions

Conclusion

A Qlik Cloud migration is technically feasible. The organizational side is the real challenge.

Qlik’s product investments are focused on the cloud. Organizations that remain on-premises will also miss out on new features. But that does not mean you need to migrate tomorrow. Build a business case, take an honest inventory of what you have, and create a plan that fits your organization—not a vendor’s ideal scenario.

The most successful migrations I have guided had three things in common: a thorough assessment beforehand, a phased approach for each business unit, and attention to users after go-live.

Want to know what a migration would mean for your specific environment? I’d be happy to take a look with you.