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.

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 · Edit the plan (it is a real planner, not a read-only report)

The Proposed Site Collections panel is fully editable until you click Execute. You can:

• Rename any proposed site inline — the site name appears in an editable text field. Rename “HR Benefits” to “MX HR Benefits” or whatever your naming convention dictates.
• Rename target libraries — each library shows its source name and a target-name input. The target starts identical to the source; edit it to rename on the way into the new site.
• Move items between sites — every library has a “Move to” dropdown. Reassign freely. Moving back to Primary means the library stays in the source site.
• Remove a proposed site — click Remove site on any non-primary group. Its libraries return to Primary automatically (nothing is silently dropped).
• Add an empty site — the + Add empty site button at the bottom creates a fresh target group. Move libraries into it from other groups.
• Pick the target site type per group — Microsoft 365 Group (Teams) by default. Communication Site and Classic Team Site appear in the picker for planning; only the Teams-backed path is executable today.

Step 4 · Promote directly from the source tree

The Source Tree section above the plan shows the site’s libraries and folders as an expandable hierarchy (up to four levels deep). Every library and every folder has a Promote → action that spins it off as its own target site in the plan below:

• Promote a library — the library moves out of its currently-assigned group into a brand-new target site named after the library. Used when the auto-grouping bundled something together that the architect wants separated.
• Promote a folder — the folder becomes the source content for a new target site. The executor copies only that sub-tree (not the whole library) into the new library. Common case: Documents/HR/Benefits becomes its own HR Benefits site without touching the rest of Documents.

Libraries and folders that are already promoted show a Promoted badge in the tree so you can see your plan state while browsing.

Step 5 · Pick the provisioning mode

A global toggle at the top of the plan controls default behaviour; each site can override it:

• Structure + content (default) — provision the site, create the libraries, and enqueue a content migration job per library. Each new site becomes a full copy of its source content at the new location.
• Structure only — provision the site and create empty libraries. No content migration jobs are queued. Useful when the architect wants to set up the shell in advance of a content-move change window, or when content will be re-created cleanly by a different process.

The per-site picker overrides the global default when a single group needs different treatment. The confirmation dialog before Execute shows the effective mode per site so there are no surprises.

Step 6 · Auto-provision

When you click Execute Restructuring, the wizard walks each proposed group and:

• Creates an M365 Group (which auto-provisions a SharePoint team site).
• Creates each target library at the new site using the name you chose.
• If mode is structure + content, creates a MigrationJob row and enqueues the content copy. For folder-promoted items, the migration is pointed at the specific folder sub-tree, not the whole library.
• Records a redirect-mapping entry (old URL → new URL) for every library, including structure-only ones, so you can publish the redirect list to users even if content moves later.

Step 7 · Queue migration jobs (if you picked structure + content)

Migration jobs run in parallel on the worker, with the auto-split engine kicking in for large libraries. You can watch the cohort run from the wizard’s execution panel or from the Jobs list.

Step 8 · 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 9 · 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).

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.

Related

• 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