Best Practice Qlik -> Power BI Migration

Hi NatalieGraham​ 

I have done a similar migration in the past and there is quite a bit of functionality in Qlik that is not available in Power BI. So it first work with your users to understand what features they use today that they would like to use in future. Once that is done or then highly recommend doing a pilot to make sure that the new users are comfortable and know how to use Power BI. Once the pilot and training is successful then move on to migrating the rest of the reports.

Hi NatalieGraham​ ,

Migrating 30 + HR dashboards from Qlik to Power BI is best handled through a proper phased rollout rather than a single high-risk release.

1. Phased Release Strategy

Pilot (3–5 Dashboards): Select a mix of complexity levels and departments (e.g., Talent Acquisition, Total Rewards) to validate data accuracy, security/RLS, and usability with a small group of HR users. 

Rollout Waves: Group remaining reports by function and readiness:  

Wave 1: Talent Acquisition 

Wave 2: Total Rewards 

Wave 3: Employee Listening 

Wave 4: Broad audience & remaining dashboards (Adjust order based on business priorities and dependencies rather than rigid departmental silos). 

2. Best Practices & Lessons Learned

• Parallel Run: Keep Qlik and Power BI running concurrently to cross-check KPIs, totals, and business logic. 

• Clear Acceptance Criteria: Require data reconciliation, performance checks, and formal business sign-off before each wave. 

• Value-Driven Priority: Prioritize business impact, not dashboard volume. 

• Enablement & Tracking: Provide role-based training and monitor adoption via Power BI metrics. 

• Clean Retirement: Only sunset Qlik after full validation and a communicating end date. 

3. Critical Security Check

HR data is highly sensitive. Thoroughly audit sharing permissions, sensitivity labels, and row-level security (RLS) before publishing broad-audience dashboards. 

Summary: Start with a focused pilot, move in controlled waves using a standard checklist, and treat each release as a learning milestone rather than one massive deployment. Business users might face some functionality differences in Qilksense and PowerBI, for that use only some pilot or test report show those to business users first and get acceptance first. Thanks

If this helps, ✓ Mark as Kudos | Help Other

NatalieGraham​ Hi! 

Microsoft has published Skills for Fabric (https://github.com/microsoft/skills-for-fabric). It's an open-source set of skills for AI coding agents such as GitHub Copilot CLI, VS Code and Claude Code. The Power BI authoring bundle includes skills for semantic model authoring and Power BI reports (PBIP).

In practice, you can give the agent your Qlik load scripts and chart expressions and ask in natural language for things like:

• "Build a Power BI semantic model from this Qlik load script, with a star schema, relationships and DAX measures equivalent to these set-analysis expressions."
• "Create a Power BI report with these pages and visuals, matching this Qlik sheet."

It produces the model and the report as PBIP/TMDL files that you can review, version in Git and deploy. It's not a one-click converter: you still need to validate the logic, the RLS and the numbers. But it removes much of the manual rebuild work, which matters a lot with 30+ dashboards. It's also a good fit for a pilot-then-waves plan, because once the pilot has proven your patterns you can reuse the same prompts in each wave.

Hope this helps, and good luck with the migration!
BBF

I recommend a phased rollout rather than releasing all 30+ dashboards at once.

- Pilot: Release 3–5 dashboards to selected HR users and validate data accuracy, performance, and security.

- Phased releases: Roll out by business area—Talent Acquisition, Total Rewards, and Employee Listening.

- Broad audience: Release remaining dashboards after resolving pilot feedback.

- Best practice: Test RLS carefully, especially for sensitive HR and compensation data, and keep Qlik available temporarily as a fallback.

This approach reduces risk and improves user adoption

Hi NatalieGraham​ , Please check the below thread for the Qlik to Power BI challenges faced by previous developers.

Qlik Sense to Power BI challenges | Microsoft Fabric Community

For the Release plan please consider these steps

1. Start with a pilot of 3-5 dashboards, one broad-audience and one or two sensitive ones, so you catch security, performance and adoption issues early.
2. Then release in waves by audience. Talent Acquisition is usually a friendly group to begin with, and the broad-audience dashboards can wait until things are stable.
3. Keep Qlik and Power BI running in parallel for a few weeks, and reconcile the numbers before you switch Qlik off. Otherwise you will hear “arre, this doesn’t match Qlik!” on day one.
4. Check Qlik usage stats before migrating. Many dashboards are hardly used, so retire them instead of migrating everything.
5. Fix the metric definitions (headcount, attrition, etc.) and get RLS signed off by data owners before go-live. This saves a lot of back and forth later.

Hi NatalieGraham​,

I'd go phased, but release by data domain rather than picking dashboards at random. Dashboards that share data (e.g., all Talent Acquisition ones) should sit on one shared semantic model. Once that model is validated, the dashboards on top of it are low risk and can go out together.

Before building anything, check usage in Qlik (the Operations Monitor app or the session logs). With 30 HR apps, it's common to find several that nobody opens, and those can be retired instead of migrated.

For the first wave, pick one domain with an engaged owner and a medium audience. Total Rewards or Employee Listening often fit better than the broad-audience ones. Run Qlik and Power BI side by side for a cycle or two, and reconcile the key numbers with a small set of DAX queries you can rerun every refresh:

EVALUATE
SUMMARIZECOLUMNS(
    'Date'[Year Month],
    'Org'[Business Unit],
    "Headcount", [Headcount],
    "Hires", [Hires],
    "Terminations", [Terminations]
)
ORDER BY 'Date'[Year Month], 'Org'[Business Unit]

Export the same grid from Qlik and diff them. Counting logic (as-of-date headcount, rehires, contingent workers) is where HR migrations usually drift, because Qlik set analysis and DAX filter context behave differently.

Because it's HR data, design the security model in that first wave too: RLS by org hierarchy, plus small-cell suppression for engagement survey results. Retrofitting that across 30 reports later is painful.

So my overall approach would be:

Usage audit in Qlik -> retire unused apps
Group remaining dashboards by data domain -> one shared semantic model each
Wave 1: one domain, engaged owner, parallel run + DAX reconciliation
Security (RLS, survey suppression) designed in wave 1
Next waves per domain -> broad-audience dashboards last -> decommission Qlik app per wave

AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.

Hi NatalieGraham​,

Thank you for reaching out to Microsoft Fabric Community.

Thank you Murtaza_Ghafoor​, DaniyalKhaleel1​, BeaBF​ and jubinsoni​ for the prompt response.

As we haven’t heard back from you, we wanted to kindly follow up to check if the solution provided by the user's for the issue worked? or let us know if you need any further assistance.

Thanks and regards,
Anjan Kumar Chippa

Hi NatalieGraham​,

We wanted to kindly follow up to check if the solution provided by the user's for the issue worked? or let us know if you need any further assistance.

Thanks and regards,
Anjan Kumar Chippa