Your Power BI migration is finished. Are people actually using the new reports?
You have moved reports to Power BI from a legacy platform, or from one Power BI tenant to another. The cutover is done, the acceptance tests passed, and the project is technically complete.
Then the questions start. Did people actually switch? Which of the migrated reports are being used, and which ones did everyone quietly abandon? Your sponsor wants evidence that the investment paid off, and the next migration wave is waiting on your answer.
Why this is hard today
A successful migration is usually measured by whether reports were delivered, not by whether anyone uses them. Delivery is easy to count. Adoption is not.
Native usage metrics tell you a report was opened, and they keep a limited window of history. That is enough to see a page view, but not enough to tell a real switch from a single curious click, or to show that people open the new report and then go back to the spreadsheet they trust.
What BI Pixie shows you
BI Pixie adds invisible tracking elements, called Pixies, to your migrated reports, so you can measure the switch rather than assume it.
- Adoption and attrition per report
- Monthly active users and how that population grows or shrinks after go-live, so you can see a report that launched well and then lost its audience.
- Depth, not just opens
- Session duration and interactions per session separate people who genuinely work in a report from those who open it and leave.
- Which pages and visuals are still used after the migration
- Page and visual level engagement shows which parts of a migrated report people still open, and which were rebuilt for nobody.
- Satisfaction from the people using it
- Feedback controls and embedded surveys collect scores from inside the report, so post-migration sentiment comes from users rather than from the loudest stakeholder.
- Report speed before and after the cutover
- Load and render times per report and per visual. "It has been slower since the migration" is the hardest complaint to answer, because by the time it is raised the old platform is gone and nobody measured it. A baseline captured before the cutover turns that into a specific report, page, or visual you can point at. This one needs your Power BI workspaces integrated with Azure Log Analytics, and it only works if you set it up before you migrate.
Migrating the data platform underneath the reports
The harder version of this problem starts before anything is rebuilt. You are moving the data estate itself to Microsoft Fabric, Databricks, or Snowflake, and hundreds of existing Power BI reports point at the platform you are retiring. Every one of them needs a decision, and the decision is not technical.
Effort is the easy half to estimate. Any competent team can look at a report and say whether it needs a new connection string or a rebuild. The half nobody can answer from the report itself is whether it is worth the work. So teams migrate everything, which is the most expensive option available, or they cut by guesswork and find out which reports mattered when someone escalates.
- Repoint it and leave it alone
- A report with steady monthly users and real interaction depth is working. Change the connection, change nothing else, and protect it through the cutover.
- Refactor it
- Heavy use concentrated in two pages out of eleven tells you what to keep and what to drop. Page and visual level engagement turns a rewrite into a scope decision instead of a rebuild of everything that was there before.
- Rebuild it
- High opens with almost no interaction, or a report people open and leave within seconds, usually means the report is being tolerated rather than used. That is a candidate to redesign on the new platform, not to carry across as-is.
- Retire it
- Reports opened by a handful of people a few times a quarter are the cheapest win in any migration. Retiring them removes migration effort, support load, and a data source dependency in one decision.
BI Pixie does not estimate migration effort and does not read your data platform. It answers the other half: which reports anyone would miss. You bring the list of reports that depend on the platform you are retiring; the engagement data tells you which of them justify the work.
What it takes to set up
- 1 Connect your Power BI workspace and select the migrated reports.
- 2 Add Pixies. The reports keep working exactly as before and the tracking is invisible to your users.
- 3 Let a normal reporting cycle run so you have a baseline to compare against.
- 4 Review adoption and engagement per report in the BI Pixie Dashboard.
Worth knowing: Baselines start when you add Pixies, so add them to the migrated reports as early as you can. If you can add them before go-live, you get a genuine before-and-after rather than an after-only picture. Adoption is measured from engagement counts, not from personal data: no personally identifiable information is collected unless you enable user identity capture in tracking setup, and that setting is off by default.