Estate inventory and usage analysis
Every report, dashboard and extract catalogued with real usage telemetry, owner, data sources and business criticality. Usage data settles arguments that opinion cannot.
BI migration
BI migration to the Microsoft stack
Structured migration from legacy BI platforms, with rationalisation and a reconciled cutover.
- A rationalised report set, typically far smaller than the one you started with
- Business logic consolidated into a governed semantic model instead of scattered across reports
- Documented reconciliation between old and new before any switch-off
- Licence and maintenance costs released on a known date
A migration that recreates every existing report is a migration that fails twice: once on budget, and again on adoption. In every estate we have inventoried, a large share of reports have no regular audience, and a meaningful share are near-duplicates of each other.
So we start with an inventory and a rationalisation decision per report: migrate, merge, replace with self-service, or retire. Then we extract the business logic, the calculations buried in Qlik scripts, Tableau calculated fields, Cognos framework models or BusinessObjects universes, and rebuild it once in a semantic model rather than report by report.
The cutover runs in parallel with reconciliation evidence, so the business sees matching numbers in both systems before the old platform is switched off. That is slower than a flag-day cutover, and it is the reason our migrations do not get rolled back.
What we deliver
What the work involves
Rationalisation workshops
Decisions made with the business, report by report: migrate, merge, replace with a self-service model, or retire. Recorded with the name of the person who agreed.
Logic extraction
Calculations lifted out of Qlik load scripts, Tableau calculated fields, Cognos framework manager models, BusinessObjects universes, MicroStrategy schemas and SSRS datasets, then expressed once as documented DAX or SQL.
Rebuild on the target platform
Semantic model first, then reports. Native Power BI patterns rather than a pixel-copy of the old tool, because a straight visual translation imports the previous platform's limitations.
Parallel run and reconciliation
Both platforms live for an agreed period, with automated comparison of key figures and a documented variance log. Nothing is switched off on trust.
Decommissioning
Licence wind-down planning, archival of historical outputs for audit purposes, access revocation and a final cost-saving statement.
Method
How the engagement runs
Each stage names the artefact it produces, so progress can be checked without a status meeting.
Inventory
Automated extraction of the report catalogue plus usage logs, consolidated into one register.
Full estate register with usage and criticality
Rationalise
Disposition agreed per report with named business owners; scope fixed on evidence.
Signed rationalisation decisions and migration backlog
Design the target
Target semantic model and workspace design derived from the surviving reports, not from the old folder structure.
Target architecture and model design
Migrate in waves
Delivery in waves by business area, each wave reconciled and signed off before the next begins.
Wave releases with reconciliation evidence
Cut over and decommission
Parallel period, switch-off, archive, licence termination.
Cutover record and realised saving statement
Deliverables
Deliverables
- Estate register with usage telemetry and disposition per report
- Business logic catalogue mapped from source platform to target
- Target semantic model and workspace design
- Migrated reports delivered in signed-off waves
- Reconciliation pack per wave, including explained variances
- Decommissioning and archive plan
- Licence saving statement with dates
- Training for report authors on the new platform
Stack
Technologies
- Power BI
- Microsoft Fabric
- Tabular Editor
- Power Query / M
- SQL Server
- Qlik Sense
- Tableau
- IBM Cognos
- SAP BusinessObjects
- MicroStrategy
- SSRS / Paginated reports
Questions
BI migration: common questions
Inventory and rationalisation take about four weeks for a typical mid-sized estate. The rebuild depends almost entirely on how many reports survive rationalisation and how tangled the source logic is: a 60-report estate with clean sources can be done in three months, while a 900-report BusinessObjects estate with a decade of undocumented universes is a year-plus programme. We give a wave-by-wave estimate after the inventory, not before.
No, deliberately. A pixel-for-pixel copy carries over the old tool's workarounds and usually costs more to build and maintain. We keep the information content and the numbers identical, and redesign the presentation to native patterns. Where a report genuinely must look unchanged, a regulatory return, for example. We say so and build it that way.
Automated reconciliation during the parallel period: the same measures pulled from both platforms for the same periods and dimensions, compared, with every variance either corrected or explained in writing. Several variances we find turn out to be errors in the legacy report. Those get documented too, because someone has been making decisions on them.
Yes, and we recommend it. Waves by business area let each group validate its own numbers, and let you stop or re-sequence if priorities change. The cost is a period of dual licensing, which we plan for explicitly so it does not come as a surprise in the budget.
They get archived as rendered outputs (PDF or Excel with metadata) in an immutable store with an agreed retention period, rather than kept alive by paying for a legacy platform licence. The archive plan is agreed with whoever owns your retention policy before anything is switched off.
Related
Power BISemantic modelling, DAX and report delivery with one agreed definition per measure.GovernanceOwnership, cataloguing, classification and access evidence, implemented in the tools teams already use.Microsoft FabricLakehouse architecture sized against measured consumption rather than headcount.
Sector context: Financial services, Manufacturing, Retail, Healthcare, Logistics.
Next step
BI migration: what the next step looks like
A fixed-price inventory. You keep the register whatever you decide next
Answered within one working day, by the engineer who would do the work