Usage-based rationalisation
All 1,200-plus objects catalogued against real usage, with redundant and obsolete reports retired rather than rebuilt.
BI migration · Business intelligence
From 1,200 QlikView objects to a governed Power BI estate, with no reporting blackout
An inventory and a rationalisation decision per report before any rebuild, business logic moved out of the BI tool into Azure Synapse, and parity proved report by report before each wave went live.
- Client
- Large diversified group, under NDA
- Market
- Brazil
- Duration
- 8 months
- Year
- 2023
- Delivered by
- The group's Brazilian engineering practice, in 2023, before Vigiles AI Ltd was incorporated.
- Objects in scope
- 1,200+
- Catalogued against real usage, then rationalised before rebuild.
- Validated per report
- Parity
- Numbers compared against QlikView and signed off before each cutover.
- Reporting blackout
- Zero
- Both platforms live in parallel until each wave was accepted.
- End to end
- 8 months
- Inventory, warehouse modernisation, rebuild and decommissioning.
More than 1,200 QlikView objects were catalogued against real usage, rationalised, and rebuilt in Power BI on semantic models over an Azure Synapse warehouse. Calculation logic that had accumulated inside the BI tool was lifted into a governed data layer. Every report was validated number by number against QlikView before its wave went live, and the legacy platform stayed available in parallel until each wave was signed off.
On arrival
On arrival
- The group ran more than 1,200 QlikView objects, many of them redundant or obsolete, carrying years of accumulated business logic and almost no documentation.
- Licensing cost and the difficulty of evolving the legacy platform were pushing IT to move to Power BI, but not at the cost of the numbers being trusted less afterwards.
- Source data was scattered with no modern warehouse behind it, so calculation rules were replicated inside each BI application rather than defined once.
- A reporting blackout was not acceptable. The business areas could not be left without their indicators at any point in the transition.
- Parity between QlikView and Power BI was the condition for adoption. A new platform that disagrees with the old one by any margin loses the users on day one.
Approach
Approach
- Inventory and rationalisationAll 1,200-plus QlikView objects were catalogued against actual usage, separating what earns its place from what only accumulates cost. Migrating redundancy is the largest single waste in a BI migration.
- Dependency and business-rule mappingCalculation logic, data sources and dependencies were extracted per report, documenting rules that existed only as implicit behaviour inside QlikView.
- Warehouse modernisation on Azure SynapseSources were centralised into a Synapse warehouse and the calculation rules moved out of the reporting layer into a governed, reusable data layer.
- Rebuild on Power BI semantic modelsReports were rebuilt over semantic models with measures in DAX, so that revenue, margin and the rest had one definition each instead of one per report.
- Parity validation and business sign-offNumbers were compared report by report against QlikView and signed off with the business area before each cutover, rather than after it.
- Phased cutover and controlled decommissioningMigration ran in waves with QlikView live in parallel until final validation, so the legacy platform was switched off deliberately rather than abandoned.
Solution
What was built
- The migration started with what is actually used. The 1,200-plus objects were inventoried and cross-referenced against real usage, which separated the reports that earn their place from the ones that only carried cost. Rationalising first is what stops a migration from faithfully reproducing years of redundancy on a new platform.
- The structural problem was addressed next. Business rules were locked inside the QlikView applications, so the calculation logic and dependencies of each report were extracted and moved into a modern warehouse on Azure Synapse. Scattered rules became one governed, reusable layer.
- With that base, reports were rebuilt in Power BI over semantic models. Measures written in DAX standardised the corporate KPIs, so that revenue, margin and the rest had a single definition, which is what removes the disagreement between reports that quietly erodes trust in the numbers.
- User confidence was earned through parity. Each migrated report was validated number by number against QlikView before it went into production, and the transition ran in waves with both platforms live until sign-off. There was no reporting blackout at any point: the business areas were never without their indicators.
- After eight months the group ran on a modern platform with lower licensing cost, business rules governed in Synapse and KPIs standardised in Power BI. The estate was ready to be developed rather than merely kept alive.
What mattered
What made the difference
Business rules extracted and documented
Calculation logic and dependencies lifted out of QlikView and written down.
Azure Synapse warehouse
Sources and rules centralised into one governed data layer.
Semantic models in Power BI
DAX measures that standardise KPIs and remove duplicated logic between reports.
Parity validated before cutover
Report-by-report comparison against QlikView, signed off by the business area.
Phased cutover with no blackout
Waves with both platforms live in parallel until each was accepted.
Catalogue, lineage and KPI definitions
Documentation produced as part of delivery rather than promised after it.
Licensing cost reduced
Legacy platform decommissioned deliberately once its last wave was validated.
Questions
Common questions
It depends far more on how many reports survive rationalisation than on how many you start with, and on how tangled the source logic is. Large estates typically run six to twelve months. This one covered 1,200-plus objects in eight, in waves.
Parity is validated report by report before the cutover, not after. Each report was compared against QlikView and signed off with the business area before it went live. Discovering a discrepancy after go-live costs the platform its credibility, and that is difficult to recover.
It is not mandatory and it is usually right. Moving business rules into a warehouse such as Azure Synapse stops the logic being replicated inside every report, gives each KPI one definition, and makes the estate governable afterwards. Without it you migrate the original problem.
Yes, with a phased cutover. QlikView stayed available in parallel until each wave was validated, so no business area lost its indicators during the transition. The legacy platform was then switched off in a controlled way rather than simply abandoned.
Next step
Arrange a technical review
A 45-minute working session with an engineer rather than a sales call. You describe the problem; we set out what we would build, in what order, and what it is likely to cost.
Answered within one working day, by the engineer who would do the work