A QlikView to Power BI migration rarely fails because a chart cannot be recreated. It fails when the programme treats each sheet as the system and overlooks the QVDs, load scripts, Set Analysis, variables, security rules and manual processes that make the numbers work.
The most useful first deliverable is therefore not a new dashboard. It is an evidence-based assessment of the Qlik estate: what is used, where the logic lives, which outputs are trusted and what should not be carried into Power BI at all. This applies whether the estate is QlikView, Qlik Sense or a mix of both: the underlying problem is the same, with business logic hidden outside the visible sheet.
Migration is a redesign, not a screen conversion
Qlik and Power BI can answer the same business questions, but they organise data, calculations, security and distribution differently. A pixel-for-pixel rebuild can preserve duplicated reports and years of local workarounds while producing a Power BI estate that is harder to support than the Qlik environment it replaced.
I begin by separating three things: business requirements that must survive, technical patterns that need redesign and content that can be retired. That gives stakeholders continuity without making the target architecture imitate the source.
1. Catalogue the estate and prove what is used
An application inventory should record each QlikView document and Qlik Sense app, its owner, audience, refresh schedule, data sources, dependencies and recent usage. Similar applications should be grouped so the assessment can reveal where several teams maintain slightly different versions of the same report.
Usage data is important, but it is not the only test. A month-end finance app may be essential despite being opened only a few days each month. Conversely, a frequently opened landing page may contain little business logic. The inventory needs both operational evidence and a named business owner.
2. Trace QVDs, load scripts and source dependencies
The visible application can be the final step in a long chain. A QVD may feed several apps. A load script may apply mappings, concatenate extracts, generate calendar fields or repair source-system issues. Scheduled jobs and file drops may be understood by only one person.
I map that lineage before choosing the Power BI target. Shared transformations belong in a governed data layer rather than being copied into every semantic model. Microsoft Fabric may be appropriate when the programme needs reusable ingestion, Lakehouse or Warehouse storage and common curated outputs; it should not be introduced merely because Power BI is the reporting tool.
3. Redesign the associative model as an explicit semantic model
Qlik’s associative model and Power BI’s tabular model create different filter behaviour. A model that works naturally in Qlik may contain circular references, synthetic keys or field structures that do not translate cleanly into a Power BI star schema.
The migration assessment should identify the business grain of each fact, the shared dimensions, slowly changing attributes and required security filters. The target semantic model then expresses those choices deliberately. This is also the point to decide whether several Qlik apps should share one Power BI model rather than each receiving its own copy of customer, product, calendar and finance logic.
4. Translate the definition, not only the Set Analysis
Set Analysis, variables and expressions often contain the real business rules. Direct translation into DAX can be misleading because context works differently and the original expression may combine a valid definition with a Qlik-specific workaround.
For every important measure, I record the plain-English definition, source fields, exclusions, time logic and expected control totals before writing DAX. Stakeholders approve the definition rather than a syntax conversion. Reusable measures and calculation groups can then replace repeated expressions while preserving the agreed result.
5. Rebuild security and distribution deliberately
Section Access in QlikView and Qlik Sense does not become Power BI row-level security automatically. User identifiers, group membership, reduction fields, exceptions and service accounts need to be mapped and tested against the target identity model. Object visibility and workspace access may require separate decisions.
Distribution also changes. Qlik bookmarks, exports, NPrinting outputs, email routines and shared links may be part of a business process even when they are absent from the dashboard specification. The target must cover how users receive, filter, export and discuss the information, not only how it looks on screen.
6. Rationalise reports before rebuilding them
A migration is one of the few moments when an organisation can remove reporting duplication with stakeholder attention and budget already available. Applications can be placed into four groups: retire, consolidate, redesign or reproduce. Each decision should have an owner and reason.
| Assessment area | Evidence to collect | Target decision |
|---|---|---|
| Usage and ownership | Open frequency, audience, critical reporting dates, named owner | Retire, combine or migrate |
| Data dependencies | Sources, QVD lineage, load scripts, schedules and failure handling | Power Query, Dataflows, Fabric or another governed layer |
| Calculations | Set Analysis, variables, definitions and control totals | DAX measures, calculation groups and upstream logic |
| Security | Section Access, identities, groups and exception users | Workspace access, row-level and object-level security |
| User journey | Sheets, bookmarks, exports, subscriptions and manual steps | Power BI reports, apps, paginated outputs and process changes |
7. Define reconciliation before the first release
Visual similarity is not acceptance evidence. Reconciliation should cover control totals, detailed exceptions, date boundaries, filters, null handling, currency logic and security. The test pack needs agreed baselines from Qlik and named owners for differences.
Qlik and Power BI should run in parallel for a controlled period. Each reporting domain can be signed off before the corresponding Qlik application is retired. This reduces the risk of a single cutover and gives users time to learn the new report journeys without maintaining both platforms indefinitely.
What a useful migration assessment delivers
- An application, data-dependency and usage inventory
- A heatmap of business value, complexity, risk and ownership
- A catalogue of important calculations and security rules
- A target Power BI and, where justified, Microsoft Fabric architecture
- A report rationalisation decision for each application
- A prioritised wave plan with dependencies and acceptance criteria
- A reconciliation, coexistence and decommissioning approach
The assessment replaces a hopeful list of screens with a defensible delivery plan. It also gives procurement and programme sponsors a clearer basis for estimating effort because the hidden data and business logic have been exposed before rebuild work starts.
Start with the logic people trust
The best QlikView or Qlik Sense to Power BI migration preserves trusted definitions and useful decisions while removing technical and reporting debt. That requires understanding the estate before choosing the first dashboard to rebuild.
See the full Qlik to Power BI migration service, the wider Power BI consultancy approach and Microsoft Fabric implementation options. To discuss an assessment for your Qlik estate, contact Business Intelligence Atlas.
Comments are closed