Qlik to Power BI: Migration Best Practices¶

Audience: Project managers, BI leads, migration architects Purpose: Proven patterns for successful Qlik-to-Power BI migrations Reading time: 15-20 minutes

1. Migration strategy: report-by-report plan¶

1.1 Do not migrate everything¶

The first best practice is the most counterintuitive: do not migrate all Qlik apps. Most Qlik deployments follow an 80/20 rule:

• 20% of apps get 80% of usage
• 30-50% of apps have not been opened in 90+ days
• 10-20% of apps are duplicates or personal copies

Migration triage categories:

1.2 Wave planning¶

Each wave should follow this sequence:

1. Data layer -- ensure Gold tables exist for the apps in this wave
2. Semantic model -- build or extend the shared semantic model for this domain
3. Expression conversion -- port all Qlik expressions to DAX measures in the semantic model
4. Report build -- create Power BI reports consuming the shared semantic model
5. Validation -- side-by-side number comparison with Qlik
6. User acceptance -- app owner signs off
7. Cutover -- redirect users, disable Qlik app reload
8. Monitoring -- track Power BI usage metrics for 2 weeks

1.3 Effort estimation model¶

Apply this formula: Total migration effort = (Simple x 1.5d) + (Medium x 4d) + (Complex x 7.5d) + (Very Complex x 15d)

2. Data architecture best practices¶

2.1 Build the semantic layer first¶

The most common mistake in Qlik-to-Power BI migrations is converting apps one-by-one without building a shared semantic layer. In Qlik, each app has its own data model. In Power BI, shared semantic models provide a single governed definition of measures and relationships.

Best practice: Before converting any apps, build domain-level shared semantic models on CSA-in-a-Box Gold tables:

Multiple Power BI reports can then consume the same semantic model, replacing the per-app data model duplication that Qlik creates.

2.2 Use Direct Lake, not Import¶

For CSA-in-a-Box deployments, the target connectivity mode is Direct Lake (not Import):

2.3 Eliminate QVD-to-QVD chains¶

In Qlik, QVD chains (raw QVD -> transformed QVD -> aggregated QVD -> app) are the de facto data pipeline. In the target architecture:

• Raw QVDs -> Bronze layer (ADF ingestion to ADLS Gen2)
• Transformed QVDs -> Silver layer (dbt models to Delta Lake)
• Aggregated QVDs -> Gold layer (dbt models to OneLake)
• App data model -> Shared semantic model (Direct Lake on Gold)

Never recreate QVD chains using Power BI Import datasets. This trades one extract pipeline for another. The CSA-in-a-Box medallion architecture with Direct Lake eliminates the entire concept of BI-layer data caching.

3. User training best practices¶

3.1 Training curriculum for Qlik users¶

3.2 Addressing the selection model gap¶

The single biggest user complaint in Qlik-to-Power BI migrations is the loss of associative selections (green/white/gray). Address this proactively:

Day 1 training topic: Explain the difference between associative selections and cross-filtering. Use this framing:

• In Qlik: "I select a value and the engine shows me everything related. I explore by clicking."
• In Power BI: "I use slicers to filter, and the visuals update based on the defined relationships. I explore by asking Copilot or using Q&A."

Design patterns that mitigate the gap:

1. Rich slicer panels -- add slicer visuals for every dimension users commonly filter by
2. Cross-filtering configuration -- set Edit Interactions so that clicking a bar/point filters other visuals (not just highlights)
3. Q&A visual -- add a Q&A visual to every report so users can type natural language questions
4. Copilot -- train users to ask Copilot "What factors influenced this metric?" instead of clicking through associative selections
5. Clear All button -- add a "Reset" bookmark button so users can clear all filters with one click

3.3 Champions program¶

3.4 Common Qlik-user complaints and responses¶

4. Governance framework¶

4.1 Workspace governance¶

4.2 Semantic model governance¶

4.3 Purview integration¶

5. Copilot adoption strategy¶

5.1 Copilot use cases for migrating Qlik users¶

5.2 Copilot rollout phases¶

1. Phase 1 (Week 1): Enable Copilot for the BI team and champions only
2. Phase 2 (Week 3): Enable for all report creators with training
3. Phase 3 (Week 6): Enable for all consumers with guided documentation
4. Phase 4 (Ongoing): Collect feedback, share best practices, publish prompt guides

6. CSA-in-a-Box Fabric integration¶

6.1 The optimal data flow¶

flowchart LR
    SRC[Source Systems] --> ADF[ADF Pipelines<br/>Bronze ingestion]
    ADF --> BRONZE[Bronze Layer<br/>ADLS Gen2 / OneLake]
    BRONZE --> DBT[dbt Models<br/>Silver + Gold]
    DBT --> GOLD[Gold Layer<br/>Delta tables in OneLake]
    GOLD --> DL[Direct Lake<br/>Semantic Model]
    DL --> RPT[Power BI Reports]
    DL --> PAGINATED[Paginated Reports]
    DL --> COPILOT[Copilot / Q&A]
    DL --> EXCEL[Analyze in Excel]
    GOLD --> PURVIEW[Purview<br/>Lineage + Classification]

6.2 Integration best practices¶

6.3 Performance optimization¶

7. Post-migration operations¶

7.1 Health metrics to track¶

7.2 Decommission timeline¶

8. Anti-patterns to avoid¶

The most common migration anti-pattern is recreating every Qlik app as a separate Power BI report with its own semantic model. This recreates the per-app data duplication problem in a new tool. Build shared semantic models first, then create multiple lightweight reports on top.

Some migration teams replace QVD files with Power BI Import datasets that refresh on schedule. This is architecturally identical to the Qlik pattern and carries the same problems (stale data, refresh failures, storage sprawl). Use Direct Lake instead.

Qlik's associative model allows any table structure. Power BI requires star schemas for optimal performance. Skipping the data model redesign step results in slow queries, incorrect DAX results, and frustrated users.

If measures are defined in individual reports instead of the shared semantic model, you lose the governance benefit of centralized measure definitions. Every measure should live in the semantic model.

Users who loved Qlik's green/white/gray selections will be vocal about the loss. Address this proactively in training. Do not dismiss the concern -- acknowledge the difference and provide alternatives (slicers, cross-filtering, Copilot, Q&A).

NPrinting reports often serve operational users with strict formatting requirements (invoices, compliance reports, distribution schedules). Convert these carefully with full stakeholder validation. A broken operational report causes more organizational pain than a missing dashboard.

Cross-references¶

Maintainers: CSA-in-a-Box core team Last updated: 2026-04-30