We decided to move a Power BI report to Qlik. How do we prove nothing changed on the way?

lab build · Oct 2026 The family end to end

The same method, the other way. The team has chosen Qlik as the target, and a Power BI report has to move there with its numbers intact. ade-ops reads the Power BI semantic model and the report definition: tables, relationships, measures, pages and visuals. Each DAX measure becomes a Qlik expression by rule, with Power BI's semantics kept: a KEEPFILTERS filter becomes an intersection in set analysis, an AVERAGEX over customers becomes an Aggr that takes the chart's own dimensions. What has no faithful rule is refused, with the reason, never guessed. Relationships become Qlik associations, the data is extracted, and a new Qlik Sense app is built with the same sheets. Then the proof: every measure on every slice, the value from the published Power BI model against the value the live Qlik engine returns. 154 of 154 cases match. This was proven on our own round trip: the Power BI model is the one ade-ops generated from a Qlik app, so its DAX is the regular kind our own translator writes.

ade-ops · operate

What it does not show

It does not convert any Power BI report. The input is the friendly DAX that ade-ops itself wrote, not a model a person built in Power BI Desktop.
Refused today, with the reason listed: plain CALCULATE filters, iterators over expressions such as SUMX with RELATED, time intelligence, inactive relationships with USERELATIONSHIP, calculation groups, ALL / ALLEXCEPT / REMOVEFILTERS, SWITCH and SELECTEDVALUE, RANKX and TOPN, calculated columns and tables, and bidirectional or many-to-many relationships.
On the report side, only cards, line, column, bar, donut and pie charts, tables and slicers are rebuilt. Bookmarks, drillthrough, field parameters, conditional formatting and hierarchies are not.
Row-level security becomes a design item (Section Access), not generated code.
A Qlik association filters both ways where Power BI filters one way. The numbers agree here because every slicer sits on a dimension table. The difference is declared, not hidden.
The same method runs from Qlik to Power BI too: see that journey. Neither direction is a recommendation of a platform.

Transcript

0:00 We decided to move a Power BI report to Qlik. How do we prove nothing changed on the way?
0:06 The setting: a Power BI report on a Databricks model, in a demo workspace. Synthetic data.
0:15 ade-ops reads the semantic model and the report: tables, relationships, measures, pages
0:24 Each DAX measure becomes a Qlik expression by rule, keeping Power BI's semantics
0:37 Proven on our own round trip: what a hand-written model uses is refused, with the reason
0:46 A new Qlik Sense app, built from the report: same sheets, same figures
0:53 The detail sheet: same table, same totals
0:57 Parity: 154 of 154 cases match the live Qlik engine
1:10 The same check, the other way.
1:10 Proven on our own round trip, not on any Power BI report. A Qlik association filters both ways where Power BI filters one way: declared, not hidden.
1:10 ade-ops · lab build, experimental · proven on our own round trip · AI voice · synthetic data · recorded 2026-10-18

ade-ops lab build (experimental: proven on our own round trip) · AI voice · a Power BI demo workspace on a Databricks demo model, a Qlik Cloud demo tenant · synthetic data · recorded 2026-10-18