There's a pattern I see again and again. An organisation moved to SharePoint five, six, seven years ago — often in a hurry, often by copying a file server across as-is. It worked. People got on with their jobs. And then, slowly, it stopped working.
Today the tenant holds tens of thousands of documents across dozens of sites. Someone in finance asks in Teams, “does anyone have the latest supplier contract template?” Three people reply with three different files. A new starter spends their first week re-creating a document that already exists, twice. Search returns 400 results and the one you want is on page three — if you have permission to see it at all.
If that's you, two things are true. First, it isn't anyone's fault — it's the predictable outcome of how most tenants were set up. Second, you don't need to migrate, start again, or buy another system. You need to fix the structure you already have. Here's what's actually going wrong, and how I approach putting it right.
Why it happens: six things that quietly break findability
1. Folders were the only structure. The file server moved over folder-for-folder, so the only way to describe a document is where it sits. Ten levels deep, paths get long enough to break sync and hit URL limits, and every team invents its own naming. SharePoint can describe a document by what it is — type, department, client, status — but that was never switched on.
2. Every Team became a site. When Microsoft Teams took off, every new Team silently created its own SharePoint site with its own document library. Five years on, that's hundreds of sites, many owned by people who have left. Search has to look through all of them, and staff have no idea which one is “the” place for anything.
3. Nothing ever retires. Projects that closed in 2021 sit next to live work with equal weight. Search can't tell the difference between the current policy and the six superseded drafts beside it, so it shows you all seven.
4. Search was never configured. Out of the box, SharePoint search indexes your content and stops there. Nobody added the company's acronyms, bookmarked the twenty documents everyone needs, or set up filters that make sense for your business. So search “works”, technically, and is useless in practice.
5. Permissions drifted. Years of “share with…” links, broken inheritance, and one-off exceptions mean two people searching for the same thing see different results. Some can't find documents they should see. Others can find documents they shouldn't — which becomes a real problem the day you switch on Copilot.
6. Versions live as separate files. Final_v3, Final_v3_updated, Copy of Final_v3. SharePoint keeps version history automatically, but if the habit is “save a new copy”, you end up with a dozen near-identical documents competing in search.
What doesn't fix it
- —Migrating to a fresh tenant or new intranet. You'll spend months moving the same mess into a new box. Without changing the structure, you get the same result with a new URL.
- —Buying a third-party document management system. The problem isn't the tool; it's the absence of structure and ownership. Both of those move with you.
- —A one-off “clean-up day”. Useful for morale, forgotten in a quarter. Sprawl is a process problem and needs a process answer.
- —Switching on Copilot and hoping. Copilot is only as good as the content and permissions underneath it. On an unstructured, over-shared tenant it confidently surfaces the wrong document — or one someone shouldn't see.
How to fix it: a staged plan that doesn't disrupt work
The mistake most organisations make is trying to fix everything at once. The tenant is big; the team's time is small. The approach that actually works is to diagnose properly, take the quick wins, and then restructure only the libraries that matter — in that order.
Stage 1 — Diagnose (about a week)
Before touching anything, find out what's really there and what people actually need. This is the part most teams skip, and it's where the whole plan comes from.
- —Site inventory. Pull the full list of sites from the SharePoint admin centre with storage, last activity and owner. In a typical five-year tenant, a large share have had no activity in over a year.
- —The “top twenty”. Ask each department for the twenty documents they reach for most. This list drives everything that follows — you optimise for these first.
- —Search analytics. Microsoft 365 records what people search for and which queries return nothing or get abandoned. That tells you exactly where search is failing.
- —Permissions review. Where has inheritance been broken? What's shared with “anyone with the link”? Which sites have no owner at all?
Stage 2 — Quick wins (weeks 2–4)
These change how the tenant feels within days, and they cost almost nothing.
- —Bookmarks and acronyms in Microsoft Search. Pin the top-twenty documents so a search for “expense form” or “onboarding checklist” returns the right file at the top, every time. Add your internal acronyms so search understands your language.
- —Archive inactive sites. Sites with no activity in 12+ months get archived (still recoverable, no longer cluttering search) or, where appropriate, deleted after owner sign-off.
- —Assign owners. Every remaining site gets a named owner. No owner, no site.
- —Tidy the front door. A simple hub page that links to the handful of libraries people genuinely use, so nobody has to remember URLs.
Stage 3 — Restructure the libraries that matter (weeks 4–8)
Now fix the structure — but only for the five to ten libraries that carry most of the daily work. This is where SharePoint's real strengths come in.
- —Metadata instead of folder depth. Replace the deep folder tree with a flat library and a few well-chosen columns: Document Type, Department, Client or Project, Status. One document, many ways to find it.
- —Content types and managed metadata. Define “Contract”, “Policy”, “Report” once, with the columns each needs, and reuse them across sites. Use the term store so “HR” and “Human Resources” are the same thing everywhere.
- —Views instead of folders. “Current policies”, “Contracts expiring this quarter”, “My department” — saved views give people the folder-like experience they're used to, without the sprawl.
- —Document sets for project packs. Where a project genuinely needs a bundle of related files, document sets keep them together with shared metadata.
- —Versioning, properly. Turn on major/minor versions, train the “edit in place” habit, and retire the Final_v3 culture.
Stage 4 — Make search work for your business
With metadata in place, search can finally be configured to match how your organisation thinks.
- —Refiners. Filter results by document type, department or status — the columns you just added.
- —Search verticals. A “Policies” tab, a “Contracts” tab, a “Templates” tab, each scoped to the right content.
- —A proper search page. For larger tenants, a custom search experience (for example using the open-source PnP Modern Search web parts) gives staff a single, tailored place to look.
- —Promoted results. Make sure the authoritative version always wins over its superseded cousins.
Stage 5 — Stop it happening again
Findability decays without governance. The final stage is lightweight but essential.
- —A site-provisioning process. New sites are requested, given an owner and a purpose, and created from a template with the right columns already in place.
- —Retention and lifecycle. Retention labels (via Microsoft Purview) that auto-apply based on content type, and site lifecycle policies that flag inactive sites automatically.
- —A quarterly review. Thirty minutes to check inactive sites, orphaned owners and no-result searches. Small, regular, boring — and it works.
- —Training that fits. Short, role-specific sessions: how to file, how to find, how to share safely.
A note on Copilot
Many organisations arrive at this problem because they're planning to roll out Microsoft 365 Copilot and have realised, correctly, that it will surface whatever it can find. Everything above is also the honest checklist for Copilot readiness: clean structure, meaningful metadata, sensible permissions, and retired content actually retired. Do the groundwork and Copilot becomes genuinely useful; skip it and Copilot becomes a very fast way to find the wrong document.
How long does this take?
The diagnostic stage is typically one to two weeks. Quick wins land in the following fortnight and are usually the moment staff notice the difference. Restructuring is staged library by library so nobody's work is interrupted, and governance is set up alongside. The exact timeline depends on the size of the tenant and how many libraries genuinely matter — which is exactly what the diagnostic tells you.
The important point is that none of it requires a migration, a new platform, or a big-bang cut-over. Your SharePoint isn't broken. It's just been running for five years without the structure it was designed to have — and that's fixable.
