Over the past few months we tested Qlik Answers on a dashboard of one of our customers. We had already run plenty of tests on small, simple apps. Those results were promising and the user experience was good, but small apps are not where analytics gets difficult. So we moved to a real use case: a production sales model, with the data quality issues and modelling choices that come with it. 

AI tooling moves fast, so treat this as a snapshot. This review describes how Qlik Answers behaved in July 2026. The agentic experience was not brand new by then. Qlik took it generally available in February 2026 and expanded the agent set at Qlik Connect in April. What we cannot tell from the outside is which underlying model updates landed in between. 

Why Qlik Answers and not Claude, ChatGPT or Gemini 

Together with the customer we set two hard requirements: EU-only, and no training on our data. That is worth spelling out, because the agentic Qlik Answers experience does not stay inside your tenant region by default. You have to opt in to cross-region inference, which lets Qlik send the inference request to the AWS region where the model is available. For tenants in the EU, Qlik states that an EU cross-region inference profile is always selected, so the request stays within EU AWS regions, and that enabling it does not give Qlik or AWS access to your data.  On the training question the documentation is explicit: Qlik states it does not use customer data to train any AI model outside the customer’s own tenant. 

For the other models we could not get that same guarantee, so the choice was made for us before we compared a single answer. 

So how does Qlik Answers compare?

We did run the same questions on our own test dashboards with Claude, ChatGPT and Gemini. In our opinion those answers were better, with one caveat we ran into straight away: on the small Haiku model Claude got it wrong, and only on Opus was it clearly ahead of Qlik Answers. The frontier models bring a wider set of skills to the problem, which simply gives them more to work with.

That is an observation on test data rather than a benchmark, and it did not change the decision here: the EU requirement was not negotiable.

This is not necessarily an either-or choice, though. Qlik also exposes its analytics capabilities through the Qlik MCP Server, which means you can use clients such as Claude or ChatGPT to work with governed Qlik data and master items. In that setup, the external model does the reasoning while Qlik provides governed access to the data. The trade-off is that data passed to the model is then processed under that provider’s policies, so for this customer it did not solve the EU-only requirement.

The test dashboard we used is called ThermoThuis, a demo application we built with public data for all addresses in Aalsmeer, where our office is located. It brings together information such as energy labels, WOZ property values and other housing characteristics to help identify where sustainability investments are likely to have the greatest impact and return.

Below you can see what Qlik Answers and Claude made of the same prompts.  
 
My first reaction was that Qlik Answers had won this round, because Claude on Haiku returned the wrong answer. Then we switched Claude to Opus, and honestly, I found Claude the stronger of the two. Its charts made the point, and the counts differ slightly because Qlik Answers picked a different measure than Claude. The visuals from the second prompt are where that gap is clearest. 

Prompt: Visualize some key trends

Qlik Answers:  

Prompt: Can you see a relation between year built and energy labels?

The model matters, the context decides. 

While we were setting this up, we read several sources making the same point: context does more for accuracy than model choice does. The table below comes from one of them. The same question was asked at every iteration, and the only thing that changed was how much context the model had to work with.

Source: Datacult, The Boring Work That Makes AI Analytics Actually Work. 

Accuracy climbs from 0% to 92% without ever swapping the model. In our experience that pattern holds outside the lab too: the model matters, but the context decides. Give a frontier model a dashboard without context and it will still hand you the wrong number, confidently.

This review is our attempt to test that on a real dashboard. First we walk through the five things we changed to make the answers reliable. Then we look at where it runs into its limits today, and what would take it further: context organized per analysis rather than per dashboard.

The model we tested on

The business context: Fashion Analytics

Some context on the business first, because the questions later in this article only make sense once you know how this company works. Our customer is a fashion company: it designs collections, presents them to retailers per season, and collects orders for production. That makes the season calendar the backbone of every analysis.

A pre-order, a re-order and a returns period each run on their own rules, and a jacket that proves itself gets carried over to the next collection under the same article name, redesigned to the trends of that season.

Most of the questions in this article are the ones a buyer or an account manager actually asks:

“Which articles grow from one season to the next?”

“How does the current season compares to the previous one?”

And that is exactly why it is a good test for Qlik Answers: the questions are easy to say out loud, but answering them means knowing which season, which article name and which measure belong together, and none of that is obvious from the data alone.   

The data set we used is the Sales model. It is a star schema with a concatenated fact table. That detail matters, because it means a naive Sum(Sales) returns the wrong number. To get a correct answer, the AI must use the master measures. Any approach that lets it invent its own aggregation is going to fail here, and it will fail quietly. 

Step 1: Fill the logical model 

The first thing we did was make the app available to Qlik Answers so it could be indexed. That went fine. A short wait, and we could start asking questions. 

The answers were wrong. Qlik Answers was inventing its own measures instead of using ours, which on a concatenated fact table produces numbers that look plausible and are not. 

The cause turned out to be the logical model. Qlik Answers reads the logical model and reasons over it, and our master measures were not in there. So it filled the gap itself. That is consistent with what Qlik documents. Master measures and dimensions are evaluated before raw fields, and items defined by the developer count as the trusted source. But that only applies to master items that actually sit in the logical model. Ours did not, so there was nothing to respect and it wrote its own expression instead. We added the measures to the logical model, and Qlik Answers immediately started answering with the master measures instead. 

View of the logical model 

Step 2: Describe your master measures 

In step 1 our questions were phrased to steer Qlik Answers towards a specific master measure. That works for a test, but it is not how anyone actually uses a dashboard. You want a colleague in sales to be able to ask a question in their own words and get the right answer. 

That means better context. Three things in particular: synonyms for the terms people actually use, an explanation of what each measure means, and per measure a note on when it should be used and when it should not. 

Following Qlik’s own guidance on writing descriptions, we went through every master measure and filled the description field with its real business meaning rather than a restatement of the expression. We used an LLM for the first pass: we handed it our naming conventions and let it draft a description for every master measure, then checked each one against what we actually meant. In the same round we marked which measures are technical building blocks for the underlying calculation and which ones end users are supposed to reach for. The model can phrase it, but only we know which measure is the one people should use. 

The answers got better. Accuracy went up, and Qlik Answers became able to map a question to the right master measure on its own. Not perfectly, but the difference between a filled description field and an empty one is large enough that we would not skip this step again. 

Step 3: Read the reasoning 

Next we asked whether Customer A had ordered more or less than in the same period last year. After a short wait we got visualizations based on the number of orders. We followed up by asking for the same comparison in euros. 

The reasoning Qlik Answers exposed for that follow-up looked like this. Customer names, field names and figures have been replaced to anonymise our customer’s data, but the structure of the output is untouched: 

It works. But it picked Gross COST PRICE, and we expected Gross Amount for this question. Interesting detail: Gross Amount is not the measure that came back in the reasoning at all.  

The generated measure looked like this:

{<[Customer]={'123456 - DO NOT USE - CUSTOMER A','324567 - CUSTOMER A','456789 - STOCK ORDER CUSTOMER A'},[Date Order]={">=$(=01-01-26 12:00:00[.000000])<=$(=30-06-26 12:00:00[.000000])"}>} [Gross COST PRICE] 

Look at that customer selection. It includes an account literally named DO NOT USE. No orders sit under it, so the number is still correct, but the AI had no way of knowing it should be excluded. Two options: explain in the context that Customer Status must be filtered to active customers only, or remove the account from the dashboard entirely so nobody, human or machine, can pick it by accident. In our experience the second option is the one that actually sticks. 

The date filter is worth a second look too. It filtered on [Date Order], while the model also exposes a plain Date field, and Date is the more logical one to filter a period on. Same root cause as the customer selection: nothing in the context told it which of the two to prefer, so it picked the one whose name looked closest to the question. Two fields that sound alike and behave differently are exactly the kind of thing your colleagues learn once and never write down. 

The knowledge gap is in the context

This is where the gap sits. An experienced user pulls the right answer out of a dashboard because they know which fields to avoid. That knowledge lives in their head, not in the app. An AI only has what is written down. Everything a colleague knows through experience has to become explicit context, or it does not exist. 

It helps a lot that Qlik Answers shows this level of detail. You can see how an answer was built and, more importantly, where to sharpen the context to get a better one. An answer without visible reasoning would have looked perfectly fine here. 

So read the reasoning, and read Qlik’s own explanation of what each agent in the chain does. It is worth the twenty minutes. The Semantic Search Agent picks the master items it thinks your question needs, the Data Analyst Agent turns those into an analysis package, and master measures and dimensions are evaluated before raw fields. Once you know that, the reasoning output stops being a log and becomes a diagnostic. If it reached for the wrong measure, the problem is your description, not the question. Every improvement in the rest of this article came out of reading that output and working backwards to the context that caused it. 

Reasoning of Qlik Answers. Key information has been removed. We keep a set of measures ending in TOTAL for use in share measures: the same calculation as the regular measure, but with TOTAL in the expression. In this reasoning one of them scores high on similarity, which is exactly why it pays to check that only the measures the AI should use actually are exposed in the logical model.  

Step 4: Ask the question a business user would ask 

By this point the mechanics were in place. The real test is whether someone outside the BI team can get an answer. We tried a genuine analytical question: 

“Jackets repeat across seasons on Article Name. A given jacket name appears in SEASON 25 and in SEASON 24, for example. Can you analyse this and work out which jackets will perform best in SEASON 26? Best means highest growth. Please filter on [Article Season] <> CERTAIN VALUE. Relevant fields: Article BrandGroup, the brand of the season. Season Year, the year of the season. Block, the block within the season.” 

The results were good. We got a list of jackets ranked on growth, and a second list built the same way. 

Now look at how much we had to put into that prompt. It carries a lot of developer knowledge and field-level detail. It is also shorter than we wanted it to be: Qlik Answers caps a question at 500 characters, and we sat there cutting words to get under it. There was more we would have explained if there had been room. If you have to know the field names before you can ask anything, and then edit yourself down to fit the box, the tool is not doing its job yet. So that became the next step: stop relying on the person asking to know the model, and describe the dimensions the way we had described the measures. 

Step 5: Describe your master dimensions 

Same treatment as the measures. We described every dimension, pulled the raw fields from the data model out of the logical model, and left only the master dimensions exposed. That forces Qlik Answers to work with the dimensions and measures we want it to use, and keeps everything else hidden. It also closed the Date Order gap from step 3. With only the master date dimension left exposed, there is no near-identical raw field for it to reach for by mistake, so we did not have to write a description explaining which of the two to prefer. Removing the wrong option turned out to be cheaper than describing it. 

There is a rule of thumb here, and it is more mechanical than it sounds.

• Hide the key fields
• Hide the fields you only use inside measures
• Hide the flag fields

Leave the dimension fields visible, because those are what Qlik Answers needs to slice on. Qlik’s preparation guide points at the same lever: set those fields to Hidden under Visibility in the logical model, or prefix them with % in the load script so they hide automatically. 

This costs your end users nothing. The logical model governs what Qlik Answers is allowed to see, not what someone can select and filter on in the dashboard. Hiding a field there does not take it away from anybody. 

The answers improved again, and it stopped reaching for raw fields. This is the point where we would say the setup was genuinely usable: with enough context work, and a question written by someone who knows the model, Qlik Answers gives useful answers. Neither of those conditions is something you can expect from a business user on day one. 

Room for improvement: the visualizations 

This is where Qlik Answers still has the most ground to make up. Picking the right chart for the story you are telling is hard, and we can say that from years of building them by hand. During testing we saw plenty of visualizations where we questioned whether they made the point at all. 

Take the chart below. It came back after this question: 

“I want to see the key trends for Article Season > CURRENT and PREVIOUS. I want the differences per article category. Use the Sales EDI measure, specifically Sales EDI Qty and Sales EDI Amount.” 

Looking at the result, there are two choices we would not recommend regarding the visual: 

• Putting the amounts in a single column. You lose every basis for comparison that way. 

• A combo chart. We can argue about those in general, but putting Qty on the secondary axis and then also putting it in the bars does not make it better. 

Figure 1: the chart as Qlik Answers generated it, labels and values removed to anonymise our customer’s data  

To be fair: you can name the chart type in the question and Qlik Answers will build what you asked for. So this is not a complaint about what it can do, it is a comment about what it chooses. The default is where the problem sits, and the default is what a business user gets, because a business user typically does not know to ask for a grouped bar chart. 

With more prompting we did get to the right measure and could pull the right tables out. The honest conclusion: clicking through the dashboard would have been faster. 

Room for improvement: nowhere to put analysis knowledge 

At the same time, we cannot fit everything into a prompt. We have industry-specific constructs that we tried to explain to Qlik Answers and could not. To use a dashboard properly, an AI has to be taught how that dashboard works. This is a broader semantic-layer problem: AI needs more than access to fields and measures, it needs explicit business meaning and context. We wrote more about why the semantic layer is becoming an interface for AI here.

One example: we built a solution where selecting a value in an island table changes a variable, and that variable decides whether quantities are shown packed or unpacked. We have not been able to explain that to Qlik Answers. A second one: filtering to real articles only, leaving ledger and promotional articles out until you actually need them in the analysis. That did not land either. Default filters matter in the same way when you have several calendars in one dashboard. 

We also tried pointing Qlik Answers at a default bookmark, so you at least know it starts from the right point. In our tests it did not pick the bookmark up. 

For end users that separation already exists in the dashboard. We enforce it with separate sheets, each with its own filters, so a returns analysis cannot be run with the settings that belong to a pre-order. Qlik Answers has no equivalent. Every analysis draws on the same undifferentiated context. 

What we want is a short AI skill instruction: how certain steps and analyses work, which fields to use, what a correct answer looks like. And not one per dashboard, but one per analysis. A returns analysis runs on the same dashboard as a pre-order or a re-order analysis, and all three need different instructions: different default filters, different measures, a different idea of what a correct answer looks like. That is missing, and without it a user cannot reliably get good answers. 

The verdict 

So how do you get correct and consistent answers out of Qlik Answers?

Everything that worked for us came down to writing down what people already knew: measures in the logical model, descriptions on measures and dimensions, and default filters that put every question on the same footing. That last one matters more than it sounds, because it lets an end user check an answer against the dashboard they already use. Without that check, they will not trust it. 

What is missing is a place to put the rest. We want one skill instruction per analysis, not per dashboard: the standard filters, the measures that matter, how the packed and unpacked logic works, which article types to leave out. A returns analysis and a re-order analysis sit on the same model and answer to different rules. Right now that knowledge either goes into every single prompt or it goes nowhere. Bookmarks would have been a workaround, but they did not get picked up in our tests. 

That brings us back to the table at the top of this article. Accuracy went from 0% to 92% there without changing the model once, and our experience matches it: every improvement we got came from better context, not from a better engine. So we stand by the point, in its sharper form: the model matters, but the context decides.

The same principle applies beyond Qlik Answers. Reliable AI analytics starts with the data, metadata and context underneath it. We explore that broader data foundation for AI analytics here.

Take that further than this one tool. Whether you start asking AI questions next quarter or decide never to, the work in front of you is the same: get your data quality in order and write down the context that currently only lives in people’s heads. Every model that arrives after this one will need exactly that, and it is not wasted effort if you never point an AI at it, because it is the same documentation your own colleagues have been missing for years. In our experience this is the part organizations postpone, and it is the part that determines whether any of this works.

Want to see what Qlik Answers can do with your own environment?
We can help you assess your Qlik model, logical model, measures and semantic context, and identify what needs to change to make AI-assisted analytics more reliable.

> Talk to our Qlik consultants

Where Qlik Answers still falls short?

But we should be equally honest about the other half. If what we tested here had been the state of things two years ago, we would have been impressed. And we were not catching a first release early. Measured against what other models do today, and how they combine skills, it falls short. The reasoning it exposes is genuinely good, better than most tools give you, and it is the reason we could debug our own context at all. The visualization choices are not there yet, and neither is the ability to teach it how a specific dashboard works. 

Would I recommend it?

If your data has to stay in the EU, Qlik Answers is a reasonable choice and we certainly expect that it will get better. But do not buy it expecting the context work to disappear. That work is the job. The tool just makes it very obvious whether you did it. 

Tom Maarsen

Tom joined Bitmetric in April 2023, bringing with him years of experience in returns logistics, including extensive work with Qlik. Over the years, he has developed dashboards for productivity tracking and near-real-time inventory insights. At Bitmetric, Tom has deepened his expertise in Qlik, TimeXtender, and Qlik Automate. As an automation expert, he spoke at the Masters Summit for Qlik, sharing insights on optimizing workflows. In his free time, Tom enjoys gardening and spending time on the water on his boat.

The post Qlik Answers review: What we learned from real-world testing appeared first on Bitmetric.

Give a language model access to a database, tell it which tables are in it, and ask what last month’s revenue was. There is a good chance it will produce a well-formed query and a convincing answer within seconds.

But that still does not tell AI what your organization means by revenue.

Does it mean booked revenue, invoiced revenue, or delivered revenue? Are credit notes included? What about intercompany revenue? Which date determines the month? And if someone asks about revenue in the Netherlands, do we mean the customer’s country, the delivery address, or the sales organization?

That is not a SQL problem. It is a semantic problem.

And that is precisely why a concept that has circulated in business intelligence for decades is suddenly receiving so much attention again: the semantic layer.

In fact, I think its role is fundamentally changing.

Until now, we mainly built semantic models to provide dashboards and reports with consistent business logic. Soon, AI agents will use that same layer to understand our organizations.

From BI layer to interface for AI

The semantic layer is not new

Anyone who has worked in Business Intelligence for some time will recognize the idea. In the traditional BI world, a semantic layer was standard practice. A well-known example is the BusinessObjects Universe. A Universe placed a business-friendly layer over the technical database structure. Users worked with familiar concepts, dimensions, measures, and hierarchies without needing to know exactly how the underlying tables and joins were structured.

SAP still describes a Universe as a collection of metadata objects that allows users to analyze data in non-technical, understandable business language. (SAP Help Portal)

Cognos had a similar concept with Framework Manager.

The idea was simple and actually very sensible:

The database tells you how data is stored; the semantic layer tells you what that data means.

Of course, there was also a downside.

These traditional BI environments could become quite cumbersome. Before a user could build a report, a data warehouse often had to be designed, a central model built, a Universe configured, and someone had to grant permission to use it.

That was not exactly agile.

Then came self-service BI

Starting around the second half of the 2000s, the landscape began to change.

Products such as QlikView, followed later by Qlik Sense and Tableau, made it much easier to work with data quickly. Instead of spending months designing a central BI layer, an analyst or developer could load, model, and visualize data and deliver something useful almost immediately.

That was a major step forward.

I worked with Qlik for years myself, and that speed and freedom were a large part of its appeal.

But this shift also had a consequence: the explicit, centrally managed semantic layer began to fade from view.

That does not mean Qlik, Tableau, or later Power BI contained no semantics. Quite the opposite. A Qlik data model contains relationships and business logic, Tableau has logical models, and Power BI now offers extensive semantic models.

But in practice, that meaning often became scattered across different layers. Especially in Qlik, much of the business logic was captured not only in the data model, but also in variables, set analysis, master measures, script logic, and even individual object expressions.

That worked well as long as experienced developers knew where everything was and why it had been built that way. But it made the business meaning less explicit, less centralized, and harder to reuse outside the original application.

As a result, the semantic layer received far less attention as an architectural principle in its own right.

We increasingly began capturing business logic wherever we needed it at the time:

• In a Qlik app
• In a Tableau workbook,
• In a Power BI semantic model,
• In a SQL view,
• In a DAX measure,
• In an ETL script.

And sometimes in several places at once.

Self-service made analytics more accessible, but it also made it very easy to create multiple versions of the same truth.

Ultimately, we ran into the same problem

As long as an organization has a limited number of dashboards, the problem is manageable. But as self-service BI becomes successful, dozens or hundreds of models, apps, and reports emerge. Then the familiar debates begin.

What is striking is that these are roughly the same problems the classic semantic layer was originally designed to solve.

And so the concept returned.

Power BI now explicitly refers to semantic models. Looker built much of its platform around LookML. dbt developed its Semantic Layer and MetricFlow. Data platform vendors are increasingly talking about metrics, data products, ontologies, and semantic layers.

I sometimes look back on BusinessObjects with a certain nostalgia. Universes were not such a bad idea after all. But the renewed appreciation for the semantic layer is mainly driven by our rediscovery that access to data is not the same as agreement on what it means.

And that is where AI comes in.

AI makes the problem much bigger

Consider that question again:

“What was our revenue last month?”

A human data analyst who lacks sufficient context can ask follow-up questions:

An analyst can also recognize when a result seems strange. If revenue is normally around five million and the query suddenly returns 28 million, that will probably set off alarm bells.

An AI agent does not automatically have that intuition.

It can find a table with a Revenue column, join it to another table, generate a plausible query, and confidently present the wrong answer.

Maybe the join is wrong. Maybe it uses bookings instead of revenue. Maybe every order line is counted three times. Maybe it is unaware of an exception from Finance.

The answer can still look excellent, which makes this more dangerous than a standard error message.

The challenge is no longer making data discoverable

Over the past twenty years, we have invested enormous effort in making data accessible.

Cloud data warehouses, lakehouses, APIs, ELT, notebooks, and self-service BI have made it increasingly easy to access data from a technical perspective.

Generative AI takes this a step further. Soon, users may not even need to know where the data is stored. They can simply ask a question. This shifts the problem. The question is no longer just:

“Can AI access our data?”

The more important question becomes:

“Does AI know how our organization interprets that data?”

That is where the semantic layer comes back into play.

The semantic model as a contract

I find it useful to think of a good semantic model as a kind of contract. It defines:

Technically, such a model can consist of measures, dimensions, relationships, calculated fields, hierarchies, metadata, and security rules, but functionally it does something more important. It captures part of the business language in a form that software can use. Until recently, dashboards were the primary consumers of that contract. Now, an entirely new type of consumer is emerging: the AI agent.

Microsoft is already explicitly building toward this

Microsoft Fabric clearly shows where this development is heading. Fabric Data Agents can answer questions about different types of enterprise data, including warehouses, lakehouses, and Power BI semantic models.

Microsoft has even published separate guidelines for making Power BI semantic models AI-ready. In these guidelines, Microsoft emphasizes the importance of clear names, descriptions, correct relationships, and reducing ambiguity in the model, among other things. According to Microsoft, the quality of a Data Agent’s answers depends heavily on how well the data sources and semantic models it uses have been prepared.

That is telling.

For years, we often viewed metadata as documentation—something we should really maintain, but rarely have enough time for in practice. For AI, metadata shifts from documentation to “runtime context.” A measure’s description is then useful not only to the next developer. An agent actually uses that description to determine what the measure means and when it should be applied.

And then MCP enters the picture

Microsoft also supports using a Fabric Data Agent as a Model Context Protocol server, which is currently still in preview. Through MCP, such an agent can make its data and query capabilities available to external AI systems.

MCP is a standard that allows AI applications to discover and use tools, context, and data sources in a consistent way. The interesting part is not so much MCP itself. Perhaps MCP will be replaced by something better in a few years. What is interesting is the architectural principle behind it.

The application where someone asks a question no longer needs to be the same application where the business logic is managed. An AI assistant can run elsewhere and still access a governed data or analytics layer. This suddenly makes the semantic layer much more than the backend of a dashboard.

It becomes a service.

Qlik is moving in the same direction

Qlik is now doing something similar.

Qlik has made its MCP Server generally available and uses it to give external AI assistants access to Qlik’s analytics capabilities and governed data products. This allows the underlying Analytics Engine and existing business logic to be used without requiring the end user to work in Qlik itself.

That is an interesting development. A traditional discussion would be:

“Do we use Qlik or Power BI?”

But with this architecture, you can ask a different question:

“Where do we manage the trusted analytical context that our users and agents need?”

For example, an organization could use Power BI as its primary reporting tool while certain governed data or analytical logic is managed elsewhere.

Or an AI assistant could access Qlik without the user ever opening a Qlik dashboard. That makes platform boundaries less clear-cut.

TimeXtender perhaps makes the idea even more explicit

TimeXtender has explicitly built its MCP architecture around “governed semantic models for AI agents.”

In this approach, the semantic model is presented to an AI client as a contract. Among other things, the model describes entities, relationships, metrics, hierarchies, and relevant context. As a result, the AI does not need to infer what the business means from a technical database schema.

TimeXtender describes the problem well: without this context, an AI system may select a field that sounds logical, miss an exception rule, or create a join that is technically valid but wrong in business terms.

And that actually brings us back to the BusinessObjects Universe. Once again, we are placing a business-friendly layer between the physical data and the consumer. But this time, the consumer is not necessarily a reporting user. It can also be software.

One semantic layer, multiple consumers

I see that as the fundamental shift. For a long time, we viewed a semantic model as something tied to a BI tool. A Power BI semantic model belongs with Power BI reports. A Qlik model or Master Items belong with Qlik visualizations. A Universe belongs with Web Intelligence (or Deski).

But imagine an architecture in which the same governed business logic is used by:

• Dashboards;
• Excel;
• Operational applications;
• APIs;
• Copilots;
• Chat interfaces;
• AI agents;
• Autonomous processes.

That considerably changes the economic value of the semantic layer. The dashboard becomes one of its potential users, rather than necessarily being the end product around which everything is built.

AI makes good modeling more important, not obsolete

There is also an opposing line of thought. If AI can write queries itself, why should we still spend so much time on models, measures, and business logic? Can’t the model simply figure that out?

Technically, it increasingly can, but from a business perspective, that is exactly what you do not want.

The easier it becomes to query any data, the more important a reliable semantic layer becomes.

Ten employees looking at the same dashboard at least see the same revenue. Give each of those same ten employees an AI agent that independently generates SQL against a complex data warehouse, and you may suddenly get ten different answers.

AI democratizes access to data. Without governance, it also democratizes the ability to produce different versions of the truth at scale. That makes well-modeled and governed semantics more important than ever.

This also changes the work of BI teams

If this development continues, some of the work of analytics teams will shift. Today, BI teams still receive many requests like:

When users can use AI to ask their own follow-up questions, some of that work will likely disappear. But that does not mean the work itself will disappear. Someone will still need to determine:

• What KPI definitions mean exactly;
• Where the official definition is maintained;
• Which relationships are correct;
• Which data is reliable;
• Which exceptions apply;
• Which information someone is allowed to use;
• Which models are authoritative;
• How changes are tested;
• How lineage and ownership are documented.

The value shifts from visualizing every question to structuring meaning people can trust. For data and analytics professionals, that strikes me as a healthy development. Although we should be honest: documenting definitions and maintaining metadata is usually a little less fun than building a polished visualization.

And our semantic models are often far from ready for that

There is just one problem. Many existing semantic models were designed for human developers.

A Power BI developer may know exactly what a measure named [NS Adj LY %] means. An AI agent does not.

A Qlik developer knows why a particular set analysis expression applies an unusual selection. An agent that only sees the end result has no idea why.

As a result, things we once easily considered “nice to have” become important for AI-ready semantic models.

These are not exotic AI techniques. They are largely the same disciplines we have always needed for good BI. AI simply raises the cost of carelessness.

From semantic layer to business infrastructure

That is why I believe we need to rethink how we view semantic models. Not as a technical component of Power BI. Not as something that exists only in Qlik apps. Not as an additional modeling tool layered on top of the data warehouse.

A well-designed semantic layer is essentially a machine-readable description of how an organization views its own data.

That is a valuable business asset. Perhaps even more valuable than many of the dashboards built on top of it. Dashboards come and go, but the definitions of revenue, customer, margin, inventory, occupancy, or churn should be much more stable. When that meaning is properly managed, more and more applications can connect to it. Power BI today, a Copilot tomorrow, and the day after that, an agent that automatically investigates anomalies or suggests actions.

We’re almost back to the Universe, but not quite

There is something ironic about this development. After twenty years of innovation, we are partly returning to an idea that BusinessObjects introduced a long time ago:

Put a semantic layer between the technical data and whoever wants to use it.

But we are not simply back where we started. The first generation of semantic layers was primarily intended to make it easier for people to build reports. The new generation needs to work for both people and machines.

And that brings different requirements.

The semantic layer needs better documentation, must be programmable and accessible through standardized interfaces, and must provide sufficient governance for automated systems to work with it. That is fundamentally different.

So don’t start with the chatbot

Many organizations looking to experiment with AI and data understandably start with the visible technology. Which LLM will we use? Microsoft Copilot? ChatGPT? Claude? Our own agent? Which vector database? Do we need MCP?

If the goal is to get reliable answers about your own business operations, I would start by asking a different question:

Where have we actually defined what our data means?

Where is the official revenue definition? Which customer classification is authoritative? Where does the gross margin logic reside? Are those definitions known only to a few experienced developers? Are they scattered across SQL, Power BI, Qlik, and Excel? Or do they actually exist as reusable, governed business logic?

If the answer is unclear, your primary problem is not yet an AI problem. It is a semantic layer problem. AI simply makes that problem suddenly very visible.

The semantic layer is becoming business infrastructure

Dashboards are not going away. For many forms of communication, a purpose-built visualization simply remains better than a chat window. But the dashboard is increasingly becoming less of the sole destination of our data architecture. The same business context can soon be used by reports, applications, and AI agents.

This turns the semantic layer from a component of the BI stack into part of the company’s infrastructure. A place where we define not only where the data is located, but, more importantly, what the data means. And once machines start using that meaning directly, the semantic model takes on an entirely new role: it becomes the API through which AI learns to understand your organization.

Is your data foundation ready for AI?

Becoming AI-ready does not start with choosing a language model. It starts with reliable data, clear definitions, and well-governed business logic.

Want to know whether your current data architecture, semantic models, and governance are ready? With our AI Readiness Assessment, we identify the most important gaps and the steps needed to enable AI to work reliably with business data.

Barry Harmsen

Barry is the founder of Bitmetric. He has worked in Data & Analytics for more than twenty years, in roles ranging from hands-on development to architecture and strategy. He favors solutions that fit the organization’s context and that people actually use. A long time ago, he wrote QlikView for Developers.

Outside work, Barry spends his time with his family, rowing, doing DIY projects, and pursuing hobby projects that his family is enthusiastic about to varying degrees.

The post Your semantic layer is becoming the API for AI appeared first on Bitmetric.

It really can work. Anthropic recently published an article explaining how they built this internally: 95% of all internal analytics questions automated, with approximately 95% accuracy. Interestingly, a controlled experiment at a medical clinic reached almost exactly the same conclusions. But what went wrong along the way is at least as instructive.

So the question is not just whether your AI tool is good enough, but more importantly: is your data ready for AI?

The real problem is not the technology

The core problem with analytics agents is not writing queries. It is correctly matching a question to the right table, the right definition, and the right filter.

“How many active users did we have last month?” sounds simple. But an agent needs to know which table you mean, what “active” means in your context, which time window you use, and whether certain user groups should be excluded. If any of that is unclear, the agent will provide an answer that is technically correct but substantively wrong. And no one notices, because it looks perfectly normal.

A concrete example: a field named slot_status with the values Open and Filled. The agent is asked about available slots, searches for slot_status = 'Available'—a value that does not exist—and neatly returns zero results. No error message. No indication that anything went wrong. An experienced analyst would probably have checked which values actually occur first.

What doesn’t work, but is still widely attempted

Automatically deriving definitions

Have an LLM automatically generate your data catalog from your tables and query logs. Many tooling vendors are actively building this into their solutions right now.

Anthropic tried it. It didn’t work. Automatically generated definitions look complete, but they encode exactly the ambiguity you are trying to eliminate. The difference is in the details. An automatically generated description says:

“The status of the order.”

A useful description says:

“The lifecycle status of the order. Use this field for revenue analysis. Do not use this field to determine whether inventory has been reserved; use allocation_status for that.”

The first description identifies the field. The second teaches the agent how the domain works. Use AI to draft documentation, but have a person establish the definition.

Providing thousands of reference queries

Anthropic gave the agent access to thousands of historical SQL files. Accuracy barely improved. In 80% of the cases where the agent was wrong, the correct answer was already in those queries. It just couldn’t find it. The bottleneck was not access to data, but structure.

Choosing a better or more expensive model

In the experiment at the medical clinic, the model was never changed. Accuracy rose from 0% to 92% purely through better context. The model is rarely the bottleneck.

All three cases revealed the same problem: the agent did not need more information, but better information and structure.

What does work

A solid data foundation

Not fifty tables that all have something to do with “revenue,” but one place that everyone knows is the source. Clear ownership, documented definitions, and explicit decisions about what is and is not included. This is not a new lesson: it is exactly what you also need for reliable dashboards. An AI agent simply makes it more obvious when something is wrong.

Is AI part of a broader effort to develop your data environment? A data strategy helps you address architecture, ownership, definitions, and priorities as a whole.

The instruction layer that makes the difference

A semantic layer helps. In Power BI, it is explicitly part of the semantic model. On other platforms, the same principle exists under different names, such as curated datasets, business logic, and centralized definitions. That resolves ambiguity at the metric level. But an agent needs more: it must know which data sources to consult, what the pitfalls are, and how to clarify a vague question. That context is not part of your semantic model.

Anthropic builds that context into manually created instruction documents that it calls “skills.” ChatGPT has the same concept under the name “GPTs,” while Gemini calls them “gems.” Without that layer, its agent achieved only 21% correct answers. With well-designed skills: above 95%.

The knowledge these documents need to contain is domain expertise that cannot simply be written down. It resides in the minds of the people who have worked with the data for years: why a particular table exists, which filters always apply, and which exceptions were once built in after a painful mistake. These people are not the data engineers, but the analysts and domain experts. They are also the only ones who can assess whether an answer is substantively correct; domain expertise is the real differentiator.

The agent is never finished

Anthropic saw accuracy fall from 95% to 65% within one month after it stopped maintaining the agent. There are two reasons for this. Tables are renamed, definitions shift, new sources are added, and the context an analytics agent relies on changes constantly, so the instruction documents gradually become inaccurate. But it also works the other way around: you fix a bug in your data model or add a better filter, while the workaround you documented earlier remains in place. The agent then applies it unnecessarily or does something that is now actually wrong.

Anthropic sees the same pattern found in every data project: the build gets attention and budget, but subsequent maintenance does not. With a dashboard, you notice when someone complains that the figures are incorrect. With an AI agent, nobody notices because it simply keeps providing answers.

Where do you start?

A handful of well-documented datasets, a few dozen test cases, and a simple instruction layer already deliver most of the gains. But first, answer three questions honestly: is your data model documented well enough for an agent to navigate it without guidance? Is someone responsible for maintaining the instruction documents when something changes? And do you have domain experts who are willing to write down their knowledge and can assess whether the answers are correct?

If the answer to any of those questions is “not really,” that is no reason to stop. But it is a reason to improve your data foundation first.

Want to know whether your data is ready for AI?

In our AI readiness assessment, we review your data models, definitions, documentation, and ownership. Afterward, you will know where you stand, what is already usable, and what needs to happen first.

Barry Harmsen

Barry is the founder of Bitmetric. He has worked in Data & Analytics for more than twenty years, in roles ranging from hands-on development to architecture and strategy. He likes solutions that fit the organization’s context and that people actually use. A long time ago, he wrote QlikView for Developers.

Outside work, Barry spends his time with his family, rowing, doing DIY projects, and working on hobby projects that his family is enthusiastic about to varying degrees.

The post Putting AI to work on your data works. But not like this. appeared first on Bitmetric.

License costs are rising—not with just one vendor, but across the market. According to research by Zylo, 79 percent of IT leaders now face price increases at renewal. Vertice puts SaaS inflation in the first quarter of 2026 at over 13 percent, nearly two percentage points higher than a year earlier.

You feel it most when you receive a renewal proposal that looks markedly different from the last one.

So what do you do? You have a few options.

Simply renew

You can sign. It works, and continuity is assured. Sometimes that is simply the right choice.

Negotiate

You can negotiate. A renewal is not a foregone conclusion. There may be room to negotiate, especially if you have a partner who knows the vendor and can handle the discussion effectively. It does not always lead to an adjustment, but if you do not ask, the answer is always no.

Review the contract model

You can review the contract model. Most platforms offer several options, and the combination that worked two years ago may no longer be right today. We recently saved a large Dutch representative body more than 30 percent by migrating it from on-premises to the cloud. It was a logical step it had wanted to take for some time, with a welcome side effect on the invoice. That does not even include the hardware savings.

Switch platforms

Sometimes the conclusion is that another platform is a better fit. An independent BI tool selection lets you compare the options based on usage, functionality, costs, architecture, and management. Switching is not always easy, but with the right guidance, it does not have to be a leap into the unknown. We are currently going through exactly that process with several clients.

But there is another question that I find at least as interesting.

Does the platform still align with where you want to go?

Vendors continuously add functionality, which partly justifies changes in pricing. In our experience, however, many organizations use only a fraction of what is available. That means you are not only paying more, but also failing to make full use of what you already have. This is especially true of the AI capabilities added to almost every platform in recent years.

A renewal is therefore not just a time to look at the invoice. It is also a time to assess whether your analytics environment still fits your organization’s needs—not what was purchased two years ago, but what you actually want now.

Would you like an independent assessment of the renewal proposal and your current direction? A Second Opinion Data & Analytics gives you insight into what is sound, where the risks lie, and which alternatives are realistic.

Sometimes renewing makes sense. Sometimes optimization is enough. And sometimes switching is the wiser choice.

Would you like to discuss your upcoming renewal, or more broadly how your Data & Analytics platform aligns with your organization? Schedule a call with us.

Eric van Gils

Eric is Commercial Director at Bitmetric and has worked in IT for more than 20 years, most of that time in data and Business Intelligence.

During that time, he has seen one thing again and again: organizations are not looking for attractive dashboards; they want answers to questions that truly matter. Clearly defining those questions is often the hardest part.

His guiding principle: “If you don’t know what to ask, you’ll never get the right answer.” Eric helps clients discover what they really want to know and ensures that Bitmetric delivers the solutions that make this possible.

The post Your analytics contract is expiring. Look beyond the invoice. appeared first on Bitmetric.

We took a look. What we found was an environment without a single line of documentation. There were dozens of apps, some of them nearly identical copies with only minor differences. No one knew why they existed or which one was correct. There was no architecture documentation and no version control. Year after year, changes had been made directly in production—patch upon patch—until whatever structure may once have existed had disappeared completely. The environment was running, but it was hanging by a thread.

This is the scenario many organizations fear but rarely take active steps to prevent: dependence on one person and a vulnerability that only becomes visible when that person leaves.

I have seen this pattern recur in Qlik environments for almost twenty years. In this guide, I explain what effective Qlik management looks like, what goes wrong without structured maintenance, how proactive work differs from reactive fixes, and when it is better to bring in a partner than to handle it yourself.

In short: Qlik environments grow on their own. Manageability does not. Without structured maintenance, technical debt accumulates more quietly than you might think, until a departure, migration, or release exposes it. Proactive management keeps your environment usable and ensures that every change remains manageable instead of becoming increasingly burdensome.

Table of Contents

• What are Qlik support and management?

• What goes wrong without management?

• Proactive vs. reactive: the difference in practice

• Qlik Cloud vs. on-premises: what changes?

• Governance: how do you stay in control as the environment grows?

• Performance: where are the real bottlenecks?

• When should you bring in a support partner?

• What should Qlik support cost, and what value does it deliver?

• Frequently Asked Questions

What are Qlik support and management?

Qlik management is about more than calling a help desk when something breaks. It covers everything needed to keep a Qlik environment healthy, manageable, and reliable: monitoring environment health, app maintenance, governance, release analysis, performance reviews, and user management.

That is fundamentally different from generic IT support. An IT generalist resolving a ticket does not have the expertise to diagnose a silent error in an incremental load routine. Nor can they assess whether a new Qlik Cloud feature release affects the custom extensions you use, the visualizations that have been phased out, or the API integrations that depend on your environment.

The distinction I always make is:

Reactive management: you resolve problems after they become visible. Users report that a dashboard is inaccurate. You investigate, fix it, and wait for the next report.

Proactive management: you monitor, analyze, and maintain the environment systematically, preventing problems from occurring—or at least from coming as a complete surprise.

That sounds logical. In practice, many organizations still choose the first approach, simply because it feels more tangible: you pay for what is broken, not for what does not break. The irony is that reactive management is consistently more expensive. Not on the monthly invoice, but in the cumulative cost of incidents, recovery time, and the technical debt that builds up step by step.

What goes wrong when you neglect Qlik management?

Based on the environments we have encountered over the past few years, we see the same problems recurring. Not always all seven at once, but rarely fewer than three.

1. An (incremental) load that silently fails

A QVD load routine runs every night but has not loaded fresh data for weeks. The error message disappears into a log file that nobody reads. Users see data from three weeks ago as “current.” This is one of the most dangerous problems because it remains invisible until someone compares the figures with another source.

These kinds of errors can be completely prevented with a simple monitoring alert. But someone has to configure that alert first.

2. Knowledge that leaves with your people

The architect who built the data models has left. What he built works, but no one knows why it was set up that way. There is no documentation, no comments in the scripts, and no architecture description. Every change is now a gamble because you do not know what you can touch without breaking something else.

The example from the introduction is the extreme case. But I see a milder version in almost every new client environment.

3. Hardcoded reference data

Product categories, cost centers, region codes: hardcoded in the script or loaded from an Excel file maintained by a single colleague. That colleague has left. The Excel file is somewhere on a shared drive. Or perhaps it is no longer there.

This sounds trivial until the organization restructures and the cost center codes change. Then you discover that thirteen apps each contain their own version of that table.

4. Uncontrolled growth of apps and sheets

I call this Qlik sprawl, after the familiar spreadsheet sprawl: the same uncontrolled growth, but now in apps and sheets instead of Excel files. It starts with apps: at some point, every department has its own report built. But with the arrival of self-service analytics, it goes further: anyone can create sheets, duplicate visualizations, and save their own versions. That is an advantage of the platform. The problem is that no one ever cleans up.

The result is an environment full of overlapping apps and sheets, with slightly different definitions of the same concepts. “Revenue” in the financial dashboard is calculated differently from “revenue” in the sales dashboard. And no one knows which version is correct anymore, or which sheets are still actively used.

5. Silent changes in source data

The data source changes. A field gets a new value. A table is renamed. A new option is added to a drop-down list. Qlik does not display an error: the data simply loads, but the results are no longer correct.

This is more insidious than a hard error. A hard error is noticeable. A silent discrepancy can go unnoticed for weeks or months, until someone compares the figures with an external source.

6. Missing documentation

The environment is running. But why a specific data model is structured the way it is, which decisions were made when configuring spaces, and who has access to which data source and why: none of this is documented. With every change, you have to figure it out all over again, and mistakes happen because you lack the context.

7. Governance gaps: access and user management

Who has access to which data? Is that access still appropriate after the latest reorganization? Do any users have overly broad permissions? And, perhaps more urgently, do former employees still have active accounts in the environment?

User management is an aspect of governance that is often overlooked. People who change roles, move to another department, or leave the company are not always removed from Qlik. This is not only inefficient; it also creates a compliance risk.

Proactive vs. reactive: the difference in practice

Proactive Qlik management consists of a set of specific activities that you perform systematically, regardless of whether anything is currently broken. It follows a clear schedule.

To illustrate, this is how we approach it at Bitmetric, organized by frequency.

Continuously and when incidents occur

Handling support requests, investigating errors in apps and reloads, supporting data sources and automations, escalating platform issues to Qlik Support when necessary, and restoring objects from backup.

Weekly

Identifying new apps, spaces, data connections, automations, and tasks. Reviewing changes to access permissions and licenses. Analyzing recurring reload and automation errors. Reviewing open support tickets.

Monthly

Analyzing usage and configuration with the Qlik Analyzers: App Analyzer, Reload Analyzer, Data Connection Analyzer, and Entitlement Analyzer. Checking whether apps comply with tenant standards. Cataloging unused apps, spaces, alerts, subscriptions, automations, data connections, and tasks. Reporting on incidents, findings, and areas for improvement.

Quarterly

Reviewing extensions and themes for usage and necessity. Analyzing app and sheet adoption. Identifying unused sheets. Optimizing reload schedules and batch windows. Assessing QVD performance. Discussing recurring support findings and prioritizing improvement proposals.

Annually

Assess the tenant architecture. Evaluate scalability in relation to users, apps, and data volume. Review governance, roles, and responsibilities. Reassess licensing and capacity requirements. Update the disaster recovery plan and practice the recovery procedure, including a restore test using the Qlik Cloud backup.

This is what proactive management means in practice. No vague promises about “proactively helping you think ahead,” but a structured approach with a cadence that suits the nature of the platform.

Qlik Cloud vs. on-premises: what changes in management?

A common assumption is that Qlik Cloud is SaaS, so the vendor handles its management. That is partly true. The infrastructure is indeed Qlik’s responsibility: servers, availability, and updates to the core software.

But managing the environment is still your responsibility.

Moreover, Qlik Cloud Analytics is a considerably richer platform than Qlik Sense on-premises ever was. Every feature you use also requires management. Qlik Automate introduces automations that can fail and need to be monitored. Reporting introduces subscriptions and distribution schedules that need to be maintained. Qlik Predict introduces AutoML deployments with their own life cycles. And then there are API integrations and third-party connectors.

In my experience, Qlik Cloud shifts the management burden but does not reduce it. Responsibility for the infrastructure disappears, but it is replaced by a broader functional scope that must be actively managed.

Other key differences:

Release cadence

Qlik Cloud publishes weekly feature releases, generally on Tuesdays, in addition to ongoing technical updates. That is significantly more frequent than the semiannual releases of on-premises Qlik Sense. Each release can affect existing apps, visualizations that have been phased out, or extensions that are no longer supported. Proactive release impact analysis is therefore not a luxury but an ongoing management activity.

Data Gateway

On-premises, the data was located close to the Qlik server. With Qlik Cloud, you need a Data Gateway to access on-premises data sources. That gateway has its own life cycle and requires monitoring and maintenance.

Backup and recovery

On-premises, the Qlik environment was often simply included in existing server backups: the file system, QVDs, and the repository database. Qlik Cloud recently introduced soft delete for apps: a deleted app can be recovered for up to fourteen days. This does not apply to configurations and other artifacts, which are lost immediately after deletion. This shifts most of the responsibility for a comprehensive backup and recovery strategy to you or to the provider managing the environment for you. If you do not want to depend on manual exports and separate recovery procedures, our Backup for Qlik Cloud service provides daily managed backups of apps, configurations and tenant metadata, with long-term retention and recovery support.

A good backup also includes more than just app files. It should also cover configurations, connections, automations, permissions, and other metadata needed to reconstruct the environment. Read more about what a good Qlik Cloud backup should include.

For organizations considering a move to Qlik Cloud: plan for a management transition, not just a technical migration.

Considering a move to Qlik Cloud? Read our guide to Qlik Cloud migration or explore our Qlik Consulting service for guidance throughout the process.

Governance: how do you maintain control as the environment grows?

Governance in Qlik concerns who is allowed to view, modify, and publish what; who is responsible for data quality; and whether all of this is properly embedded in the environment’s configuration. In an environment with five users and ten apps, you can manage this informally. With fifty users and a hundred apps, that is no longer responsible.

But governance is not a standard formula that you apply the same way everywhere.

The right governance setup depends on several factors: who develops solutions and for whom, who uses the environment and at what level, who owns the data and who owns the analytics, how mature the data culture is, and how sensitive the data is. Company-wide financial data requires stricter governance than a local marketing analysis.

Four patterns, increasing in complexity

In practice, I distinguish four common patterns:

Personal BI
The creator answers their own questions. Little or no sharing, and no formal publishing. Flexible and informal. Works well for individuals, but does not scale.

Team BI
A group of colleagues shares analyses in a shared environment. Developers are often subject-matter experts who provide access to their own data. Processes are informal, but the approach works for the group.

Departmental BI
A small team within the department builds analytics for all users in that department. Quality standards are higher, and publishing is more formal. This is where lifecycle management becomes important: users are not intimately familiar with the apps, so the apps need to speak for themselves.

Enterprise BI
A central team, often a CoE (Center of Excellence) or BICC (Business Intelligence Competency Center), is responsible for all analytics. It has a high level of technical expertise, formal processes for requirements and delivery, and mandatory lifecycle management. It is often also responsible for providing self-service datasets for departmental and team BI.

The dominant pattern in your organization determines the governance structure you need. But an organization does not have to operate at the same level everywhere. Some departments work well with Team BI, while the finance department requires Enterprise BI governance.

Who manages what: data and analytics

A second dimension is how responsibilities are divided between the business and IT.

In a fully decentralized model, the business manages both the data and the analytics. It is flexible, but difficult to scale and sustain.

In a “middle-out” model, IT manages the data layer and the business manages the analytics. This provides a good balance between governance and self-service and is a commonly chosen approach in practice.

In a fully centralized model, IT or a CoE manages everything. This provides tighter governance and more control, but also less flexibility for the business and greater dependence on the central team.

The best-fit model depends on the organization’s size, data culture, data sensitivity, and the capacity of both IT and the business.

One warning

Overly strict governance is counterproductive. If you regulate self-service out of existence, people will work around the system. Excel, their own tools, shadow IT. The environment you carefully control is bypassed by a shadow environment you cannot see. Choose a baseline that fits the dominant patterns in your organization, and allow room for exceptions where they make sense.

Practical governance elements

Regardless of the chosen pattern, several elements are always relevant:

• Space structure: a clear structure with clearly defined ownership for each space

• Access model (RBAC, Role-Based Access Control): documented, reviewed periodically, and updated after personnel changes

• Data ownership: every dataset has an owner in the business, not in IT

• Section Access: for row-level security, but only robust if the logic remains up to date after organizational changes

• Change management: who is allowed to change what in production, and through which process

Governance is not a one-time project. It is an ongoing process that requires consistent maintenance.

Governance starts with a clear data and analytics strategy. Read more about our Data Strategy service.

Performance: what is really causing the pain?

Performance issues in Qlik Cloud are almost never caused by the infrastructure. Qlik manages the servers, capacity is sufficient in most cases, and “Large Apps support” is rarely what you actually need.

The performance issues I encounter are almost always found in one of the following four layers. And they compound each other.

The data model

A poorly designed data model is the most common cause. Tables that are too wide and contain fields that are never used, redundant joins, unnecessary intermediate tables. The result: longer load times and a larger memory footprint.

But the real problem is the cascading effect: a poor data model forces developers to use workarounds in front-end expressions to produce the required calculations. Those workarounds slow down the app, leading to the assumption that more infrastructure is needed. Yet the solution lies in the data model.

The load script 

Scripts that have been expanded over the years without refactoring. Dead code, duplicate transformations, variables that no longer reference anything. Tasks that run sequentially even though they could easily run in parallel. And the most common issue: no incremental load for tables that could support one, meaning every reload fully reloads data that was largely already present.

Load processes and scheduling

Reload tasks that are not scheduled optimally. Dependencies that are not configured properly, causing one delayed task to trigger a chain of problems. Batch windows that are not aligned with the available capacity. This is operations work, not development work.

Front-end expressions

Inefficient Set Analysis expressions. Calculations that run again with every user interaction because the underlying data structure does not support them. Aggregations in visualizations that should actually be part of the data model.

The solution is the same in every case: periodic maintenance and review. Not hardware or a license upgrade, but someone who reviews it regularly and has enough technical knowledge to identify the cause.

If such a review shows that the data model, load script, or architecture needs to be structurally rebuilt, Qlik Consulting is the logical next step.

When should you engage a Qlik support partner?

Not every organization needs an external Qlik support partner. If you have a well-structured internal team with sufficient Qlik expertise and capacity for proactive maintenance, you can manage it perfectly well yourself.

But there are situations where outsourcing makes more sense than handling it yourself.

Signs that partner support is worthwhile

• No one internally has the in-depth Qlik knowledge needed to analyze release notes or diagnose data model issues
• The environment is too large for one person to keep up with alongside their day-to-day responsibilities
• A Qlik Cloud feature release has already caused unexpected issues in production
• A key person has left without transferring their knowledge
• You are preparing for a migration, an ERP change, or a major architecture change
• Analytics downtime has a direct impact on operational decisions

What to look for when choosing a partner

A good Qlik support partner does more than resolve tickets. Check whether they perform a release impact analysis for every update, whether they know your environment so they do not have to familiarize themselves with it each time, and whether they are willing to challenge you. If a partner always says yes and never pushes back, that is not a good sign.

Also be wary of partners whose attention wanes after the initial implementation. Support is the work that starts after implementation, not before. Always ask what specifically will be done in the first six months after go-live, and by whom.

Are you unsure not only about the support partner, but also about the current setup, management arrangements or proposed approach? A Second Opinion Data & Analytics provides an independent assessment of these choices.

How much should Qlik support cost, and what value does it deliver?

Much of the value of professional Qlik management lies in what does not happen: incidents that are prevented, releases that bring no surprises, and an environment that remains usable without each change requiring more effort than the last.

That last point may be the best indicator of management quality: the effort required to implement a change. In a well-managed environment, that effort remains stable. In a neglected environment, it increases with every addition, as technical debt and a lack of clarity about the existing structure make each step more difficult. Eventually, no one dares touch anything.

What determines the cost?

The price of a support contract depends on several factors: the size of the environment (apps, users, data volume), the complexity of the architecture (on-premises data sources, legacy integrations, custom extensions), the required SLA (incident response time, availability outside business hours), and whether proactive maintenance is included or only break-fix service.

At Bitmetric, proactive Qlik Cloud management starts at €950 per month.

Would you rather manage your Qlik Cloud environment yourself, but still be kept informed daily about risks and anomalies? With CloudScan for Qlik, you can do that from €125 per month per tenant.

A good partner clearly sets out the scope and cost in advance. Vague hourly-rate arrangements without a clear scope are a sign that you do not know what you are buying—or what the final bill will be. At Bitmetric, the Bitmetric Blueprint underpins our entire service offering, not just Qlik Cloud Analytics.

Frequently asked questions

Conclusion

Keeping a Qlik environment running well takes quite a bit of work. Unfortunately, that work is usually invisible: as long as everything is running smoothly, you do not notice it. That is precisely what makes it vulnerable—you only realize something was missing when it stops working.

Structured Qlik management does not guarantee that nothing will ever go wrong. It does guarantee that you will see issues coming sooner, respond faster, and be less affected by surprises that would otherwise build up unnoticed and surface in production.

The choice between in-house management and outsourcing depends on your expertise, capacity, and the complexity of your environment. Both can work. What does not work is avoiding the choice and hoping everything will keep running smoothly on its own.

Want to know where your Qlik environment currently stands? I would be happy to discuss it with you, with no obligation. Use the button below to schedule a call with me via Teams at a time that works for you.

Barry Harmsen

Barry is the founder of Bitmetric. He has worked in data & analytics for more than twenty years, in roles ranging from hands-on development to architecture and strategy. He favors solutions that fit the organization’s context and that people actually use. Barry was a Qlik Luminary and Qlik Partner Ambassador for many years. A long time ago, he wrote QlikView for Developers.

Outside work, Barry spends his time with his family, rowing, doing DIY projects, and working on hobby projects that his family is enthusiastic about to varying degrees.

The post Qlik Support & Management: The Complete Guide (2026) appeared first on Bitmetric.

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.

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.

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.”

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.

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.

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.

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.

Barry Harmsen

Barry is the founder of Bitmetric. He has worked in Data & Analytics for more than twenty years, in roles ranging from hands-on development to architecture and strategy. He favors solutions that fit an organization’s context and that people actually use. Barry was a Qlik Luminary and Qlik Partner Ambassador for many years. A long time ago, he wrote QlikView for Developers.

Outside work, Barry spends his time with his family, rowing, doing DIY projects, and working on hobby projects that receive varying levels of enthusiasm from his family.

The post Migrating to Qlik Cloud: The Complete Guide (2026) appeared first on Bitmetric.

But this question is much broader. We are hearing it more and more often:

We run on Qlik, but we are essentially a Microsoft organization. Shouldn’t we simply switch to Power BI?

The answer is not a simple yes or no. Qlik and Power BI are both mature analytics platforms. So switching does not automatically mean moving to something newer or better. You are choosing a platform that better fits your organization, people, and broader architecture. Or you may conclude that Qlik is still the best choice.

One thing is clear: this is not an export-import project. Organizations looking to replace Qlik with Power BI are therefore usually dealing with more than just a BI migration. There is no official solution from Microsoft or Qlik that directly converts an entire Qlik app into a production-ready Power BI solution. Microsoft has published a general approach to Power BI migrations, but it is not specifically focused on Qlik.

This article covers when switching makes sense, what changes fundamentally, and how to approach the process. We also discuss when it is better to stay with Qlik.

Considering staying with Qlik but want to move to the cloud? Read our Qlik Cloud migration guide.

Want to find out how well prepared you are for a move to Power BI or Microsoft Fabric? Use our Qlik to Power BI Migration Readiness Checklist with 85 concrete checkpoints.

In short
Moving from Qlik to Power BI or Microsoft Fabric can be a logical choice, especially if your organization is heavily invested in Microsoft. But it is a rebuild, not a move. Qlik apps, load scripts, and data models are not converted automatically. You can reuse business logic and KPI definitions, but they must be reimplemented. You should also first determine whether you only want to replace the reporting layer or the underlying data architecture as well. After all, Power BI and Microsoft Fabric are not the same.

Most problems in projects like these do not arise because a platform falls short, but because the scope of the rebuild is underestimated: hidden dependencies, logic that cannot be translated one-to-one, or a parallel run that is too short. This article systematically examines those risks using an assessment framework (Retain, Rebuild, Retire) and a phased approach, so you know where the complexity lies in advance rather than discovering it afterward.

Short on time? Go directly to:
– When switching to Power BI does or does not make sense
– The six phases of a Qlik-to-Power BI migration
– Common mistakes in a Qlik-to-Power BI migration

Table of contents

• Considering a switch? Start with these three questions

• When is switching to Power BI or Fabric the right choice?

• Do you only need Power BI, or do you also need Microsoft Fabric?

• What changes fundamentally?

• What can you take with you, and what can’t you?

• The migration approach in practice

• Common mistakes when migrating from Qlik to Power BI

• Frequently asked questions

Considering a switch? Start with these three questions

Whether you want to migrate QlikView or Qlik Sense to Power BI, the same fundamental question applies: what should you retain, what should you rebuild, and what can you retire? Before comparing licenses or creating a project plan, you need to answer three questions:

1. Which Qlik apps and QVDs are actually being used?
   
   
2. Do you only want to replace Qlik as a reporting tool, or also modernize the underlying data layer?
   
   
3. Which functionality and approaches to analysis must be retained during the switch?
   
   

The answers will determine whether you only need Power BI, should explore Microsoft Fabric, or would be better off staying with Qlik.

Is the platform choice part of a broader change to your data environment? A data strategy can help you define the desired future state and the transition path first.

When is switching to Power BI or Fabric the right choice?

A switch is particularly worth exploring if your organization relies heavily on Microsoft and the current Qlik environment is increasingly seen as a separate platform.

Signs that a switch may make sense:

• Your IT environment runs largely on Azure, Microsoft 365, and Entra ID.
• Your information needs mainly involve standardized reporting, guided analytics, and self-service on top of managed data models.
• Power BI is already included in your Microsoft licenses.
• The use of Qlik has declined since in-house Qlik specialists left.
• You want to reduce the number of separate platforms and vendors.
• The costs and management effort required for Qlik are no longer justified by its actual use.
• You want to integrate analytics more closely with other Microsoft services.

Having Power BI available under an existing license can make the business case more attractive. But licensing alone should never be the deciding factor. Rebuilding, testing, and implementing an analytics environment usually costs considerably more than the difference in user license costs.

The question “which platform is technically better?” is rarely the most important one. Both platforms can deliver effective dashboards, reports, and data models.

The more relevant question is:

Which platform best fits our organization’s people, processes, and architecture?

Not sure which platform is right for your organization? Read how we can help with BI tool selection.

When is switching not the right choice?

There are also situations where deliberately staying with Qlik may be the better choice.

The associative model is essential for users

Qlik excels in environments where users freely navigate large, combined datasets. Selections and excluded values are immediately visible. Users can follow relationships without every analytical path having to be predefined in a report.

Power BI also supports interactive analysis and self-service. However, it works from a more explicitly designed semantic model and report structure. Analytical questions that arise naturally from associations in Qlik sometimes require additional modeling, measures, or a different mode of interaction in Power BI.

If this freedom to explore is central to daily use, you could lose something essential by switching.

You only want to modernize because Power BI is supposedly newer

Qlik Sense and Power BI belong to the same generation of analytics platforms. At the reporting level, switching between the two is primarily a lateral move.

If you are still using QlikView, switching can be part of a broader modernization effort. But even then, you have several options. You can move to Qlik Cloud, Power BI, or a broader Microsoft Fabric architecture.

Modernization does not automatically come from the logo on the dashboard. It includes areas such as:

• Data architecture;
• Automation and deployment;
• Governance;
• Manageability;
• Integration with other platforms;
• Availability of expertise;
• Usage and adoption.

Qlik is demonstrably a better fit for your users

If Qlik is widely used, well managed internally, and demonstrably delivers value, “we are a Microsoft organization” is not, by itself, a good reason to migrate.

A single ecosystem is easier to manage. But standardization that harms functionality, productivity, or user acceptance is not progress.

You want to solve data or dashboard problems through a migration

“My data is inaccurate” and “I do not like the look of my dashboards” are understandable complaints, but they are not, by themselves, good reasons to replace Qlik.

Unreliable figures usually result from problems with data sources, definitions, transformations, the data model, or how results are validated. A different BI platform does not automatically solve those problems. They can even become more serious during a migration because existing logic must be reinterpreted and rebuilt.

The same applies to dashboard design. Good reports require clear design principles, consistent standards, and developers who understand how users process information. Without that expertise, a dashboard in Power BI will not automatically be better than a dashboard in Qlik.

First, investigate where the problem really lies. Only switch when the platform itself is demonstrably getting in the way. Unsure whether the platform is really the problem? A Second Opinion Data & Analytics provides an independent assessment of your existing environment or migration proposal.

Your organization is not currently equipped to carry out the rebuild properly

A transition requires more than Power BI licenses and a few developers. You need time for assessment, architecture decisions, rebuilding, testing, and adoption.

If the organization currently lacks sufficient capacity, ownership, or budget, postponing the move may be wiser than completing only half the migration.

That does not mean you have to stay with Qlik forever. It means the prerequisites need to be in place first.

If you decide to stay with Qlik, read our Qlik Support & Management guide on proactively managing a Qlik environment. If you want ongoing support with management or to outsource part of it, explore our Qlik Support service.

Do you only need Power BI, or Microsoft Fabric as well?

Power BI and Microsoft Fabric are often mentioned in the same breath, but they are not the same.

Power BI focuses on semantic models, reporting, visualization, and analysis. Microsoft Fabric is a broader analytics platform that brings together data integration, data engineering, data warehousing, real-time analytics, data science, and Power BI, among other capabilities.

Power BI is one of the workloads within Fabric.

That distinction is important for the scope of your migration. 

When Power BI can suffice without a new Fabric data layer

Power BI can be a deliberate end state if:

• You already have a well-functioning data warehouse or data platform;
• Data sources are available through existing, managed models;
• You primarily want to replace the Qlik reporting layer;
• You do not need a new data engineering environment;
• Existing ETL processes can remain operational;
• You primarily use Power BI for semantic models, dashboards, and reporting.

So you do not automatically need to move your entire data architecture to Fabric just because you are going to use Power BI.

When Microsoft Fabric becomes relevant

Fabric is worth considering if you want to modernize more than just reporting:

• Data storage and access;
• ETL and ELT processes;
• Pipelines and orchestration;
• Data warehousing or a lakehouse;
• Data science;
• Real-time analytics;
• Centralized governance across multiple analytics workloads.

If Fabric becomes part of the target architecture, our Microsoft Fabric consulting work typically focuses on designing and implementing that broader data platform layer.

For example, a Fabric lakehouse can serve a similar role to a curated QVD layer. But it is not the only possible destination.

You can also:

• Retain an existing data warehouse;
• Use Azure SQL or another cloud data warehouse;
• Continue using existing ETL processes;
• Use an external data integration platform;
• Replace only the reporting layer.

So the right question is not simply:

Do we need Power BI or Fabric?

A better question is:

Which parts of our current analytics architecture do we want to replace?

Only once that is clear can you choose an appropriate target architecture.

Account for shared capacity in Fabric

Fabric capacity is not a monthly bundle that suddenly runs out at a certain point. Different workloads consume Capacity Units. Microsoft smooths peak usage over time.

However, sustained overload can lead to throttling. Operations may then be delayed, queued, or ultimately rejected.

Before you begin, map out:

• Which workloads share the same capacity;
• When peak loads occur;
• How often models and pipelines run;
• How many concurrent users you expect;
• Which processes are business-critical;
• What growth you expect in the coming years.

Do not focus only on the capacity you need at launch. Also set up monitoring and periodic optimization.

What changes fundamentally?

The biggest change is conceptual. Qlik and Power BI enable users to work with data in different ways.

A different approach to analysis

Qlik’s associative engine makes relationships between data an immediate part of the user experience. After making a selection, you can see which values are associated with it and which values are excluded.

This allows users to follow connections that were not necessarily designed as a fixed navigation path in a report.

Power BI also supports interactive reporting, drillthrough, filtering, and self-service. However, its starting point is different. Analysis is guided more strongly by:

• The semantic model;
• Explicitly defined relationships;
• Measures and calculation logic;
• The design of report pages;
• Available filters and interactions.

A question that can be explored directly through associations in Qlik may require additional modeling or a specific measure in Power BI.

That does not make Power BI any less powerful. It does mean that you should not simply recreate existing Qlik apps exactly as they are. You need to reassess how users can best answer their questions on the new platform.

Data model

Qlik data models cannot be exported directly to Power BI. Tables, relationships, calculations, and selection logic must be reassessed.

Both platforms can work well with a star schema. The main difference is how the engine processes relationships, filters, and calculations.

In Power BI, relationships and filter directions are explicit parts of the model. Calculations are typically created using DAX, where filter context and row context play an important role.

You can use Qlik expressions and Set Analysis as a conceptual starting point, but they must be redesigned and reimplemented.

In part 2 of our Qlik vs Power BI comparison series, we take a more technical look at the differences in data modeling.

Scripting and data transformation

Qlik load scripts cannot be transferred to Power BI or Fabric.

Depending on the target architecture, the transformation logic may be implemented in, for example:

• Power Query;
• Dataflows;
• Fabric Data Factory;
• Notebooks;
• A data warehouse;
• An external data integration platform.

People with strong Qlik scripting skills will usually recognize the transformation logic quickly. However, the syntax, execution, and design principles are different.

Do not expect a direct one-to-one transfer of knowledge. Allow time for training, guidance, and review.

Security

Section Access and Row-Level Security serve a similar purpose: ensuring that users only see the data they are authorized to access.

However, their implementation differs.

In Power BI, RLS is configured using roles and filters in the semantic model. Workspace roles, Object-Level Security, and security in the data source may also play a role.

The existing user groups and security rules can serve as input. The technical structure must be redesigned and tested.

Do not try to replicate Section Access exactly. Start with the security capabilities and management structure of the new platform.

Performance and user experience

It is too simplistic to say that Qlik or Power BI is always faster.

Perceived performance depends on factors including:

• The data model;
• The volume of data;
• The storage mode;
• DAX or Qlik calculations;
• Caching;
• Capacity;
• Data sources;
• The network;
• Report design;
• The number of concurrent users.

Qlik can feel more responsive during exploratory use, especially when users make many selections and continuously explore associations.

Power BI can perform very quickly with a well-designed semantic model and appropriate capacity. However, poorly designed DAX, unnecessarily complex visuals, or unsuitable storage choices can significantly degrade the experience.

Therefore, do not test technical refreshes alone. Have real users perform representative analyses in a proof of concept.

For more on the practical differences in end-user experience, read part 4 of our Qlik versus Power BI comparison series.

What can you carry over, and what can’t you?

A migration does not start entirely from scratch. The existing environment contains a great deal of valuable knowledge. It is usually only the technical implementation that cannot be transferred.

What you can reuse

Data sources

The same ERP systems, databases, APIs, and files can often be reconnected.

However, check whether existing connectors, gateways, and authentication methods need to be reconfigured.

Business rules and KPI definitions

Definitions of revenue, margin, active customers, or inventory value remain valuable. They only need to be reimplemented and validated.

Knowledge from the QVD layer

The QVD files themselves do not automatically become part of the new architecture, but they do show:

• Which data is used;
• How tables are combined;
• Which transformations are required;
• Where historical data is built up;
• Which datasets are shared across multiple applications.

Security rules

Section Access can serve as the functional specification for the new authorization model.

Dashboard design and user requirements

The existing dashboards show what information users need. Use them as a source, not as a mandatory visual design.

What needs to be rebuilt

Qlik apps

Qlik apps cannot be imported as a Power BI report. Reports, models, and calculations must be rebuilt.

Qlik load scripts

The logic can be translated, but the syntax and technical implementation are not compatible.

Set Analysis and expressions

The intent of the calculation can be preserved. The implementation must be redesigned in DAX or in the data layer.

Extensions

Qlik extensions do not work in Power BI. Determine whether a standard visual, a certified custom visual, or a different report design can achieve the same goal.

Section Access

The security rules must be reimplemented as RLS, OLS, or a combination of platform and data source security.

NPrinting reporting

NPrinting reports are not converted automatically. You need to reassess how scheduled PDF, Excel, and other reports are created and distributed.

For example, you can use Power BI subscriptions, paginated reports, Mail & Deploy, or another reporting service. If you already use Mail & Deploy alongside Qlik, you can explore whether this distribution layer can be retained and connected to Power BI instead.

For a comparison of the front-end and development experience, read part 3 of our Qlik vs Power BI comparison series.

The complexity often lies in the QVD layer

In many organizations, much of the business logic is not in the dashboards but in the underlying QVD layer. This includes historical data buildup, incremental load processes, transformations, and dependencies between applications.

An extensive QVD architecture is not a reason to stay with Qlik. It does mean that a migration involves replacing more than just the reporting layer.

That is why you should identify the following early on:

• Which QVDs are actually being used;
• Which business logic needs to be retained;
• Which dependencies exist between applications;
• Which components can be simplified;
• Which logic would be better moved to a central data layer;
• Which target architecture the organization wants to manage afterward.

The QVD files themselves do not automatically become part of the new environment. However, they are an important source for understanding how data is built, combined, and reused.

Within Fabric, a Lakehouse with Delta or Parquet files can serve a similar role to a curated QVD layer. But a Lakehouse is not automatically the right destination.

You can also retain an existing data warehouse, use Azure SQL, or choose another data integration platform.

The migration is therefore also an opportunity to eliminate years of technical debt, duplicate logic, and unused intermediate layers.

Real-world example: at Nature’s Pride, we used TimeXtender to build a central data layer as the foundation for the migration from Qlik to Power BI. This allowed data sources and business logic to be configured centrally rather than rebuilt separately for each Power BI model. Read the customer case study.

The migration approach in practice

There is no standard migration path. Every migration from Qlik to Power BI or Fabric requires a tailored approach and begins with a thorough assessment. Organizations that skip this step often discover only during implementation how much complexity the environment actually contains.

Phase 1: Assessment

Start with a complete inventory of the current environment:

• Qlik apps;
• QVDs;
• Data sources;
• Reload tasks;
• Dependencies;
• Section Access;
• Extensions;
• Macros and document triggers;
• External scripts and application integrations;
• NPrinting reports;
• User groups;
• Actual usage figures;
• Management processes.

A list of applications is not enough. You need to know who uses them, what decisions they support, and which components actually deliver value.

Want to approach this inventory systematically? Use our Qlik to Power BI Migration Readiness Checklist to see which areas have already been assessed and where open questions remain.

Then use the 3-R framework.

Retain

The app remains in Qlik. The value does not justify the effort required to rebuild it, or Qlik is deliberately retained as the better solution for this use case.

Rebuild

The functionality is still needed and is rebuilt in Power BI. This does not mean you have to copy the existing app exactly. The structure, user experience, calculations, and scope can be adapted to the new platform.

This is also the time to remove redundant tabs, duplicate logic, historical exceptions, and unused features.

Retire

The app is archived rather than replaced, for example because it is rarely used or because the information is now available elsewhere.

In our experience, this inventory is often underestimated. Hidden dependencies, exceptions, and complex security rules only become apparent through a thorough analysis.

Phase 2: Target architecture

Next, determine which components to replace:

• Reports only;
• Reports and semantic models;
• Data integration as well;
• Storage and orchestration as well;
• The entire analytics architecture.

Then answer questions such as:

• Can the existing data layer remain in place?
• Is a data warehouse or lakehouse needed?
• Which logic belongs in the data layer, and which belongs in Power BI?
• Will you choose Power BI Pro, Premium Per User, or Fabric capacity?
• Which workloads will share the same Fabric capacity?
• How will the development, testing, acceptance, and production environments be set up?
• How will deployment and version control be handled?

For a larger environment, start with a proof of concept. Do not choose a simple dashboard; use a representative application with relevant data volumes, calculations, and security.

Developing the target architecture requires both Power BI and Microsoft Fabric expertise when you are also modernizing the underlying data layer.

Phase 3: Data layer and data sources

Reconnect the data sources and build the chosen data architecture.

Use the existing QVD logic as a functional reference, but reassess each transformation. Not everything that has historically ended up in the Qlik load script automatically belongs in the new solution.

With a phased migration, the existing Qlik data layer does not have to be retired immediately. In addition to QVD, Qlik Sense can also save tables as Parquet. This allows existing QVD generators to temporarily produce both QVDs for the Qlik apps and Parquet files for the new Microsoft environment.

For example, these Parquet files can be placed in Azure Blob Storage or Azure Data Lake Storage and accessed from Fabric. This allows you to rebuild the reporting layer incrementally, without having to replace all the transformation logic at the start of the project.

Test the following, among other things:

• Counts and totals;
• Historical data;
• Incremental processing;
• Exceptions;
• Key fields;
• Data quality;
• Refresh duration;
• Error handling;
• Lineage and documentation.

Complete this foundation before you start building large numbers of reports. Otherwise, you will end up fixing the same data issues in multiple Power BI models.

Phase 4: Semantic models and reporting

Start with the most widely used and most valuable Qlik applications.

Do not automatically recreate every sheet and every object. For each report, determine:

• Which questions users actually answer;
• Which KPIs are essential;
• Which analyses are rarely used;
• Which Qlik interactions need to be handled differently;
• Which information can be consolidated into one central semantic model.

This is also where experienced Power BI consultants can help redesign semantic models, measures and reports rather than simply recreating the existing Qlik applications.

Use the migration to simplify reporting. A new platform with the same legacy clutter is not an improvement.

Phase 5: Governance and security

Set up workspaces, roles, and ownership before rolling out the environment more broadly.

Define:

• Who is allowed to publish models;
• Who is allowed to modify reports;
• How RLS and other security measures are managed;
• Who is responsible for data quality;
• How changes are tested;
• How capacity and refreshes are monitored;
• Which reports are certified or promoted;
• How users request access.

Governance is not just a technical setup. It is also a set of agreements about ownership and decision-making.

Phase 6: Testing and go-live

Run Qlik and Power BI in parallel temporarily.

Compare not only totals, but also:

• Selections and filters;
• Edge cases;
• Security;
• Exports;
• Levels of detail;
• Refresh timing;
• Use across different devices;
• Performance during peak hours.

Conduct user acceptance testing for each department or user group. Then roll out in phases.

Running both systems in parallel for two to four weeks can be a useful starting point, but the right period depends on the frequency and importance of the reporting.

A shorter period may be sufficient for a daily operational dashboard. For monthly or quarterly reporting, you need to be able to compare at least one complete reporting cycle.

Common mistakes when migrating from Qlik to Power BI

The biggest mistakes in a migration from Qlik to Power BI are usually not caused by a single wrong technical decision. They arise because the scope of the rebuild, the differences between the platforms, and the impact on users are underestimated.

1. Underestimating that it is a rebuild

Organizations plan the timeline and budget for a migration, but in reality they are facing a rebuild. Qlik apps, load scripts, data models, calculations, and security rules are not transferred automatically.

Hidden dependencies are also easily overlooked. These may include QVD chains, macros, document triggers, extensions, external scripts, API integrations, NPrinting, and Excel files that have become part of the process.

Organizations that do not conduct a thorough inventory beforehand often discover the true complexity only during implementation.

2. Confusing Qlik expertise with Power BI expertise

A good Qlik developer understands data, modeling, and business logic. That knowledge remains valuable during a migration.

But DAX, Power Query, Power BI modeling, and Microsoft Fabric also require their own expertise. Be sure to account for training, guidance, and review by experienced Microsoft specialists.

The reverse is also true. A Power BI specialist without Qlik expertise may misinterpret the purpose of Set Analysis, associations, QVD load patterns, and other Qlik-specific constructs.

A migration team therefore needs expertise on both sides. Combining Qlik and Microsoft experience helps prevent existing solutions from being translated incorrectly to the new platform.

3. Using Microsoft Fabric without a clear scope and architecture

Microsoft Fabric is a broader data platform than Power BI. That means not every migration to Power BI automatically requires Fabric.

Determine in advance which components you actually need. Consider data integration, storage in OneLake, pipelines, lakehouses, notebooks, and real-time processing. Also make a deliberate choice between options such as pipelines, Dataflows Gen2, shortcuts, and mirroring.

Also consider the expected capacity usage. Different Fabric workloads share the same capacity and can affect one another. Without a clear scope and capacity estimate, you add costs and complexity without generating sufficient value in return.

4. Trying to translate Section Access one-to-one

Row-Level Security in Power BI serves roughly the same purpose as Section Access in Qlik, but it works differently.

Exact replication of the same tables, fields, and security structure often results in an unnecessarily complex solution. Use the existing security rules as a functional source, but redesign the security model based on the Power BI architecture.

5. Trying to migrate every app

Not every Qlik app needs to be rebuilt. Some apps are rarely used, contain largely the same information as other apps, or support a process that has since changed.

Use the assessment as an opportunity to clean up as well. Determine for each app whether it should be retained, rebuilt, or phased out. Every app you can responsibly retire immediately saves development, testing, and maintenance time.

6. Making the parallel run too short

During a parallel run, users can compare results, report discrepancies, and become familiar with the new way of working. This period must be long enough to test less frequent processes as well, such as month-end closing and periodic reporting.

The required length of the parallel run varies by environment and business process. Do not assume a single fixed timeframe for the entire organization. Instead, take a phased approach by department or reporting domain.

7. Treating change management as an afterthought

Power BI works differently from Qlik. Users will encounter different filtering options, navigation patterns, and ways to explore data. A technically correct report will not automatically be used effectively.

Involve key users in the design and acceptance testing from the outset. Communicate changes in good time and provide guidance during the transition. Change management should be part of the migration project from the beginning, not only after go-live.

8. Blindly carrying over existing business logic

Not every historical calculation, exception, or KPI definition is still correct or necessary. Some rules were originally added to address a temporary problem and were never removed. Other definitions are now interpreted differently by different departments.

Use the migration to revalidate business logic with the business. Document definitions and exceptions, and consciously decide what should be retained, modified, or removed. Otherwise, you will recreate old errors and ambiguities on the new platform.

9. Setting up management and governance only after go-live

A new Power BI or Fabric environment needs clear management agreements from the outset. This includes workspaces, permissions, deployment, naming conventions, ownership, monitoring, support, and the publication of datasets and reports.

If you only address this after go-live, sprawl can quickly set in. Reports are copied, definitions begin to diverge, and it becomes unclear who is responsible for management and data quality.

That is why you should design not only the technical solution, but also how it will be managed and further developed after the migration.

For ongoing support after go-live, we offer Power BI Support and Microsoft Fabric Support.

Frequently asked questions

Conclusion

Migrating from Qlik to Power BI or Microsoft Fabric can be a good choice for many organizations, especially when the Microsoft ecosystem is already the standard and Qlik is increasingly seen as a separate platform.

But the transition is not a straightforward move. Data models, transformations, security, and reports must be reassessed and largely rebuilt.

The key, therefore, is not to start building as quickly as possible. Start with an honest inventory of what you have, what is still being used, and what you actually want to replace.

Sometimes the outcome is Power BI on top of the existing data layer. Sometimes a broader Fabric architecture makes sense. And sometimes Qlik is still the better choice for part of the environment.

Allow for delays. In practice, migrations often take longer than anticipated. Build in sufficient time and, where possible, maintain contractual flexibility until the new environment has actually been validated and is in use.

Bitmetric has deep Qlik roots and works daily with Power BI, Microsoft Fabric, and broader data architectures. This means we can help not only with setting up the new platform, but also with determining what should be retained, rebuilt, or phased out in the existing Qlik environment.

Want to map out where you stand first? Use our Qlik to Power BI Migration Readiness Checklist and assess your migration against 85 concrete checkpoints.

Want to know which route is right for your environment? Schedule a call.

Want to learn more about the differences between the platforms first? Read part 1 of our Qlik versus Power BI comparison series on Qlik and Power BI. Staying with Qlik but considering a move to the cloud? Read our Qlik Cloud migration guide.

Barry Harmsen

Barry is the founder of Bitmetric. He has worked in Data & Analytics for more than twenty years, in roles ranging from hands-on development to architecture and strategy. He likes solutions that fit the organization’s context and that people actually use. Barry was a Qlik Luminary and Qlik Partner Ambassador for many years. A long time ago, he wrote QlikView for Developers.

Outside work, Barry spends his time with his family, rowing, doing DIY projects, and working on hobby projects that his family embraces with varying degrees of enthusiasm.

The post Migrating from Qlik to Power BI or Microsoft Fabric: the complete guide (2026) appeared first on Bitmetric.

A perfectly reasonable question. But if that is the essence of proactive support, it is still mostly reactive support with a friendly veneer.

At Bitmetric, I take a different view of proactive support.

To me, it means systematically looking for signals in an environment before they develop into disruptions, tickets, or urgent requests. Not because everything is entirely predictable, but because there are often warning signs before a problem becomes an incident.

An API key that will expire soon.
An app approaching a memory limit.
A data gateway that will soon no longer be supported.

Those are things you would rather identify before they affect a user.

Proactive support is not the same as operational monitoring

Proactive support is not the same as operational monitoring.

With operational monitoring, disruptions are reported as soon as they occur. This could be a failed reload or a process that has stopped. Depending on the agreements in place, the alert goes directly to the customer, Bitmetric, or both.

Proactive support takes a broader view. It looks not only at immediate disruptions but also at risks that have not yet become incidents.

This is how the two complement each other. Operational monitoring helps you respond quickly when something breaks. Proactive support helps you identify sooner where problems may arise.

A practical example: CloudScan for Qlik

One example of how we approach this at Bitmetric is our CloudScan for Qlik: an automated daily check of Qlik Cloud tenants.

CloudScan can be purchased as a standalone service, but it is also included as standard with our Qlik Support services and when you purchase your Qlik Cloud subscriptions through Bitmetric.

CloudScan checks a tenant against more than 50 criteria, including health, capacity, reliability, security, users, configuration, and usage. We look not only at issues that require immediate attention but also at signals that indicate something may be developing.

Critical findings are reported immediately. The report also provides insight into issues that are not yet urgent but that you still need to know about.

The findings are classified, making it clear what requires immediate attention and what primarily needs to be monitored.

This prevents noise. An expired API key requires a different response than an app that is gradually approaching a memory limit. Not everything is equally urgent, but some signals are worth identifying early.

An alert is not a solution in itself

An alert is only useful when it is clear what it means, how urgent it is and what action makes sense. Sometimes immediate action is needed, sometimes it can be discussed during a regular review, and sometimes it is mainly a signal that something requires further investigation.

That is why CloudScan combines automation with the practical knowledge of consultants who work with Qlik every day. After thirteen years as a Qlik partner, and with nearly twenty years of personal experience with the platform, we know the difference between noise and a signal that genuinely deserves attention. Not every warning requires action, but every warning does require proper assessment.

What we learn from one customer also helps others

CloudScan is not a fixed checklist we created once and left unchanged.

Because we perform these checks for multiple customers, we can identify patterns. An issue we encounter while supporting one customer may also affect other Qlik Cloud environments. The same applies to what our Qlik consultants see during projects, audits, migrations and management work.

If an issue can be detected automatically and clearly poses a risk, we turn it into a new check.

That check then runs automatically for all relevant CloudScan customers.

As a result, an issue we discover at customer A today may allow us to identify the same risk at customer B tomorrow, before it becomes an incident there.

For us, this is an important part of proactive support: using knowledge not only to solve one issue, but also to recognize the same issue earlier in the future.

Proactive support in practice

Proactive support cannot prevent things from ever going wrong. A Qlik Cloud environment is constantly changing: users build new apps, data sources are modified and Qlik continues to develop the platform.

It does, however, allow you to identify risks earlier and turn experience from support and consulting into checks that are then performed automatically.

This means support is focused not only on resolving incidents, but also on keeping the environment healthy.

To me, proactive support therefore means systematically reviewing what is happening, assessing what requires attention and advising on an appropriate next step.

How healthy is your Qlik Cloud environment?

Would you like to know which anomalies and risks CloudScan finds in your Qlik Cloud environment? We can run CloudScan once at no charge on one Qlik Cloud tenant.

CloudScan is also included as standard with our Qlik Support services and when you purchase your Qlik Cloud subscriptions through Bitmetric.

We will review the key results together, after which you will receive the full report, including the details for each check.

Barry Harmsen

Barry is the founder of Bitmetric. He has worked in Data & Analytics for more than twenty years, in roles ranging from hands-on development to architecture and strategy. He values solutions that fit the organization’s context and that people actually use. A long time ago, he wrote QlikView for Developers.

Outside work, Barry spends his time with his family, rowing, doing DIY projects and working on hobby projects that receive varying levels of enthusiasm from his family.

The post Proactive Qlik Cloud support is more than an occasional check-in call appeared first on Bitmetric.

But it does not cover everything you build yourself inside that environment.

I see it regularly with clients: plenty of thought has gone into how to set up Qlik Cloud, which apps to build, who gets access. But what it would take to actually recover all of that? Much less often considered. Which is understandable, it is not the first thing on your mind when you are standing up a new environment. Until you need it.

Apps are the starting point, not the finish line

Apps are the most visible part of a Qlik Cloud environment, so it makes sense that people think of them first. A lot of work goes into them: dashboards, data models, scripts, business logic, visualisations.

But an app rarely stands alone. It relies on data connections, lives in a space, requires permissions and is probably reloaded on a schedule. Most environments also contain automations, reporting tasks, themes and extensions that have value well beyond any single app.

A good backup looks further than app files.

What do you actually want to be able to restore?

A practical Qlik Cloud backup covers a few distinct layers.

Apps and user content

Apps are the core. You want to be able to recover them after accidental deletion, unwanted changes or an overwrite that should not have happened. Bookmarks can matter too, especially when users rely on saved selections as part of their daily workflow.

One deliberate choice worth making upfront: export apps without loaded data. The app structure, scripts and metadata are preserved, while the datasets themselves stay within Qlik Cloud. That keeps storage volumes manageable and reduces risk around sensitive data. The trade-off is that after a restore, the app needs a reload before it shows current data again. That is fine, as long as everyone knows it going in.

Data connections, automations and integrations

A restored app is not much use without its connections to source systems. Data connections belong in your backup.

The same goes for automations, webhooks and web integrations that keep the broader environment running. That includes processes triggered by events, and integrations with other applications, portals or embedded analytics setups.

Sensitive data such as passwords and client secrets should not be stored in a backup. Those get re-entered at restore time. That is a deliberate choice, not an oversight.

Spaces, users and permissions

A lot of the value in Qlik Cloud lives in how access is structured. Which teams work in which spaces? Who can publish? Which groups map to which roles?

If that structure is lost or accidentally changed, the consequences can be significant. Users locked out of reports. Others with more access than they should have. Publishing workflows that stop working.

You do not need to automate every last detail of a restore. But you do need to be able to reconstruct how things were set up.

Tenant settings

Beyond spaces and permissions, there are broader tenant-level settings that affect how the environment functions. Identity providers for SSO, licence configuration, security settings. Not things you change often, but if they are lost or accidentally modified, the impact on access and day-to-day use is immediate.

Formatting, tasks and the smaller parts

Some things only become visible when they are missing. A theme that did not come back. An extension that breaks a visualisation. A reload task that stopped running. A sharing task that is no longer sending reports. A business glossary that needs to be rebuilt from scratch. A report template that needs to be reconfigured.

Not the most prominent parts of your environment, but they determine whether everything actually works again after a restore.

Think about restore, not just about saving

A backup only becomes valuable when you have thought through how you would actually use it.

For some components, a restore is simple: put the file back. For others, it means recreating, reconfiguring or using the backup as a reference for manual work. None of that is a problem, as long as you know in advance what can be restored directly and where extra effort is involved.

Practical questions worth asking in advance:

• What components are available through Qlik APIs?

• What metadata do you need to reconstruct configuration?

• What information will need to be re-entered during a restore?

Make sure you know if it works

A backup process without monitoring is a backup process you trust until it fails you.

You want visibility into backup runs, alerts when something goes wrong, and a clear record of what each run did and did not cover. A manifest per run helps with this: it tells you exactly what was backed up successfully and where issues occurred.

Retention is worth thinking about too. Keeping only yesterday’s backup is rarely enough, because problems are not always noticed straight away. A layered approach works well: daily backups for the short term, weekly and monthly snapshots for longer lookback periods.

In short

A good Qlik Cloud backup is more than periodically exporting apps. Data connections, automations, integrations, spaces, permissions, tenant settings, appearance, tasks, monitoring and restore agreements all belong in the picture. And within all of that, deliberate choices need to be made: what do you store, what do you leave out, and what needs to be re-entered when something goes wrong?

It does not need to be complicated. But it does require a clear picture of what you are protecting and what you can actually get back when you need it.

Backup is not the most glamorous part of a Qlik Cloud environment. But when something is gone, it is the only thing that matters.

Many organisations have thought carefully about Qlik Cloud as a platform, but less about what it would take to recover their own content and configuration. Does that sound familiar? If you would rather not build and maintain the backup process yourself, our Backup for Qlik Cloud service covers backup, retention, verification and recovery for you.

Barry Harmsen

Barry is the founder of Bitmetric. He has been working in data & analytics for over twenty years, across roles ranging from hands-on development to architecture and strategy. He likes solutions that fit how an organisation actually works and that people actually use. A long time ago, he wrote QlikView for Developers.

Outside of work, Barry devotes his time to his family, rowing, DIY and hobby projects that his family is excited about to varying degrees.

The post What should be included in a good Qlik Cloud backup? appeared first on Bitmetric.

Maybe someone mentioned it during a Power BI discussion.
Maybe it came up in a meeting about modern data platforms.
Or maybe you saw it and thought, “Another Microsoft product I will need to learn at some point.”

Microsoft Fabric is not just another tool.

It is Microsoft’s attempt to bring data engineering, data integration, analytics, and business intelligence into one unified platform. And that shift matters more than it might seem at first.

Because many organizations are still dealing with a very fragmented data landscape:

• Different tools for ingestion.
• Different tools for transformation.
• Different tools for storage.
• Different tools for reporting.

Every extra layer creates more complexity, more governance challenges, and more time spent moving data instead of actually using it. Microsoft Fabric is designed to simplify that.

What Microsoft Fabric actually is

Microsoft Fabric is a unified analytics platform that runs entirely as a SaaS service. Instead of stitching together separate tools, Fabric provides one environment where different data workloads can run on the same foundation.

At the center of that foundation is OneLake, Microsoft’s single logical data lake for the entire organization. This means different teams can work on the same data without constantly copying, exporting, or rebuilding pipelines between tools.

Data engineers, analysts, and BI developers can all work within the same platform. That shared environment is what makes Fabric different from many traditional data architectures.

The main Fabric components you should know

Fabric covers a lot of capabilities, but beginners only need to understand a few core pieces.

Data Engineering

Data Engineering in Fabric focuses on preparing and transforming data.

You work with lakehouses, notebooks, Spark environments, and pipelines to ingest and transform data before it is used for analytics. The lakehouse architecture combines the flexibility of a data lake with the structure of a data warehouse.

Data Science

Fabric also includes environments for machine learning and experimentation.

Data scientists can explore data, train models, and deploy insights directly inside the same platform where the data already lives. This removes the need to constantly move datasets between different tools.

Business Intelligence

This is where many users first interact with Fabric.

Power BI is deeply integrated into the platform, allowing analysts to build dashboards and semantic models directly on top of Fabric data. For many Power BI teams, Fabric feels familiar, but with a stronger data foundation underneath.

Real Time Intelligence

Some organizations need to analyze data the moment it arrives.

Fabric includes tools for streaming data and event driven scenarios, allowing teams to work with high velocity data and respond to changes in near real time.

Why Microsoft Fabric matters

The biggest reason Fabric matters is not because it introduces completely new technology. It matters because it tries to simplify the modern data stack.

Over the past decade many companies adopted separate tools for every part of the data lifecycle:

• A tool for ingestion.
• A tool for storage.
• A tool for transformation.
• A tool for analytics.

This approach can work, but it often creates complicated architectures and a lot of duplicated data. Fabric’s goal is to reduce that fragmentation by bringing those capabilities closer together.

Instead of moving data across multiple platforms, teams can build pipelines, models, and dashboards on top of the same data foundation. That can significantly simplify governance, collaboration, and data management.

How to start learning Fabric

One mistake many beginners make is trying to understand every Fabric capability at once. That is not necessary. A better approach is to start with the part that connects to the work you already do.

If you mainly work with dashboards and analytics, begin with → Power BI and Business Intelligence experience.

If you build pipelines and transformation logic, explore → Data Engineering workloads first.

If you work with machine learning or experimentation, focus on → Data Science capabilities.

Once you understand one part of the platform, the rest becomes easier to explore.

The bigger picture

Microsoft Fabric reflects a broader shift in the data world. Organizations are moving away from disconnected analytics tools and toward platforms where data engineering, analytics, and AI can work together more naturally.

That does not mean every company will move everything into Fabric overnight. But it does mean understanding Fabric is becoming increasingly valuable for data professionals.

Because the companies building their next generation data platforms are looking for ways to simplify their architecture, reduce duplication, and make data easier to use across teams. And that is exactly the problem Fabric is trying to solve.

Credit where credit is due → Shubham Rai

Mireille Erasmus

Mireille is a Marketing Manager at Bitmetric. Creative, energetic, and people-loving, she’s all about turning ideas into content that connects. Outside work, you’ll find her with friends, walking her dog, or exploring local markets.

More from the Bitmetric team

Bitmetric Qlik Support

Keep your Qlik environment running smoothly with proactive support that prevents issues before they appear. Available on flexible monthly plans. Learn more.

Qlik vs Power BI Series

See how Qlik and Power BI perform when theory meets reality. Three apps rebuilt, every step examined. Learn more.

The post A Beginner’s Guide to Microsoft Fabric appeared first on Bitmetric.