Hi @powerbiexpert22
Key challenges when “migrating” from Qlik Sense to Power BI (in practice: rebuilding, not lifting-and-shifting):
1. No real “migration”, only redevelopment
There is no official or reliable tool that converts Qlik apps to Power BI one-to-one. You usually have to:
Reverse-engineer the Qlik data model and scripts
Rebuild ETL, model, measures, and visuals in Power BI manually
community.powerbi.com
+1
This means effort is closer to a new project than to a technical migration, and many stakeholders underestimate this.
2. Different data-modeling concepts
Qlik:
Associative engine (green/white/grey logic)
Script-based modeling in the Data Load Editor
“Tables” are logical; link fields drive associations
Power BI:
Tabular model with explicit relationships
Power Query (M) for ETL + DAX for calculations
Star schema is the recommended pattern
Kanerika
+1
Challenges:
Translating Qlik’s associative behavior to clear fact/dimension tables and relationships
Replacing “it just works when you click” with explicit filter propagation in a star schema
Performance tuning changes completely (cardinality, relationships, storage modes, etc.)
3. Rewriting Qlik script and ETL logic
Qlik script often contains:
Complex joins, mapping tables, loops (for each, for…next)
QVD-based architecture for incremental loads and reuse
Pre-aggregations and custom transformations
Power BI ETL is:
UI-driven steps in Power Query (M), or external ELT (SQL, Fabric, Databricks, etc.)
Bitmetric
+1
Pain points:
Translating procedural Qlik script to step-based M queries
Re-implementing QVD-style layers (staging, core, serving) using Dataflows / Fabric / database views
Handling logic that used variables & loops in Qlik, which doesn’t map 1:1 to Power Query
4. Translating expressions: Set Analysis → DAX
Qlik’s expression engine and Set Analysis are very powerful and very different from DAX. For example:
Alternate states
Complex set expressions with modifiers (e.g. <Year={$(=Max(Year))}>)
Row-level vs aggregation-level logic mixed together
Medium
+1
In Power BI:
Calculations split between measures, calculated columns, and sometimes Power Query
Filter context, row context, and context transition must be designed explicitly
Challenges:
Rewriting Set Analysis into DAX using CALCULATE, FILTER, ALL, TREATAS, etc.
Replacing alternate states with separate measures, disconnected tables, or field parameters
Ensuring totals, subtotals, and edge cases match business expectations
5. Visual & UX differences
Qlik apps often:
Mix exploration and dashboarding in the same app
Depend heavily on the associative selections UI (green/white/grey)
Use Qlik-specific visual behaviors and extensions
In Power BI:
Slicers and filters behave differently; selections are less “global & magical”
Some Qlik visuals/extensions do not have direct equivalents
Layout and navigation patterns (pages, drillthrough, buttons) are different
Lizardis
+1
Typical issues:
Users expect the same “click anywhere and see everything update” behavior
Need to redesign UX so it feels natural in Power BI instead of forcing a Qlik clone
Replacing Qlik extensions with either native visuals or certified custom visuals
6. Security and governance changes
Qlik:
Section access model with its own syntax and behavior
Power BI:
Row-Level Security (RLS) in the tabular model
Workspaces, apps, and sharing governed by Microsoft 365 & Fabric admin settings
Lizardis
+1
Challenges:
Translating section access rules into RLS roles and filters
Redesigning how apps are deployed, versioned, and governed
Aligning refresh schedules, gateways, and capacities with existing enterprise standards
7. Infrastructure and performance expectations
Moving from Qlik to Power BI usually changes:
Licensing model and cost structure
Where data lives (on-prem vs cloud, Fabric, Lakehouse, Databricks, etc.)
How large models are handled (Import vs DirectQuery vs DirectLake)
Entrans
+1
Challenges:
Re-evaluating model size, refresh windows, and gateway architecture
Avoiding “one huge model that does everything” when Power BI favors modular models
Training the team to monitor performance with tools like Performance Analyzer, DAX Studio, etc., instead of Qlik’s tooling
8. Change management and user retraining
Even if you perfectly replicate numbers, users still feel the change:
Analysts must learn Power Query + DAX instead of Qlik script + Set Analysis
End users must adjust to different filters, navigation, and limitations
Admins must learn Power BI governance, tenant settings, and deployment pipelines
Entrans
+1
If training and communication are weak, the migration is perceived as a downgrade (“Qlik was better”) even when technically it’s fine.
9. Scope creep and gap analysis
Because you cannot simply copy-paste Qlik apps, during the rebuild you will discover:
Old reports that nobody uses but someone insists on migrating
Logic that no one fully understands anymore
Opportunities to simplify KPIs and UX
Key risks:
Trying to rebuild everything feature-for-feature instead of prioritizing high-value scenarios
Not doing a proper functional gap analysis (what Qlik does that Power BI cannot or should not do the same way)
Inforiver
+1
10. Summary you can say explicitly to management
This is not a technical export/import. It is a redevelopment project.
The main complexity is not the visuals but translating Qlik’s associative engine, script, and Set Analysis into a clean Power BI data model + DAX.
A realistic plan must include:
Assessment of existing Qlik apps and consolidation
Redesign of the data model (preferably star schema)
Rewriting ETL and expressions
UX redesign instead of pixel-perfect cloning
Training for developers, analysts, and end users
If you want, I can help you turn this into a structured forum answer or internal slide with sections: “Myth: Migration vs Reality,” “Technical gaps,” and “Organizational risks.”
If this post helps, then please consider Accepting it as the solution to help the other members find it more quickly
Regards,
Rita Fainshtein | Microsoft MVP
https://www.linkedin.com/in/rita-fainshtein/
Blog : https://www.madeiradata.com/profile/ritaf/profile
