SharePoint as systems, not folders

An organisation buys Microsoft 365 and lifts its folder tree into SharePoint unchanged. The result is folders on the internet: the same old problem with extra latency on top.

Where the difference is

A folder tells you where a file lives. Metadata tells you what it is.

Take contracts. With folders you get a path like Contracts / 2026 / Suppliers / Hotels. Now try to find which contract expires this month. Your only option is to open every file.

With metadata, each contract becomes a row with fields for type, counterparty, start and end dates, and status. The same question turns into a filter, and the answer comes back immediately.

What I built on that principle

A contracts hub with a status model that separates active from expired, so retrieving any contract takes under half a minute.

A finance system for expenses and subscriptions. It answers three questions: what are we spending on, what renews this month, and is it worth it.

A request system whose approvals run inside Teams.

A PMO system that tracks projects and their stages.

And a single source for company data. The other systems read from it, so none of them keeps a private copy anymore.

Mistakes I have seen repeatedly

Moving folders as they are. You are moving the mess, not solving it.

Too many columns. Every field should answer a question people actually ask. A field nobody filters or searches on is data entry cost with no return.

Breaking permissions across thousands of items. It starts as a solution and ends as an administrative problem.

Forgetting reporting. Structured data feeds executive dashboards, and the real value shows up when a manager sees the whole picture without asking anyone for a report.

What I take from this

Before creating a list, write down the questions it will answer. If you cannot come up with three real questions, you are building a folder the complicated way.

Related reading

• Turning a vague client request into an executable scope