Discover, analyse and decompose your content estate — then track every file through migration and beyond
The Files report is your file-level view of everything Content Governance has discovered and touched — across Discovery, Migration, Offload and Restore — with full SharePoint context: site, library, folder path, sensitivity and retention labels, size, version count, owner, and any custom metadata column. It does double duty: it is both the analysis surface you plan from and the living record that tracks and documents every file through the whole project — from first discovery, through migration or offload, to post-project compliance lookup.
ℹ The Files report answers “what is actually in there?” — the Jobs report answers “is everything running?”
—-
In this section
- Visuals & using the Files report — the KPI strip, matrix, Decomposition Tree, Tree Map, donuts and slicers; filtering by any custom metadata column; drill-through to a single file; and why the report is built on a single page.
- File status & the run-history model — how each file is tracked as a single row under its latest status, what happens when a migrated file is re-discovered, and how the run-history list keeps the report clean and current.
- The Files report as project record, handover & compliance — how the report documents the whole lifecycle, hands work over from analysis to migration, and serves as per-file compliance evidence afterwards.
- Multi-Source Migration — cherry-pick files from any source via CSV export and migrate them, with their folder structure, to a single destination.
—-
The key capability — discovery-driven analysis
Most migration tools start moving data and hope for the best. Content Governance starts with discovery: a Discovery job scans your sources and builds a complete, file-level inventory in the BI database (PostgreSQL or SQL Server) — without moving or changing anything. The Files report then lets you decompose that inventory along any dimension you choose and see exactly where the weight sits.
This is the difference between a blind lift-and-shift and a data-driven migration:
- Where does the volume actually live? Drill from tenant → site → library → folder → file and watch the GB accumulate at every level. The handful of folders holding the bulk of your storage become obvious immediately.
- How much of it is version bloat? See total version count and version-history size alongside current-version size. Libraries with runaway versioning are often the single biggest — and cheapest — win.
- What is safe to leave, offload, or migrate? Slice by age, by sensitivity / retention label, by file type, by owner — and decide per segment instead of per tenant.
- What is the real scope? File counts and volume per library let you size the project — and the licence — honestly, up front.
★ This is the core value of SMART BI: you see and understand your estate first, then move only what makes sense. Discovery has no side-effects — nothing is migrated, nothing is changed — so you can scan, analyse, re-scan and refine the plan as often as you like before committing to anything.
The two visuals that make this fast are the Decomposition Tree (follow the volume down any path you choose, one split at a time) and the Tree Map (the whole hierarchy in a single glance — biggest rectangle = biggest target). Both are covered in detail in Visuals & using the Files report.
—-
More than analysis — your project record and handover
The same report that the analysts plan from becomes the documentation of what was actually done. As jobs run, each file’s status moves in place and the report tracks progress file-by-file; when the project closes, it remains as the as-built, per-file record for audit and compliance. Crucially, it is also the handover artifact between the analysis team and the migration team — one authoritative picture instead of emailed spreadsheets.
This is important enough to have its own chapter — see The Files report as project record, handover & compliance.
—-
Questions the Files report answers
Scope & planning
- How many files — and how many GB — are still pending migration in a given library, a site, or across the whole tenant?
- Which libraries or owners hold the largest share of the total volume?
- How big is the project really, per library, for sizing and licensing?
Volume & version analysis
- Where is storage concentrated — which folders, libraries, file types or owners dominate?
- How much of the volume is version history rather than current content, and exactly where?
- What is the size and age profile — how much is old, dormant content that should be offloaded rather than migrated?
Governance & compliance
- Which sensitivity labels are blocking migration, and how many files do they affect?
- Which retention labels are in play, and on how much content?
- Which
Department— or any custom column — carries the largestConfidentialfootprint?
Migration health
- Which files were re-discovered after migration because the source changed (your delta-migration candidates)?
- What is the total size of files already offloaded, and what remains?
—-
From analysis to action
Beyond analysis, the report is also the starting point for a targeted migration: filter down to exactly the files you want — by metadata, label, state, or anything else you can slice — export the list, and hand it to a job. See Multi-Source Migration.