A specialty insurer we worked with had 460 dashboards across Power BI, Tableau and Qlik. They knew they had too many. They had no idea how many were still being used, or which contradicted which. Six months later the estate was 72 dashboards, the licence spend was down 38%, and adoption was up 2.1×. The principles below travelled well to the other BI estates we have since rationalised.
Why BI estates grow the way they do
Every enterprise BI estate has the same life cycle: a platform is adopted; analysts are enabled; dashboards proliferate; nobody is allowed to retire anything; usage fragments; a second platform is bought to fix it; the process repeats. By the time anyone counts, the organisation is running three platforms and four hundred dashboards, and nobody knows which metrics are authoritative.
The usage audit is the whole game
You cannot make good retirement decisions without telemetry. Every modern BI platform emits it; almost nobody uses it. The usage audit we run on every engagement produces three numbers that always surprise clients:
The numbers are remarkably consistent across sectors. The implication is blunt: the top 5–10% of dashboards serve the vast majority of real business decisions, and most of the rest are organisational furniture.
The rationalisation protocol
Phase 1 — instrument
Turn on and extract usage telemetry from every BI platform in scope. Build a single register of dashboards, their authors, their last modification date, their user count, their session duration, and their business domain.
Phase 2 — classify
Four buckets, by honest review with business owners:
- Keep. Used, trusted, decision-supporting. These will be rebuilt on the semantic layer.
- Retire. Not used, or superseded. Communicate, sunset, delete.
- Consolidate. Several versions of the same thing. Pick one; retire the rest.
- Investigate. Contested. Small enough bucket to handle case-by-case.
The "Retire" bucket is almost always larger than stakeholders expect. The "Keep" bucket is always smaller.
Phase 3 — rebuild on a semantic layer
Every dashboard in the "Keep" bucket is rebuilt on a metric layer — we use dbt's metric layer, or Cube, depending on stack — so that every KPI has a single definition, a version history, and a named owner. This is the step that prevents the estate re-fragmenting in eighteen months.
Phase 4 — communicate retirement
Four weeks of notice. Named owners sign off. A last-chance review window. Then retire. Publish a list of what is retired and where the replacement lives. Treat retirement as a product launch, not an IT sweep.
The semantic layer is the investment
Most of the long-term value is in the semantic layer, not the dashboard rebuild. Once every metric has a canonical definition, owned, tested and versioned, three things happen: KPIs stop disagreeing, analysts work faster, and the estate does not re-bloat. Clients who have rebuilt without a semantic layer are back at 300 dashboards within two years.
Dashboards are the leaves. The metric layer is the trunk. If you only prune the leaves, the tree grows back the same shape.
What we have learned
- Start with a visible domain. Finance reporting, usually. A visible early win unlocks the rest.
- Retire in public. An intranet page listing retired dashboards and their replacements reduces "why can't I see X any more" tickets by roughly 80%.
- Do not merge Power BI, Tableau and Qlik into one platform in a single programme. Merge onto one platform over twelve to eighteen months, rationalisation first, migration second.
- Measure adoption after. The goal is more decisions, not fewer dashboards. If usage stays the same, the programme missed the point.