Qlik Sense to Power BI: how to migrate

Migrating from Qlik Sense or QlikView to Power BI is a rebuild, not a conversion. No tool turns a Qlik app into a working Power BI report. You carry over the data sources, the KPI definitions and what users need, and you rebuild the data model, the calculations and the security. The migration runs in six steps: take inventory, choose the target architecture, build the data layer, rebuild models and reports, set up security and governance, and run both systems in parallel for a while.

That sounds like more work than most organizations expected, and it usually is. The common assumption is that you walk through the Qlik screens and recreate them in Power BI. In practice the screens are the easy part. The work is in what lies underneath: years of load scripts, intermediate files and exceptions that someone once built in and never wrote down.

That is also where the opportunity is. A migration forces you to pick up every definition again, and that is exactly the foundation many Qlik environments never laid down explicitly. Skip that step and copy only the screens, and you end up with a new tool carrying the same ambiguities. The new dashboard is not what makes the difference; the model underneath it is.

So below you will find why organizations switch and what really changes, then what you carry over and what you rebuild, and after that the step-by-step plan, the costs and the pitfalls.

Why do organizations move from Qlik to Power BI?

Three reasons keep coming up, and they have little to do with the quality of Qlik.

• The rest of the organization already runs on Microsoft. If you use Microsoft 365 and Azure, Qlik is an island with its own servers, its own accounts and its own expertise. Power BI uses the same accounts and groups as the rest of your environment.
• AFAS dropped Qlik. Since 1 December 2025, the Dutch ERP vendor AFAS offers Power BI as its only BI solution. Anyone using the built-in Qlik dashboards had to move on to something else regardless. How the connection to Profit works now is covered in our article on how to connect AFAS to Power BI.
• Expertise is easier to find. There are more people with Power BI experience on the job market than people with Qlik experience. When the one colleague who understood the Qlik scripts leaves, you suddenly have a system nobody dares to touch.

If you are still on QlikView, the question has been waiting for a while. QlikView is Qlik’s older product and runs on your own server; Qlik Sense is its successor. Modernizing a QlikView dashboard leaves three options: moving to Qlik Sense, to Qlik Cloud or to Power BI. All three mean a rebuild, so the question is not which route is the least work, but which fits the rest of your environment best.

Qlik vs Power BI: what really changes

The biggest difference is not in the charts but in how users work with data.

Qlik runs on an associative engine. Click a customer and you immediately see which products, regions and periods belong to it, and which do not. Users follow connections that nobody designed as a navigation path in advance.

Power BI works from a semantic model: a designed layer in which tables, relationships and calculations are fixed. What a semantic model is exactly, the glossary explains. You can analyze just as well in Power BI, only along the paths the model offers. A question that came up naturally in Qlik sometimes needs an extra measure or a different page in Power BI.

On top of that, four things change that users notice straight away:

• The screen looks calmer. Qlik apps are often packed screens with many tables and charts at once. A good Power BI report shows a few visuals per page around a single question.
• Filters work differently. No more green, white and grey values, but slicers and filters that apply to a page or the whole report. That takes getting used to for anyone who steered by those colours for years.
• Users can do more themselves. In Qlik most users only look. In Power BI, with the right permissions, they can build their own reports on a shared model, export, or drill through to detail. That is a gain, and it calls for clear agreements on what is allowed.
• The licensing model is different. Power BI charges per user, and if you already have Microsoft 365 E5, Power BI Pro is included. More on that under costs.

What do you carry over and what do you rebuild?

You do not start from scratch. The existing environment holds a lot of knowledge, just not in a form Power BI can read. The table below shows where each part ends up in Power BI.

Parts of a Qlik environment and their Power BI counterpart

In Qlik	In Power BI	Carry over or rebuild
Qlik app	Semantic model plus one or more reports	Rebuild, the app serves as the specification
Load script	Power Query, a dataflow or a data warehouse	Carry over the logic, rewrite the code
QVD files	Tables in a data warehouse or lakehouse	Use as a source to understand what happens
Set Analysis and expressions	DAX measures	Carry over the intent, rewrite the formula
Master items	Measures and columns in the shared model	Carry over the definitions
Section Access	Row-level security and workspace roles	Carry over the rules, rebuild the setup
NPrinting	Subscriptions and paginated reports	Set up again
Extensions	Standard visuals or certified custom visuals	Choose again

The pattern is the same every time: the intent comes along, the technology does not. Calculations show it most clearly. Set Analysis expressions become DAX formulas, and that is a translation, not a conversion. Revenue for 2025, regardless of which year the user has selected, looks like this in both languages:

Qlik:      Sum({<Year={2025}>} Revenue)
Power BI:  CALCULATE ( SUM ( Sales[Revenue] ), Calendar[Year] = 2025 )

Two lines, the same answer. But a Qlik app quickly holds dozens of these, with nested exceptions only the original developer could explain. So you test every translated formula against the source, not only against the old Qlik result. Why that difference matters comes further down.

Qlik to Power BI migration in six steps

There is no standard path, but there is an order that brings most surprises forward. Microsoft describes a general approach to Power BI migrations that is not specific to Qlik. The six steps below are that approach, tailored to what sits in a Qlik environment.

1. Inventory what exists, and what is used. Map all apps, QVD files, reload tasks, Section Access rules, NPrinting reports and extensions. Put the usage figures next to them. Then sort every app: keep, rebuild or retire. Almost every environment has apps nobody has opened in months.
2. Choose the target architecture. Are you replacing only the reporting layer on top of an existing database, or the layer underneath as well? If the logic now lives in Qlik scripts and QVDs, it needs a new home. That can be Power Query for a small environment, or a data warehouse or Fabric lakehouse when several reports share the same tables.
3. Build the data layer first and fix the definitions. Write a short data migration plan that sets out, per table, which source, how much history and which deviation is acceptable. Finish this layer before you build reports, or you will be fixing the same data problem in five models. Qlik Sense can also write tables to Parquet, according to the documentation of the Store statement. That lets an existing script feed both Qlik and the new environment for a while, so you do not have to switch everything at once.
4. Rebuild model and reports per domain. Start with one representative app as a proof of concept: not the simplest one, but one with real data volumes, tricky calculations and security. Then go domain by domain: finance, sales, operations. Build one shared model per domain instead of one model per report.
5. Set up security and governance before the rollout. Agree who may publish models, who may change reports, who owns which workspace and how users request access. Section Access becomes row-level security and workspace roles. Use the existing rules as a specification, not as a blueprint.
6. Run in parallel, and only then switch Qlik off. Keep both systems running until at least one full month-end close has been compared, including the reports that run only monthly or quarterly. Go live per department, not for the whole organization at once. And do not announce a switch-off date before the comparison adds up, especially if the Qlik contract would have to be renewed by then.

Step 4 holds the biggest temptation: recreating the old screens exactly. Users ask for it, because it is what they know. But Power BI filters differently, displays differently and has different strengths.

The question per screen is not what it looked like, but which decision it was used for. Copy a crowded Qlik Sense dashboard pixel for pixel into Power BI, and after three months of work you have exactly what you had, just in a different font.

Why the numbers in Power BI differ from Qlik

Sooner or later it happens during the parallel period. Qlik says, for example, that September revenue was €1,284,000, and Power BI says €1,279,500. Within a day the meeting is no longer about what that revenue means, but about which system is right. Exactly the argument a new report was supposed to end.

The first thing to know: Qlik is not the truth. The old number is also the outcome of definitions, some of them chosen years ago.

So the question is not which system is right, but which number matches the source. Compare both with the administration itself, the general ledger or the ERP, and not only with each other. The usual causes of a difference:

• Logic in the load script nobody knew about. Credit notes that were filtered out, intercompany postings that were removed, a fixed correction on one customer. Rules like these live in a script, not in a definition, and quietly disappear in the rebuild.
• Week numbers. By default DAX counts the week containing 1 January as week 1. The European ISO numbering, where the week with the first Thursday is week 1, only applies when you pass the function return type 21. That is in the WEEKNUM documentation, and in some years it shifts a whole week of revenue.
• Rows without a matching key. A sales line with a customer number that is not in the customer table shows up in Power BI as a separate row with a blank customer. It looks like an error in the new report, but it is an error in the source that went unnoticed in Qlik.
• Default selections and hidden filters. A Qlik app that opened with the current year selected, or a report-level filter in Power BI that nobody sees.

Every difference you resolve this way, you record as a definition. Then after the migration you have not only a new tool, but also one agreed number. How to fix such deviations structurally in the source rather than in the report is covered in our article on data quality.

What does a Qlik to Power BI migration cost?

The licence is the smallest part of the bill. Power BI Pro costs €12.10 per user per month, excluding VAT and on annual billing, and is included in Microsoft 365 E5. For an organization with twenty-five users that comes to €3,630 a year. What else comes on top and when a capacity becomes cheaper is covered in our article on Power BI licensing costs.

The bulk is in the work. Four items determine the size:

• The number of apps that really need to move. Not the number of apps on the server, but the number marked rebuild after the inventory.
• The logic in the load scripts and QVDs. An app that runs directly on a clean database is rebuilt quickly. An app leaning on four layers of QVDs is not.
• Reconciling the numbers. Every difference from the previous section takes investigation, and that work is rarely easy to estimate up front.
• Training and support. For users, and for the developers moving from Qlik script to Power Query and DAX.

A price per dashboard is therefore a poor starting point. What building a single Power BI dashboard costs when the data is already in order is covered in our article on Power BI dashboard development. A migration adds the inventory and the data layer, and those decide whether it takes weeks or months.

In the business case, also count what you save: the Qlik licences and the server, and every app you retire instead of rebuilding. Do allow for overlap, though. During the parallel period you pay for both.

People, skills and resistance

A technically correct report does not get used by itself. Someone who has worked in Qlik for years knows exactly where to click, and in Power BI initially mostly misses what is no longer there. That is not unwillingness, it is habit.

Three things help. Involve a few regular users per department from the inventory onwards, not only at the acceptance test. They know which screens are really used and can later explain to colleagues why something works differently.

Show them what gets better, such as building their own overview on the shared model. And explain what deliberately does not come back, with the reason.

Something similar applies to the development team. A good Qlik developer understands data, models and business logic, and that knowledge stays valuable. But DAX and Power Query work differently, and translating Qlik script literally into Power Query gives you a model that is slow and hard to maintain.

The reverse is true as well: a Power BI specialist who misreads Set Analysis builds a measure that calculates something slightly different. A team works best with both sides at the table: the developers or QlikView consultants who built the apps at the time, next to someone who knows Power BI well. So involve your current Qlik partner in the inventory, even if they will not do the rebuild.

When you should not migrate (yet)

There are situations in which we advise against a migration, or at least against doing it now.

• Your users rely on associative exploration. Analysts who browse large datasets freely, without a predefined path, lose something essential in Power BI. Stay with Qlik then, or consider Qlik Cloud if you want to get rid of your own server.
• You actually want to solve a data problem. If the numbers do not add up or the dashboards are cluttered, that rarely comes down to the tool. A migration does not fix it and often makes it worse during the rebuild. Fix the problem where it lives, and only then choose a tool.
• There is no capacity right now. A migration needs time from the business for the inventory, testing and reconciliation. Without it, a half-finished migration leaves you with two systems that are both not quite right.
• Qlik is well managed and widely used. Being a Microsoft organization otherwise is not a reason in itself. One vendor is tidy, but not when it costs your users productivity.

In all of these cases the answer is not never, but something else first. That is why our approach starts with the inventory, and that inventory can also conclude that you should stay.

Is your Qlik environment a set of screens you want to redraw, or a chance to finally agree on one set of definitions? Want to know which of your apps need to move and which do not? Get in touch and we will take the inventory together.

Frequently asked questions