Migrating from Qlik to Power BI or Microsoft Fabric: the complete guide (2026)

As of December 1, 2025, AFAS Software disabled the Qlik integration in its platform. As a result, many Dutch organizations had to make a platform choice.

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

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

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.

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 English-language 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 English-language 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 English-language 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.

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.

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 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 English-language comparison series on Qlik and Power BI. Staying with Qlik but considering a move to the cloud? Read our Qlik Cloud migration guide.