SharePoint folder restructuring

Break a mega-site into properly scoped site collections. The Restructuring Wizard analyses the current site, proposes a split-plan, auto-provisions the destination sites, queues library-level migration jobs, and re-applies permissions at the site-collection level so inheritance stays clean.

app.migrationfox.com/governance/restructuring/plan

Proposed restructuring plan

companyhub → 8 new site collections

source: companyhub.sharepoint.com · 240,188 files · 1.8 TB · health score 3/10

/Shared Documents/Finance→finance.sharepoint.com41,082 files

/Shared Documents/HR→hr.sharepoint.com12,440 files

/Shared Documents/Legal→legal.sharepoint.com8,921 files

/Shared Documents/Engineering→engineering.sharepoint.com84,207 files

/Shared Documents/Marketing→marketing.sharepoint.com19,844 files

/Shared Documents/Operations→ops.sharepoint.com32,110 files

When to restructure

The most common pattern: a single SharePoint site collection (often named something like /sites/companyhub or /sites/documents) has grown to host every department’s content. Permissions are set at the folder or file level. Inheritance is broken in thousands of places. Every Copilot search returns documents from three other departments. The fix is information architecture — one site collection per business unit, with permissions inherited cleanly from the site-collection root.

Restructuring is the right intervention when:

A SharePoint & OneDrive Oversharing assessment flags the site as red.
Permission grants are set at the file or folder level for departments whose boundary is not reflected in the site structure.
Content owners complain that “I see documents from other teams when I open the site”.
Copilot responses reference documents from outside the user’s department.
The site exceeds 300 GB and feels slow.

How the wizard works

Step 1 · Health scan

The Restructuring Wizard first runs a site-health scan. Each library gets a score from 1 to 10 based on:

Number of broken permission-inheritance points
Ratio of file-level ACLs to library-level ACLs
Breadth of unique principals (a library with 400 unique principals suggests cross-department sharing)
Storage and file count
Number of Anyone-link grants

Libraries scoring below 5 are flagged for restructuring.

Step 2 · Proposed plan

For each flagged library, the wizard proposes a new site collection. The proposal clusters libraries by shared principals — libraries that the same set of users access together stay together. Libraries that principals access in isolation become their own site collection. The boundaries usually (but not always) match department boundaries; review the proposal carefully.

Step 3 · Approve and customise

You review the proposed site map. Drag and drop libraries between proposed site collections if the department boundary is wrong. Rename proposed sites. Mark libraries as “do not migrate” if they are scheduled for decommission.

Step 4 · Auto-provision

When you click Approve, the wizard auto-provisions every new site collection. Each site is created with:

The site template you chose (team site by default, communication site optional).
Placeholder document libraries matching the source library names.
Site-collection-level permissions (Members, Owners, Visitors groups).
A site-collection admin (you, by default).

Step 5 · Queue migration jobs

The wizard queues one MigrationFox migration job per library → new-site mapping. Jobs run in parallel, with the auto-split engine kicking in for large libraries. You can watch the whole cohort of jobs run from the wizard’s job panel.

Step 6 · Re-apply permissions

After the copy completes, the wizard re-applies permissions at the site-collection level instead of the file or folder level. Every ACL set at the source’s file or folder level becomes a group membership at the destination site-collection level, so inheritance is uniform.

Step 7 · Decommission the source

The seven-day rollback window is open for every job in the cohort. Once you and stakeholders confirm the new sites look correct, decommission the mega-site by setting it to read-only (then deleting after your retention policy allows).

BEFORE / AFTER

Run the SharePoint & OneDrive Oversharing assessment before the restructuring (as the baseline) and after (as confirmation). The composite score almost always improves by 1–2 points on the 1.0–4.0 scale.

Permissions handling

The wizard uses three strategies depending on what it finds at the source:

Source pattern	Destination strategy
File-level ACL granting a single user	Promote to site-level Members membership for that user
Folder-level ACL granting a group	Site-level Members group for the target site collection
Anyone link at folder level	Flagged, not migrated. You decide per link whether to replace with specific grants.
Broken inheritance with no unique grants	Restore to inherit from the new site-collection root
External user grant	Flagged, not migrated by default. Toggle to preserve if you want it.

What does not move

Non-library content — site pages, lists, and web parts are copied as-is into each target site but you choose which target. The wizard does not automatically split them.
Custom site definitions — classic-era custom site templates will not be re-provisioned on modern sites. Use the Modernization scan to find them.
Subsites — subsites under the source must be flattened or explicitly mapped into a target site collection. The wizard prompts before running.

Migration Rehearsal dry-run — run before the cohort kicks off
Rollback preview — seven-day reversible window per job in the cohort
SharePoint Modernization scan — inventory classic workloads before you restructure
SPMT True History Mode — preserve Created / Modified metadata during restructuring