Leader Guide: Using SharePoint as a Document Management System

If you already run Microsoft 365, at some point you will realize that building a document management system (DMS) on SharePoint is a necessary move, and usually the right one.

The leaders I talk to across the Nordics and the UK rarely ask whether SharePoint can be their DMS. It can, and thousands of organisations run on it. They ask why it starts to strain about eighteen months in, once the library is full, the folders run deep, and permissions have sprawled.

Three things decide whether SharePoint works for you: which use cases actually fit, which limits bite at scale, and which of those you can design around. Get them right and SharePoint is an excellent DMS.

How Companies Use SharePoint as a DMS

Adoption falls into a few clear patterns. Each one starts from the same place: files scattered across network drives, and no fast way to find the right version.

Legal and historical archives. Law firms and legal departments digitise large paper archives so decades of records become searchable instead of sitting in boxes.

Construction job files. Contractors pull everything tied to a job under one client ID: quotes, signed proposals, service records. Staff get the full project history in one place.

Controlled SOP libraries. Regulated and non-profit organisations host procedures with check-in, check-out, and version history, so only one approved copy is ever live. We build this often for care providers like Stora Sköndal and Inagården, where the document management and the intranet ship together.

Engineering and product documentation. Manufacturers file manuals, data sheets, and drawings by metadata such as Country or Project rather than by filename, so the same document surfaces across many contexts.

Case management on top of documents. Some go beyond storage. SHARE NOW built a claims-handling system on SharePoint and the Power Platform to replace manual damage and insurance work.

The Real Needs Underneath

Strip away the industry specifics and the same five needs come up:

• Searchability: find documents by keyword or metadata, not by remembering which nested folder they live in.
• Workflow automation: approvals and routing handled through Power Automate instead of email chains.
• A single source of truth: one current version, so no one has to ask "is this the latest?"
• Security segmentation: open areas for everyone, locked areas for HR and Finance.
• Cost consolidation: use the Microsoft 365 licences you already pay for instead of another standalone SaaS tool.

Meeting all five is easy. Any competent build does it in the first month, which is why nobody I talk to is asking whether SharePoint can do the job.

Keeping them met is the part I would plan for. You satisfy all five with decisions made before go-live. Real users and real volume arrive after it.

Common Technical Challenges You Will Actually Hit

Information architecture and governance

These three only surface after go-live, once real users and real volume arrive.

Structure decays without a deliberate model. SharePoint imposes no information architecture, so libraries sprawl as every team adds folders its own way. Aspia's old platform got so hard to navigate that people gave up and kept local copies, until we rebuilt it around global and per-unit menus with content targeting.

Consistency breaks as you add departments. Nothing forces two teams to organise the same way, so structure drifts as sites multiply. Landskrona City needed one intranet spanning departments and frontline staff, which only holds together on a governed structure, not site-by-site improvisation.

Customisation becomes a maintenance bill. Every customisation is something you own through the next platform update. Stockholms Sjukhem swapped a heavily customised intranet for a standardised SharePoint Online build precisely to make governance cheaper.

Storage cost and version bloat

SharePoint feels free because it ships with E5. Storage is not. Organisations get roughly 1TB at the tenant level plus 10GB per licensed user, and beyond that additional storage runs roughly $200 per terabyte per month, or $2,400 a year for a single extra TB.

Version history compounds it. For non-Office files like PDFs and CAD drawings, SharePoint stores a full copy for every version, and the default keeps up to 500 versions per file. A single active library can quietly cost more than the SaaS tool you replaced.

Microsoft 365 Archive can cut the rate to about $0.05/GB for cold content. Reactivation is free, but archived files stay out of Copilot and cannot be re-archived for four months after you pull them back. If Copilot is on your roadmap, that gap matters, and getting SharePoint ready for Copilot is its own workstream.

OneDrive sync limits

Most users expect a SharePoint library to behave like a mapped network drive in File Explorer. OneDrive sync is what makes that work, and it has a hard ceiling. Microsoft's documented recommendation is a maximum of 300,000 synced items per user, counted across every library they sync, not per library.

Past that, sync degrades in practice: it stalls, loops on "processing changes," and can stop reflecting the latest version of a file. A 2026 preview lifts the ceiling toward one million items, but only on devices that meet new hardware requirements (Windows 11, 16GB or more of RAM, an SSD). Everything else stays at 300,000.

In a company with millions of files, File Explorer stops being a reliable way to work, and you have to move people to the browser or a different access method.

Path limits and permission inheritance

Because SharePoint is web-based, every file lives at a URL, and that URL has a hard limit: 400 characters for the full decoded path, counting the site, library, folders, and file name together. Deep folder trees copied straight from a file server routinely exceed it, and those files fail to migrate or sync until someone shortens the path.

Permissions are the slower and more dangerous problem. SharePoint lets anyone with rights break inheritance and set unique permissions on a single folder or file.

Do that a few thousand times and no one can answer a basic question: who can actually see this document? 

It stays invisible until a security review or an external-sharing incident forces the audit, which is what generates the most calls to us.

Fixing The Failures That Cost The Most

You cannot pre-empt everything. You can defuse the expensive failures with a few decisions made before migration, not after.

To stop storage costs from compounding, deal with volume before you migrate. Audit what is actually active, and move cold data into a separate "attic" library that keeps its original folder structure. Then pick an archive method by how often the data gets touched:

• For files people still reopen, offload them to Azure Blob with a tool like Layer2 ShArc while SharePoint stays the front end
• For genuinely cold data, native Microsoft 365 Archive is cheaper

Finally, switch libraries from the manual 500-version default to automatic version history limits.

To keep File Explorer usable past the sync ceiling, stop syncing whole libraries. Replace library sync with "Add shortcut to OneDrive," which is far more stable, or map SharePoint as a drive letter using a tool like Cloud Drive Mapper, which sidesteps the OneDrive sync client and its 300,000-item limit entirely. For the largest libraries, push people to the browser, where the limit does not apply.

To keep permissions auditable, flatten the structure instead of migrating the mess. Use a separate site collection per department rather than deep nested folders, and grant access through Entra ID groups, never individual users, so group membership is the only thing you manage.

For tenant-wide oversight, SharePoint Advanced Management adds admin-level controls for access, sharing, and content. Then add backup. Microsoft 365 Backup now covers this natively.

A Practical Next Step

Precio Fishbone designs and runs SharePoint as a document management system on Microsoft 365, across care, healthcare, business services, and the public sector, from Aspia's document findability to Stockholms Sjukhem's move off a heavily customised intranet.

If you want to find these traps before you pour data in, a SharePoint architecture and governance review is the place to start. To talk through what a governance review would surface in your environment, contact our team.

Frequently Asked Questions