SharePoint Document Management: What Actually Makes It Work

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.

What Counts as SharePoint Document Management

A SharePoint document library is not a document management system until someone configures it as one. Four settings have to be applied deliberately: metadata and content types, version control, retention, and library-level permissions. Without them a library is an oversized shared drive with a better search box. Only versioning is switched on for you.

This is also where SharePoint, OneDrive, and Teams get confused with one another. OneDrive for work and school accounts is storage provisioned per user, running on SharePoint infrastructure. A standard Teams channel’s Files tab is a folder inside the team site’s default document library, while private and shared channels each get a site of their own. Document management settings live in the SharePoint layer in every one of those cases, which is why one policy reaches the files whichever door people use.

The distinction decides where to look when document management starts failing. If files are scattered because people email attachments or save to a personal OneDrive, the answer is a structured site with defined libraries and an agreed place for each kind of document. Buying a second system gives people one more place to save the same file. I have seen that funded before anyone tested whether the first option would have worked.

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.

The Four Settings That Make a Document Management System

Four settings separate a document management system from a folder tree: metadata and content types, version control, retention, and library-level permissions.

Versioning is the only one SharePoint Online switches on for you. Metadata comes first in the sequence, because search, retention, and Copilot grounding all depend on documents being classified consistently.

Metadata and content types

Metadata columns classify documents by department, status, client, or document type, so a library can be filtered and searched without anyone remembering where a file was filed. Content types group those columns into reusable definitions, so a contract and a meeting recording in the same library get classified differently and surface differently in search.

Retention is applied separately, through Purview labels set as a default on a library, folder, or document set. Content type and information management policies were retired in April 2026, and Microsoft ignores them wherever a retention label policy is in effect.

Version control and check-out

Versioning is already on in SharePoint Online document libraries, so the safety net exists and the real decision is how much of it to keep. Check-out is the part nobody switches on, and it stops two people silently overwriting each other on documents that several people revise.

One limit is worth settling before anyone trims version limits to save storage. For items under a retention policy or an eDiscovery hold, the library version limits are ignored.

Retention and records

Purview retention labels apply retention or deletion rules to documents, and records declaration locks an item against edits. The licensing line runs between those two jobs. Creating labels and publishing them for people to apply by hand is covered from Office 365 E3 upward. 

Applying a label automatically, whether as a library default or by matching sensitive information, needs an E5 tier plan or the Information Protection and Governance add-on, and so does declaring an item a record. Confirm which plan you hold before anyone commits to a compliance date.

Permissions set at the library level

Unique permissions decide whether a library is still manageable in year three. Microsoft recommends staying under 5,000 unique permissions on a single list or library, supports up to 50,000, and past 100,000 items you can no longer break inheritance or reinherit at all.

Folder-level exceptions accumulate fast, because anyone with rights can create one and nothing prompts a review. Grant access through Microsoft Entra groups so membership is the only thing to manage, and avoid nesting those groups, which Microsoft flags as a performance problem.

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