The Files report as project record

The Files report is the project’s record — a portable Power BI file you copy, share and keep

The Content Governance Power BI report — the shipped SMARTBI_File.pbit template, and the working .pbix you run it as — is both an analysis surface and the record of the whole migration project. It captures the estate as discovered, tracks what happens to every file as jobs run, and remains afterwards as the documentation of what was actually done.

*Because of how Power BI stores its data, that record is a single, self-contained file you can copy and hand to anyone.

—-

Power BI Desktop is free — and we install it for you

The application that opens and runs the report, Power BI Desktop, is a free Microsoft product. There is no licence fee to view, refresh, customise or share the .pbix. Content Governance installs Power BI Desktop automatically as part of setup, unless you opt out.

ℹ Power BI Desktop (free) is all you need for everything described on this page. The Power BI service / portal — used for browser-based sharing, covered further down — is a separate Microsoft offering with its own licensing, and nothing in this report requires it.

—-

The data is stored inside the .pbix

The report uses Power BI import mode: when the dataset is loaded (or refreshed), Power BI keeps a compressed copy of the data inside the .pbix file. The file is self-contained.

This means you can copy the .pbix and open it on any machine running Power BI Desktop — with no database, no server and no credentials — and see every file, every status, every label and the full per-file detail exactly as it was at the last refresh.

ℹ The .pbit is the empty template (structure only, no data). The .pbix is what you get once data has been loaded into it — structure plus an embedded snapshot of the data.

—-

Decoupled from the database — and how to refresh

Once the data is loaded, the .pbix is decoupled from the BI database. The embedded snapshot is frozen as of the last refresh; opening or copying the file does not need the database to be reachable.

The report’s data model connects to the BI database (PostgreSQL or SQL Server) through an ODBC data source. Anyone who has that ODBC data source configured — i.e. network access and credentials to the database — can press Refresh in Power BI Desktop to reload the dataset with current data. Anyone who does not simply keeps the embedded snapshot, which is exactly what you want for handover and audit copies.

*To produce a dated milestone snapshot — end of discovery, end of migration — refresh the report, then Save a copy of the .pbix. That copy carries a fixed picture of the estate at that moment, independent of any later changes in the database.

—-

The file is not tied to the migration server

The .pbix does not have to live on the migration server. Copy it to an analyst’s laptop, a shared drive, a Teams or SharePoint site, or send it to the migration team or an auditor. Each copy is independent and carries its own embedded data, so the report travels with the project rather than being locked to the machine that produced it.

—-

It is a standard Power BI report — publish it if you have the portal

There is nothing proprietary about the file: it is an ordinary Power BI report. If the client uses the Power BI service (the Power BI portal), the report can be published there and shared in the browser — with workspace-based access control and, where the database is reachable from the service, scheduled refresh. Everything you would normally do with a Power BI report applies.

—-

Completely open — adjust it however you like

The .pbix is fully editable in Power BI Desktop. Nothing is locked. You can:

• rebrand it — add your own logo, colours, theme, titles and headings;
• remove visuals you don’t use, and add new ones;
• add or change measures, pages and slicers;
• reshape or extend the data model.

The shipped report is a starting point; adjust it to suit your project and your house style.

*If you customise the report, keep the single-page layout described in Visuals & using the Files report — it is more reliable than Power BI’s multi-page slicer sync.

—-

One report, three phases

1. Discovery / analysis. The initial team scans the sources and the report captures the baseline: every file, where it lives, how big it is, how many versions it has, which labels it carries — the estate exactly as found.
2. Migration / offload. As jobs run, each file’s status moves in place (Discovery → Migration / Offload) and the report tracks progress file-by-file. At any moment it shows what is done, what is still pending, and what changed at source after migration.
3. Post-project. When the move is finished, the report remains as the as-built record — a per-file lookup and compliance document showing what happened to every file, with its labels, destination and full action history.

—-

Handover from analysis to migration

★ The report doubles as the handover artifact. The team that runs the initial analysis hands it to the migration team as the single, authoritative picture — what was found, what was planned, and (as work proceeds) what has been done. There are no spreadsheets to email around and no “which version is current?” — the report is the shared source of truth across the project.

When both teams refresh against the same BI database they see the same numbers: the analysts’ decomposition of volume, versions and labels is exactly what the migration team executes against, and the migration team’s progress is visible back to the analysts.

*Each file record also links to its Run History item in Microsoft Teams. Anyone holding the report who also has access to the team can click straight through to the Run History item — and on to the job behind it — to review, modify or re-run it. The report becomes not just a picture of the project but a way into the jobs that drive it.

—-

Per-file compliance evidence

Every file is tracked as a single row under its latest status, and its complete Action history is preserved on the drill-through Single File page. Long after the project closes, the report answers — for any individual file:

• Where did it come from (site / library / folder) and where did it go (Nextcloud / SharePoint etc.)?
• What sensitivity and retention labels did it carry?
• When was it discovered, migrated or offloaded — and was it changed at source afterwards?
• Which job run touched it — with a link straight to that Run History item in Microsoft Teams?

ℹ This is the difference between “we migrated everything” and being able to show, per file, exactly what happened and when — which is what auditors, data-protection officers and the receiving business ask for.

—-

Keeping the record honest

The run-history rules that keep the live report clean also keep the record trustworthy over time: each file is referenced once, by its latest action, and run-history items with no remaining files drop out automatically. See File status & the run-history model for the mechanics.