Taming the Digital Landfill: How to Restructure Your SharePoint

A frustrated office worker searches through disorganized digital files on a computer screen.

Ask anyone in your business where the “real” version of a document lives and watch how long the answer takes. If it involves a pause, a guess, or the phrase “I think it’s in the old site”, you’re not looking at a technology problem so much as an architecture one, and it’s costing you more than most businesses realise.

The scale of the problem

Most SharePoint environments aren’t planned so much as accumulated. A site gets created for a project, a team spins up a library for a client, someone copies a folder structure from three years ago because it’s familiar, and within a couple of years the tenant is a patchwork of overlapping sites with no consistent logic behind any of them.

The cost isn’t abstract. One widely cited estimate puts the average knowledge worker’s time spent searching for and gathering information at close to an hour and a half a day, roughly nine hours a week, when documents and information are scattered across systems rather than organised around how people actually work. Separately, industry research on Microsoft 365 environments consistently finds that a fifth or more of stored content is what’s known in the trade as ROT: redundant, obsolete or trivial, data that serves no purpose but still has to be paid for, secured, and waded through every time someone runs a search.

Beyond the lost hours, disorganised SharePoint sites carry a quieter risk. When permissions are inherited by default and nobody has reviewed a site in two years, sensitive content can end up visible to far more people than intended, and when a compliance audit or a Copilot rollout meets a badly structured tenant, both tend to surface the same problem at once: nobody can say with confidence what’s stored where, or who can see it.

Why folders are the wrong starting point

The instinctive fix, more folders, better named, is almost always the wrong one. Deep folder hierarchies feel organised but scale badly: the same document often belongs in three different folders depending on who’s looking for it, so it either gets duplicated or someone loses simply because they guessed the wrong branch.

The better starting point is metadata: tagging documents with structured, consistent attributes (client, project, document type, status, department) so that the same file can be found and filtered from multiple angles without being physically duplicated or filed in only one place. Paired with a managed term set, a controlled vocabulary shared across the organisation, this also solves the problem of five departments each inventing their own name for the same category of document.

This doesn’t mean folders disappear entirely. It means folders stop being the primary way content is organised, and start being a secondary convenience within a structure that’s actually built around how people search, not how a filing cabinet used to work.

Building the architecture from scratch

  1. Audit before you design. Before deciding what the new structure should look like, understand what you’re actually working with: how many sites exist, how much content sits in each, what’s genuinely active versus dormant, and where permissions have drifted from what they should be. Skipping this step is the single most common reason restructuring projects stall, because the design ends up based on assumptions rather than the real state of the tenant.
  2. Design around the business, not the org chart. The best-performing SharePoint structures are organised around how work actually happens, by client, by project, by function, rather than mirroring a reporting hierarchy that may bear little resemblance to how documents get used day to day. If two departments effectively work the same content from different angles, your architecture should reflect that overlap rather than forcing two disconnected copies to exist.
  3. Use hub sites to connect, not nest. Rather than building deep chains of subsites (which inherit permissions and become hard to untangle later), modern SharePoint architecture favours hub sites: a central hub for a department or function, with related sites associated to it, each keeping its own permissions but sharing consistent navigation, branding and a scoped search experience. This scales far better than a nested hierarchy as the organisation grows.
  4. Choose a small, disciplined set of metadata fields. Somewhere between four and eight core fields, applied consistently, will do more for findability than an elaborate scheme nobody keeps up with. Common choices include client or project, document type, status, and owning department. Attach these to content types so that the right metadata and templates are applied automatically rather than left to individual judgement at the point of saving.
  5. Set governance before content moves, not after. Decide, in writing, who can create a new site, what naming conventions apply, how long inactive sites are kept before archiving, and who owns each site’s permissions on an ongoing basis. A structure without governance degrades back into sprawl within a year or two, no matter how well it was designed at launch.
  6. Migrate deliberately, not wholesale. A restructuring project is the natural point to leave ROT content behind rather than migrating it into the new environment “just in case”. Set clear criteria (last modified date, last accessed date, whether it has an active owner) and archive or delete what doesn’t meet them, rather than carrying every historical file into a system that’s supposed to be a fresh start.
  7. Review permissions as part of the redesign, not as an afterthought. This is the point where oversharing gets fixed. Reset default sharing settings on new sites to something more conservative than “everyone”, audit who currently has access to sensitive libraries, and build a routine (quarterly is common) for reviewing access rather than assuming it stays correct indefinitely.

What good looks like in practice

A well-structured tenant tends to share a few visible traits: a small number of purposeful hubs rather than dozens of overlapping sites, documents findable through search and filtered views rather than folder-diving, permissions that map cleanly to who should actually see what, and a named owner for every site who’s expected to keep it that way. None of this requires exotic tooling. It requires a deliberate design, applied consistently, and revisited on a schedule rather than left to erode.

The organisations that get the most value from this kind of restructuring treat it as infrastructure, not a one-off tidy-up. The businesses that skip the audit and governance steps tend to end up back where they started within eighteen months, just with a newer-looking mess.

Where Evolve Document Solutions fits in

Document sprawl rarely announces itself; it just quietly costs time, storage and risk until someone finally goes looking for a file that should have taken thirty seconds to find. We help businesses audit their existing document environment, design an architecture that actually reflects how the organisation works, and put the governance in place to keep it that way. If your SharePoint has grown faster than anyone’s ever had time to plan for, that’s exactly where we start.