All insights

How should a small business structure SharePoint?

6 min readBy Brendon Whiting, Founder · 19 December 2025

Create a site per meaningful area of work, each with named owners and its own access list, and keep folders shallow inside them. Do not build one large site with a folder for every department, however much that resembles the file server you are leaving. Permissions in SharePoint are designed to live at the site level, and structure that ignores this becomes unmanageable within a year.

The instinct to recreate the old shared drive is strong and entirely understandable. Everyone knows where things are, nothing has to be re-explained, and the migration looks like a copy rather than a project. It is also the single most reliable way to end up disliking SharePoint, because the shape of a file server and the shape of SharePoint are different in one specific way that only becomes apparent when you try to control access.

Here is the mechanism, because it is worth understanding rather than taking on trust. On a file server, permissions were set folder by folder and that was normal. In SharePoint, permissions are designed to be inherited from the site down. You can break inheritance on an individual folder, and SharePoint will let you, but every time you do you create an exception that nobody can see from the outside. Do it thirty times across a large site and no one in the business can answer who can see the payroll folder, which is a question you will eventually be asked, quite possibly by an assessor.

So the working rule is that anything needing its own access list should be its own site. Finance is a site, not a folder. HR is a site. Each significant client or project is a site if its access differs. Company-wide material that everyone reads is a site. Inside each, folders organise content for humans rather than for permissions, and they stay shallow, around three levels, because past that people stop navigating and start searching.

For a ten to fifty person business the resulting shape is modest: an intranet or company site for policies and shared reference material, a site per department, one or more for client or project work depending on how you operate, and that is often the lot. A handful of sites, each with a clear purpose and two named owners. If your plan runs past fifteen sites for a small business it is probably too granular, and every extra site is another thing whose permissions someone must maintain.

Naming deserves five minutes of thought that it almost never receives. Agree a convention before creating anything, because renaming later is awkward and leaves URLs behind. Client sites might be Client - Name, projects Project - Name, departments simply Finance or Operations. The test is whether someone joining in two years would guess correctly where something lives. Consistency matters more than cleverness here.

Then decide three governance questions up front, because they are the ones that get settled by default otherwise. Who can create new sites and Teams, since leaving this open to everyone produces sprawl within months and closing it entirely produces shadow workarounds; a request process with a fast answer is the middle path. What the external sharing default is, meaning whether staff can share with anyone by link, which deserves a deliberate decision. And who reviews sites for relevance, so that finished projects get archived rather than accumulating quietly with their guests still attached.

There is a newer reason to take structure seriously, which is that Copilot makes over-sharing instantly visible. It answers from whatever a person can already open, so a business with tangled permissions discovers the tangle the week Copilot arrives, in the form of someone surfacing a document they should never have found. Getting the structure right is now a prerequisite for AI adoption rather than a tidiness preference.

The honest caveat is that migration is the moment to do this and it costs more than copying. Tipping an old shared drive into SharePoint takes an afternoon and produces years of complaints; designing the destination, agreeing owners, and moving content into the intended shape takes days and produces something that still works in three years. If you want it planned before anything moves, call 1800 456 567.

Design it once, properly

We plan the sites, owners, permissions and naming before anything moves, so the structure still makes sense in three years.

Frequently asked questions

Usually a handful rather than dozens: one per department or major function, one or two for client or project work, and an intranet site for company-wide material. If you are heading past fifteen for a small business, the shape is probably too granular, and if you have one, it is certainly too coarse.

Shallow. Three levels inside a library is plenty for most businesses, and past that people stop navigating and start searching, which only works if names are meaningful. Deep folder trees are usually a symptom of too few sites, since the hierarchy is doing work that separate sites with their own permissions should be doing.

In theory it is more powerful; in practice most small businesses should not start there. Metadata only works if people apply it consistently, and consistency requires a discipline that does not appear on its own. Start with a sound site structure and shallow folders, and add metadata later for a specific library where it earns its keep.

Questions? Let's talk.

Call 1800 456 567 or fill out the form.

  • 30-minute discovery — no jargon, no pressure
  • Plain-English Essential Eight Cyber Security Scorecard
  • A clear plan tailored to your business

Prefer to talk?

Call 1800 456 567

Powered by Calendly — your data is handled securely.

Our office · Level 2, 25 Grenfell Street, Adelaide

By submitting, you agree to our terms and privacy policy. No spam — ever.