Migration projects rarely fail because a tool cannot move a file. They fail because nobody scoped the job accurately before it started. A site nobody remembered existed turns up in week three. A "small" site collection turns out to have four thousand unique permission grants. A stakeholder who should have been consulted about a destination structure only hears about the project after it is already underway. Every one of these is a scoping failure, and every one of them is preventable with a single document: a complete site inventory, built before the migration timeline is set, not during it.
What Is a Pre-Migration Site Inventory?
A pre-migration site inventory is a single, complete list of every SharePoint site in a tenant, along with its owner, storage used, last activity date, and permission complexity. It replaces guesswork with a document that scopes exactly what needs to move, in what order, and at what risk, so the migration plan is built on facts rather than on whatever the last reorganisation happened to leave behind in institutional memory.
Why Skipping This Step Costs You Later
Most migration overruns trace back to information that existed somewhere in the tenant but was never surfaced before the project started. A site with ninety gigabytes of version history nobody trimmed. A department that quietly stood up three unofficial team sites outside the sanctioned naming convention. An external contractor with edit rights across a dozen libraries who nobody remembers granting access to. None of these are unusual. All of them are expensive to discover mid-migration, when a schedule is already committed and a client or executive sponsor is already expecting a delivery date.
Building the inventory first turns these surprises into line items on a plan instead of fires during execution. It also gives you a defensible answer when someone asks how long the project will take, because the estimate is grounded in an actual count of sites, storage, and complexity rather than an educated guess.
Step 1: Export Every Site With Report Master
Open ShareMaster and connect with an account holding SharePoint admin permissions, then run a full tenant site inventory export in Report Master. The resulting Excel workbook lists every site collection in the tenant on one sheet, with owner, storage used, and last activity date attached to each row.
What the export includes
At minimum you want site URL, display name, owner or site collection administrator, storage used, and last modified date. If your tenant has hub sites or a large number of Teams-connected sites, note which sites are hub-associated, since those relationships often dictate migration order regardless of size.
Step 2: Flag Sites by Size, Activity, and Owner
With the export open, sort by storage to identify which sites will dominate the migration timeline purely on data volume. Sort separately by last activity to separate genuinely active sites from dormant ones. A dormant site with no recent edits is sometimes a candidate for archiving instead of migrating, which can shrink the total scope of the project meaningfully once a stakeholder confirms it is safe to leave behind.
| Sort pass | What it surfaces | What you do with it |
|---|---|---|
| By storage, descending | Sites that will take the longest to transfer | Schedule these with the most buffer time and test transfer speed early |
| By last activity | Dormant sites that may not need migrating at all | Confirm with the business owner whether to archive instead |
| By owner, blank filter | Sites with no confirmed owner | Escalate before scoping, not during execution |
Step 3: Identify Sites With Missing or Ghost Ownership
Filter the Owner column for blank cells, then cross-check the remaining names against your active directory or HR system to catch sites whose listed owner has left the organisation. An ownerless site is a scoping risk in a migration specifically because nobody can confirm what data still matters, who the destination stakeholders should be, or whether migrating the site is even worthwhile compared with archiving it.
Resolve these before the migration plan is finalised. Discovering a missing owner mid-project usually means pausing that site's migration while someone tracks down an answer, which is exactly the kind of delay a pre-migration inventory exists to prevent.
Step 4: Cross-Check Permission Complexity Before You Scope the Move
Storage and activity tell you how much data is moving. They do not tell you how hard a site will be to migrate. That answer comes from permission complexity: how many items have broken inheritance, how many unique role assignments exist across libraries and lists, and how many external or guest accounts hold access.
Why permission-heavy sites take longer
A site with clean, inherited permissions migrates close to the speed of its raw data volume. A site with hundreds of item-level unique permission grants requires those grants to be mapped, recreated, or deliberately flattened at the destination, and that mapping work does not scale linearly with file count. Two sites with identical storage can differ by a full day of migration effort purely based on permission structure.
- Run a permissions export alongside the site inventory, scoped to the same sites.
- Flag any site with unique permissions on more than a handful of items as high complexity.
- Note external or guest accounts separately, since these often need a specific decision about whether access carries over to the destination tenant.
Step 5: Turn the Inventory Into a Migration Sequencing Plan
With storage, activity, ownership, and permission complexity all captured against every site, group them into migration batches. A common approach is to move a handful of small, low-complexity sites first as a proof of process, then schedule the largest or most permission-heavy sites once the team has confidence in the transfer speed and error rate observed during the first batch.
For the mechanics of moving a site or document library once it is scoped, the guide to migrating a SharePoint site to another tenant and the cross-tenant document library migration guide cover the transfer itself in detail. For a side-by-side look at inventory tooling, see the site inventory report options comparison.
Frequently Asked Questions
What is a pre-migration site inventory?
A pre-migration site inventory is a single, complete list of every SharePoint site in a tenant, along with its owner, storage used, last activity date, and permission complexity. It replaces guesswork with a document that scopes exactly what needs to move, in what order, and at what risk.
How long does a site inventory take to build for a large tenant?
The export itself typically completes in minutes to a couple of hours depending on tenant size. The slower part is the analysis: filtering for owner gaps, sorting by storage and activity, and flagging permission-heavy sites usually takes an afternoon for a few hundred sites.
Do I need a site inventory if I am only migrating a handful of sites?
It is less critical for two or three known sites, but still worthwhile, since a quick export often surfaces a forgotten subsite or permission structure nobody remembered existed. For any migration touching more than a handful of sites, skipping this step is the most common reason a project runs over its original estimate.
What should I do with sites that have no active owner?
Escalate them before you scope the migration rather than during it. An ownerless site cannot confirm what data is still needed or whether it should be migrated at all rather than archived.