Rationalizing a Sprawling BI Estate — From QlikView Legacy to a Unified Power BI Platform
Led the consolidation of a fragmented BI environment spanning QlikView, legacy Power BI, and direct Snowflake/Databricks queries into a governed Power BI platform with shared semantic models and standardized deployment pipelines.
Retired 47 QlikView reports and consolidated 80+ Power BI assets onto 4 shared semantic models
Cut average new-report delivery time by 25–30% via reusable visual templates and shared measures
Established CI/CD for BI using Azure DevOps with deployment pipelines for dev/test/prod environments
Reduced report-related production incidents by approximately 30% through standardized testing and review gates
The brief
The client was a multinational retail execution organization that had grown its BI estate through acquisition and ad-hoc tool selection. The result, by the time I joined, was a roughly 50/50 split between QlikView (legacy, with a license cliff approaching) and Power BI, with a smattering of bespoke Snowflake-direct dashboards built by power users. Definitions of core retail KPIs — store-level sell-through, planogram compliance, field force productivity — varied across reports. Quarterly business reviews consumed disproportionate analyst time reconciling numbers between sources.
The mandate had two parts: retire the QlikView estate before license expiry, and bring the resulting unified Power BI footprint under coherent governance.
The architecture
The temptation in a migration program is to lift-and-shift — recreate each QlikView report as a Power BI equivalent. We refused this at the outset, and I think it was the most consequential decision of the engagement.
Inventory and rationalize first. We spent the first eight weeks not building anything, but cataloging every report across both platforms — usage telemetry, business owner, KPIs covered, source systems consumed. The catalog made it possible to identify duplication: of the 47 QlikView reports, only 22 had distinct purpose. The rest were variants serving overlapping audiences. We rationalized to 22 capability requirements, not 47 reports.
Four semantic models, not forty. Mapping the rationalized requirements to data domains gave us four logical analytical surfaces: Sales Execution, Field Force, Inventory & Replenishment, and Trade Promotion. We built one Power BI shared semantic model per surface, sourced from the existing Snowflake warehouse with Databricks for heavier transformations. Reports became thin consumers of these models.
Standardized visual library. A small but consequential investment: a Power BI template (.pbit) with the client’s design system, standard slicers, formatted KPI cards, and a tested set of visual patterns. Every new report started from this template. Consistency stopped being a governance ask and started being the path of least resistance.
Deployment pipelines as the only path to production. We integrated Power BI deployment pipelines with Azure DevOps, with mandatory peer review and a tested workspace tier separating dev from production. Direct production publish was disabled. This was politically harder than it was technically — many report developers had grown accustomed to ship-and-pray workflows — but the production incident rate dropped meaningfully within a quarter.
What worked
The rationalization-first approach turned a 47-to-1 migration into a 22-to-1 migration, and the savings compounded everywhere downstream. Less to migrate, less to maintain, fewer KPIs to reconcile.
The shared semantic models did exactly what the architecture promised: when the finance team revised the definition of “Net Trade Spend” mid-engagement (this happens; finance teams are gonna finance), the change was made in one place and propagated to every consuming report automatically. We benchmarked the change effort against an equivalent change pre-migration; the new architecture cost roughly 1/20th the analyst time.
The Power BI template library reduced new-report development time by 25–30% on average across the team. The headline number, however, was less interesting than the second-order effect: junior developers could now produce reports that looked like they belonged on the same platform as senior developers’ work. The visual quality floor came up.
What didn’t, the first time
We initially tried to migrate the most-used QlikView reports first, on the assumption that they were the most validated and would migrate cleanly. This was wrong. The most-used reports were also the most accreted with bespoke logic, and they fought the new model. We pivoted to migrating the cleanest reports first — the ones with simple metric definitions and clear ownership — to build out the semantic models, then tackled the messy heavy hitters last. This sequencing was much better.
We also underestimated the change management for the deployment-pipeline mandate. Several teams felt their velocity had been reduced. The fix was twofold: reduce the friction of the pipeline itself (faster automated checks, lighter peer-review process for low-risk changes) and make the production incident reduction visible at the leadership level so the velocity tradeoff was contextualized properly.
Where it landed
By project close, the QlikView estate was retired ahead of the license expiry, the Power BI platform had been consolidated to four shared semantic models with roughly 80 reports consuming them, and the CoE governance model was operating without daily intervention from the consulting team. Total cost of ownership for the BI estate dropped, and the analyst headcount that had been absorbed in the maintenance treadmill was redeployed to net-new analytical work.
The piece I’m most pleased with, two years on, is that the semantic models we built then are still serving the business, largely unchanged. That is the test for this kind of work — not whether it shipped, but whether it survived contact with the next three years of organizational change.
Technology Stack