A Qlik to Power BI migration is a rebuild, not a translation. The hard-won lessons on data models, measures, security and expectations, before you start.

Qlik to Power BI: lessons learned the hard way

Plenty of organisations are moving from Qlik to Power BI, usually for sound reasons: licensing, the gravity of the wider Microsoft and Fabric estate, or simply that the people who built the original Qlik apps left years ago and took the knowledge with them. We have done a fair few of these now. Almost every painful moment came from the same root error, treating the move as a translation when it is, in truth, a rebuild. Here is what we wish we had known on day one, set down so you can skip the tuition fees.

In practice, this is where our Power BI service comes in, and What Fabric data apps change, and what they don't covers useful related ground.

Do not copy the Qlik data model

This is the big one. Qlik's associative engine is forgiving. It will cheerfully work with a wide, flat or oddly-joined model that Power BI will punish with slow reports and confusing results. Power BI wants a proper star schema: clean facts and dimensions, sensible relationships. Lifting the Qlik model straight across is the single commonest cause of a migrated report that technically runs and performs like treacle. Draw the target model as a star schema, on paper, before you build anything.

Do not transliterate set analysis into DAX

Set analysis and DAX solve similar problems in genuinely different ways. Converting a Qlik expression clause by clause produces DAX that is slow, occasionally wrong, and unmaintainable by the next person. Rewrite the measures that matter from the business definition, what the number is meant to mean, not from the old syntax. More work up front, far less work forever after.

Stop promising a pixel-perfect copy

Qlik users live in the associative model, the green, white and grey selection behaviour where you click anything and the whole app responds. Power BI does not filter the same way, and some of Qlik's native objects have no clean equivalent. Let stakeholders believe they are getting an identical experience and you will relive their disappointment in every review meeting. Set the expectation in the first conversation: this is a better tool, not a tribute act.

Redesign the security, do not port it

Qlik's section access is not Power BI row-level security. Map one onto the other rule by rule and you tend to produce gaps you only find when the wrong person sees the wrong number. Treat access as a fresh design built on who should see what, not a migration of the old logic.

Distrust the one-click converter

Tools that promise to convert Qlik apps to Power BI automatically will hand you something that opens and runs. It will also be a thicket nobody wants to own. A migration is your one clean chance to leave the cruft behind, and an automated translation carries every bad habit across intact.

Move what people use, prove it in parallel

Two truths every Qlik team forgets. Pull the usage data before you build, and migrate only the apps people actually open, because the rest is mostly history nobody will mourn. And run old and new side by side for a while, reconciling the numbers out loud, week after week, until trusting the new reports becomes dull. Trust is not handed over on a go-live date. It is earned in parallel.

We did exactly this recently for a UK health and case-management provider retiring an ageing Qlik estate. We rebuilt the reports that carried the real decisions on a clean Power BI model, integrated the pipelines properly rather than porting the old load logic, and ran the two side by side until the numbers stopped surprising anyone. What they ended up with was smaller, faster and better trusted than what it replaced, which is the whole point. A migration done well leaves you with less, not a like-for-like copy of more.

The one move that saves the most

Before you touch a single app, do three things. Get the usage stats, so you know the handful worth moving. Draw the target model as a star schema on paper. And rewrite your top measures from their business definitions rather than their old syntax. Nail those three and the build is straightforward. Skip them and you will build it twice.

This is exactly how we run Power BI migrations, often onto the wider Microsoft Fabric platform: rebuild the few things that matter properly on a clean model, prove them in parallel, and leave the rest behind. Qlik served you well. The mistake is asking Power BI to impersonate it. Let it be the better tool it already is.

If any of this sounds familiar, talk to us about your data.

Qlik To Power BI: Lessons Learned The Hard Way