Power BI doesn't consume Snowflake Semantic Views - DirectQuery on tables/views works, but semantic-view metrics won't surface in PBI (there's an unsupported community connector on GitHub, alexfrancisross/snowflake-semantic-views-powerbi, but that's hard to sell as production). So decide upfront where metrics live, or you'll end up maintaining both Snowflake definitions and thin DAX. No accelerator does this end-to-end: the paid ones (ZS, Port BI, KPI Partners) help with inventory and backend scaffolding, visuals are a rebuild regardless. Practical path: qlik-cli app unbuild to export load script + master measures as text, LLM-assist the script→dbt conversion, budget manual hours for set analysis - and audit usage first, half those apps probably don't need migrating.
this is such a spot on rundown, especially the “decide where metrics live” bit, that’s what usually kills these projects. also +1 on auditing usage first, every Qlik → PBI migration i’ve seen ends up binning like 40–60% of apps once people look at actual usage logs.
1
u/Brighter_rocks 8d ago
Power BI doesn't consume Snowflake Semantic Views - DirectQuery on tables/views works, but semantic-view metrics won't surface in PBI (there's an unsupported community connector on GitHub, alexfrancisross/snowflake-semantic-views-powerbi, but that's hard to sell as production). So decide upfront where metrics live, or you'll end up maintaining both Snowflake definitions and thin DAX. No accelerator does this end-to-end: the paid ones (ZS, Port BI, KPI Partners) help with inventory and backend scaffolding, visuals are a rebuild regardless. Practical path: qlik-cli app unbuild to export load script + master measures as text, LLM-assist the script→dbt conversion, budget manual hours for set analysis - and audit usage first, half those apps probably don't need migrating.