A BI migration is the only time you will be allowed to delete reports

The inventory usually arrives as a spreadsheet, exported from the tool being retired. One row per report, columns for owner and last modified date, sorted by workspace. It is always longer than the sponsor expected. Somebody reads the row count out loud and the call goes quiet for a second, because everyone in it can feel the year of work sitting inside that number.

What happens next is nearly always the same. The plan becomes a rebuild. Phase one takes finance, phase two takes operations, phase three takes whatever is left, and the old tool is switched off when the new one reaches parity. Parity gets written into the acceptance criteria because it is the one criterion nobody in the room can argue against without sounding like they are planning to break something.

It is also the criterion that guarantees the expensive kind of failure. Not a project that collapses, which at least gets reviewed, but a project that succeeds at delivering the same mess in a newer interface, a year later, having paid for both tools the whole way through. The new platform inherits every duplicate, every abandoned request and every conflicting definition, and it inherits them with a fresh coat of legitimacy, because somebody signed off that they were faithfully reproduced.

The estate is a log of requests, not a design

Nobody sat down and designed that list. It accumulated. A report exists because it was needed before a board meeting three years ago, and the person who asked for it has since left. Another exists because someone needed the same view with one filter changed and copying was faster than asking. A third has not been opened in two years, but nobody dares remove it because the finance director's name is on the owner field and asking feels like picking a fight over nothing. Reports are cheap to create in an afternoon and expensive to retire, and that asymmetry runs in one direction for the entire life of the platform. The cost is not only clutter. Every duplicate is a place where a definition can quietly drift away from the one next to it.

A report is created in an afternoon and retired by a committee that never meets.

The pattern, stated plainly

Migration flips the burden of proof

In business as usual, deleting a report means proving that nobody needs it. That is an unfalsifiable negative, and any single objection wins, however vague. Someone says they think it gets used at quarter end, and the report survives another year on the strength of a maybe. A migration changes the shape of the question, because nothing is being deleted. It is being not rebuilt. The burden moves to the person who wants it: name the report, say who reads it, say what decision changes because of it. Most of the list has nobody willing to say that sentence out loud. That window is open from the day the migration is approved until the day the old tool goes dark, and it does not open again.

Open with usage data, not a build plan

Before anyone estimates anything, pull the logs. Power BI records activity events through the admin API and the tenant audit log, per user, per artefact, per action. Superset keeps its own metadata database with view records for dashboards and charts, plus a query log of what was actually run against the warehouse. Whichever tool you are leaving, the warehouse underneath it also has query history, and that is the more honest signal, because it shows which tables are genuinely being read and by whom rather than which tiles happened to render on someone's home page.

• Thirteen months, not thirty days A quarterly pack looks dead in a short window, and a year-end pack looks dead in fifty-one weeks out of fifty-two. The extra month past a year lets you see the same period twice.
• Distinct human readers, not view counts Subscriptions, scheduled refreshes and service accounts inflate the numbers badly. One person's emailed subscription is not an audience of two hundred, and a nightly refresh is not readership at all.
• Opens that were chosen A dashboard pinned as the default landing page collects opens from everybody who logged in to go somewhere else. Separate the deliberate visits from the incidental ones.
• Downstream dependency Find the reports whose main use is an export to a spreadsheet that then feeds something else. Those are not reports, they are data extracts wearing a chart, and they need a different answer in the new tool.
• Lineage in both directions Which warehouse tables feed the report, and which pipelines exist only to serve it. Retiring the report should retire the pipeline behind it, and that is where the running cost actually sits.

Four piles, decided once

Rebuild the survivors differently

The point of the cut is not that it saves build effort, though it does. The point is that a short list can be built the way the old estate never was. Metric definitions move into a modelled layer, in dbt or its equivalent, so that revenue means one thing and the report presents that meaning rather than recalculating it privately in a filter nobody will ever read. Tests sit on the model. Lineage becomes traceable, so when a number changes you can say which upstream change caused it instead of opening files until you find the culprit. Carry the whole estate across and you carry a dozen definitions of revenue with it, faithfully reproduced, which is an outcome no sponsor would approve if it were put to them in those words.

The same logic applies to access. In a large inherited estate, permissions end up expressed as which tiles a person can see, which is a presentation-layer answer to a data-layer question, and it breaks the moment anyone gets an export. Enforcing the rule on the query itself is the reasoning behind how we built Antvia, and it holds regardless of which tool you land on. A short, deliberate list is the only condition under which that discipline is affordable to apply.

Hold the argument once

This is a political exercise wearing an analytical costume, so treat the politics seriously. The sponsor has to be senior enough that the retire list does not get renegotiated per department. Keep the old tool read-only for a defined window instead of switching it off on go-live day, and log what people open during that window, because a log settles an argument that opinions cannot. Publish the route back: anything not rebuilt can be requested after go-live through the normal intake, with the same evidence anyone else has to bring. Most of those requests never arrive. The ones that do are usually worth building, and now they get built once, properly, instead of copied from a neighbouring file.

When lift and shift is the right call

There are cases where all of the above is the wrong advice. If a licence expires in six weeks, the cut analysis is a luxury you cannot afford, and the honest plan is to move as-is and run the exercise a quarter later using the new tool's own usage data, which you will have from day one this time. Regulated reporting is another exception, and a real one. A statutory return or a clinical audit report that nobody opens is still used, because being answerable for it is the use. Those belong in the keep pile whatever the view counts say. And if the organisation is halfway through a restructure, thirteen months of usage describes a company that no longer exists, so the cut will remove the wrong things with great confidence. Wait for the new shape, then run it. Whenever you do run it, keep the retire list afterwards. It is the most useful document the migration produces and the one nobody thinks to save.