Somewhere in your Microsoft 365 tenant, there is a site called Project Phoenix - Final v3. Its owner left in 2022. It has 47 members, 12,000 documents, three copies of the same PDF, and a permission chain nobody has audited since it was provisioned. Multiply that by a few thousand and you have what most enterprises quietly call their document architecture.

The reflex is to blame the platform. That is a mistake. Sprawl is not what SharePoint does to you. Sprawl is what happens when an organization provisions collaboration faster than it designs it, then hopes governance will retrofit itself. A recent case study from Archon Data Store described a tenant that had grown to more than 38,000 SharePoint sites, with 31% inactive, over 8,000 without owners, and storage costs climbing to $2.3M annually. That is not a technology failure. That is a target-state architecture that was never designed.

This article lays out a SharePoint information architecture reset: three deliberate moves — Consolidate, Classify, Retain — held together by an operating model that runs the environment instead of documenting it. It is written for CIOs, IT directors, and Microsoft 365 governance owners who need to reclaim their document architecture before Copilot exposes every shortcut in it.

TL;DR

SharePoint sprawl is an information architecture and operating-model failure, not a site-count problem. Reclaiming your document architecture requires a deliberate reset — consolidate what already exists, replace folder hierarchies with metadata, and design retention as an architectural decision — sustained by an automated governance operating model.

Key Takeaways

• Reframe the problem: Sprawl is the absence of a target-state architecture, not the presence of too many sites.
• Consolidate before you clean: Inventory, classify, and rationalize with a merge / archive / decommission decision tree, not a bulk delete.
• Metadata beats folders: Content types, managed metadata, and library views scale where folder hierarchies collapse.
• Retention is architecture: Design retention by content type using Microsoft Purview labels; do not delegate it to end users.
• Governance is a running system: Roles, cadences, and automation — not a policy PDF — keep sprawl from returning.

Sprawl is not a site-count problem. It is an architecture failure.

Every enterprise IT team we work with can produce a site count. Very few can produce a target-state architecture. That gap is the entire problem.

Modern SharePoint intentionally moved away from deep, nested site collections. Microsoft's own guidance is explicit: the modern IA is flat, connected by hubs, and organized around how people work rather than how the org chart looks. Most tenants ignored that guidance because Teams provisioning made a new site the path of least resistance. Every new channel, project, and cross-functional working group produced another site, another permission model, and another folder tree that only its creator understood.

The consequences compound quietly. Search quality degrades because the same document exists in seven places with seven titles. Storage costs inflate because nothing is ever archived. Audit exposure grows because ownership is unclear. And now Copilot arrives, and it does exactly what it was designed to do: it reads everything the user can access and answers with confidence. Microsoft's Copilot readiness guidance is blunt about the dependency: the quality and safety of AI answers is a direct function of the underlying information architecture and permissions hygiene.

The failure mode most organizations fall into is treating this as a cleanup project. Cleanups end. Architecture is a decision you keep making. Until leaders internalize that difference, every remediation is a rerun of the last one, three years apart.

Sprawl is not what SharePoint does to you. Sprawl is what happens when an organization provisions collaboration faster than it designs it, then hopes governance will retrofit itself.

Consolidate: rationalize what already exists

The first move is not deletion. It is inventory. You cannot rationalize what you have not classified, and bulk-deleting inactive sites is how you turn a governance problem into a legal one.

Start with the data Microsoft already gives you. The SharePoint site usage report and the site lifecycle capabilities in SharePoint Advanced Management expose activity, ownership, storage, and sharing posture at the tenant level. Combine that with a manual review of your top-storage and top-shared sites, and you will typically find that a small fraction of sites drive most of the risk and most of the value.

From there, every site should be routed through a four-way decision:

Site rationalization decision framework

Keep

• Criteria: Active in the last 90 days, has a named owner, maps to a current business function, unique content.
• Action: Enroll in the target-state IA — assign to a hub, apply the standard content types, confirm sensitivity labels.

Merge

• Criteria: Duplicates or overlaps another active site, same audience, same purpose, fragmented content.
• Action: Choose a surviving site, migrate content with metadata preserved, redirect links, retire the source.

Archive

• Criteria: Inactive 12+ months, still has legal, contractual, or historical value, no ongoing collaboration.
• Action: Apply an inactive site policy and a retention label; remove from navigation; preserve read-only access for records.

Decommission

• Criteria: Inactive 24+ months, no records obligation, no unique content, no owner responds to attestation.
• Action: Run the disposition workflow, notify stakeholders, delete per policy.

Two implementation notes matter more than the framework itself. First, use inactive site policies and owner attestation to shift the workload onto the people who actually know what a site is for. Central IT cannot classify 38,000 sites; the business can classify its own. Second, redesign hub topology at the same time. Consolidation without a hub structure just produces fewer messy sites. A well-designed hub — anchored to a business capability, not a department — is how you make search and Copilot navigation work after the reset.

Classify: metadata over folders

If consolidation is about the tenant, classification is about the library. And this is where most SharePoint environments quietly reinforce the exact behavior that produced sprawl in the first place: they organize documents by location instead of meaning.

Folders are a navigation habit inherited from file shares. They break at scale for a reason worth naming clearly. A folder path assumes that everyone who needs a document thinks about it the same way its creator did. In reality, finance looks for a contract by client, legal looks for it by counterparty, operations looks for it by project, and compliance looks for it by effective date. A single folder tree can serve exactly one of those views. Metadata serves all of them at once.

A practical metadata over folders in SharePoint approach rests on three building blocks Microsoft ships out of the box:

• Content types define what a document is — Contract, Policy, SOP, Meeting Note, Deliverable — and carry their own required columns, retention labels, and templates.
• Managed metadata supplies a controlled vocabulary (departments, business capabilities, clients, product lines) so classification is consistent across every site.
• Library views replace folder navigation with filtered, grouped, and pivoted views on top of the same underlying content.

The right target for most mid-market environments is not zero folders. It is a small, disciplined set of content types with five to seven required metadata fields, and library views tuned to the top three or four ways each audience actually looks for content. That is enough to make search reliable, enable automation triggers, and give Copilot the signals it needs to ground answers in the right document instead of an old duplicate.

Retain: design retention by content type, not by department

Retention is where governance quietly falls apart in most tenants. Policies get written, labels get published, and then nothing changes because the design was built around org charts instead of content.

Microsoft Purview gives you two instruments: retention policies apply broadly at a location level, and retention labels apply precisely at the item level. Labels support default application on document libraries, event-based retention, and disposition review — the controls a defensible schedule actually requires. The design mistake is trying to use them to classify every document your organization produces. That is how you get a 90-label file plan that no user can navigate and no admin can maintain.

A workable SharePoint retention design for Microsoft 365 starts from the content type, not the site. Contracts retain for a term tied to the contract lifecycle. Policies retain until superseded plus a defined period. Working files retain briefly and dispose. Financial records follow the fiscal schedule. Because those retention rules attach to content types, they travel with the document, apply automatically when a library uses that content type as its default, and stay consistent across every site in the tenant. You are not asking users to be records managers. You are asking them to identify what a document is once, at upload — and often the automation does even that.

Two more disciplines separate a paper policy from a defensible one. Configure disposition review with real reviewers who have business context, not a shared IT queue. And align retention labels with sensitivity labels so the same content type carries both its lifecycle and its protection posture. That combination is what stands up in an audit and what prevents Copilot from confidently summarizing a document that should have been disposed two years ago.

Sustain: the governance operating model

Every reset in the world will regress inside eighteen months if the tenant returns to running on documents instead of workflows. The difference between organizations that hold the line and organizations that redo this exercise every three years is not the framework. It is the operating model.

A workable SharePoint governance operating model for a mid-market IT team has four moving parts:

• Named roles. An IA owner accountable for the target-state architecture. Content type stewards accountable for a small portfolio of content types. Site owners with real names, not distribution lists. A records liaison from legal or compliance. None of these need to be full-time roles; they need to be assigned roles.
• Cadences that run. Quarterly access reviews on high-risk sites. Annual IA review tied to strategy planning. Monthly inactive-site attestations driven by SharePoint Advanced Management policies. Governance is a rhythm, not a document.
• Automation as the enforcer. Provisioning workflows that require an owner, a content type, and a sensitivity label before a site exists. Lifecycle policies that notify, escalate, and enforce without a human in the loop. Ownership-reassignment flows triggered by HR events. This is where a modest investment in Power Automate and agentic workflows pays back permanently.
• Metrics executives care about. Storage trajectory, orphaned site count, sites without owners, Copilot answer trust, audit-finding volume. If governance cannot produce a monthly one-pager the CIO understands, it will not survive the next budget cycle.

What "reclaimed" looks like

A reclaimed SharePoint environment does not look austere. It looks calm. Users find what they need in fewer clicks. New sites arrive with an owner, a purpose, and a lifecycle already attached. Storage costs bend down instead of up. Auditors get answers in hours instead of weeks. And when Copilot answers a question, it references the current version of the right document — because there is only one, and the tenant knows which one it is.

None of that requires a rip-and-replace. It requires a decision. Stop treating SharePoint as storage that occasionally needs cleanup, and start treating it as an information architecture that needs to be designed, run, and measured. The organizations that make that shift will spend the next three years using their document architecture. The ones that do not will spend the next three years cleaning it again.