SharePoint is genuinely good at a lot of things. It handles document storage, version history, permissions, and Microsoft 365 integration better than most tools in its category. Thousands of organisations use it effectively every day. The question is not whether SharePoint is a good product. The question is whether it was designed to do what a construction programme actually needs — and where the gaps appear when programmes scale.

This post is an honest, structured comparison. It covers what each tool was built for, where they overlap, where they diverge, and what the difference costs in practice on a major infrastructure programme. The goal is clarity, not a sales pitch.

Built for different jobs

The most useful way to understand this comparison is not to ask which tool is better, but which tool was designed for the job at hand. SharePoint and a CDE were built to solve different problems.

SharePoint — what it was designed to do

SharePoint is a Microsoft enterprise collaboration and content management platform, first released in 2001. It was designed for internal document sharing, intranet portals, team collaboration, and records management across general business functions — HR, finance, legal, marketing. Version history, check-in and check-out, permissions inheritance, and Microsoft 365 integration are genuine strengths, built and refined over two decades.

It is widely deployed across UK public sector organisations, which is precisely why it becomes the default choice when a construction team needs somewhere to store project documents. The path of least resistance is to use what is already in the IT estate.

A CDE — what it was designed to do

A Common Data Environment is a purpose-built digital environment for managing information across the lifecycle of a constructed asset. It was designed to implement the ISO 19650 information management framework: defined information states (WIP, Shared, Published), structured metadata, naming convention enforcement, formal approval workflows, transmittal registers, and model coordination.

CDE platforms — such as Oracle Aconex and Autodesk Construction Cloud — are built from the ground up for multi-organisation, multi-discipline project environments where information governance is a contractual requirement, not a preference.

SharePoint manages content. A CDE manages construction information governance. That distinction sounds subtle. In practice, on a major programme, it is the difference between a manageable register and a structured chaos.

Where SharePoint and a CDE do the same thing

An honest comparison starts by acknowledging genuine overlap. Both tools:

• Store documents and maintain version history

• Support role-based access permissions

• Integrate with Microsoft 365 to varying degrees

• Can be searched and audited to some extent

• Handle document libraries, folders, and metadata fields

The overlap is real. But it operates at different levels of rigour. SharePoint gives you a version history. A CDE enforces a version governance workflow. SharePoint gives you metadata fields. A CDE validates that metadata against a schema before a document can progress to the next information state. SharePoint gives you permissions. A CDE gives you multi-organisation, role-attributed, audited access control tied to project roles and information states.

The tools overlap in category but not in depth. This is what makes the comparison genuinely nuanced rather than a straightforward verdict.

Where the difference actually matters

The following five differences are not abstract feature gaps. Each one has a concrete, measurable consequence on a major infrastructure programme.

1. Information states vs version history

SharePoint tracks versions — you can see that version 3 exists and retrieve version 2. But there is no concept of a document state: whether a document is a working draft, available for coordination review, or formally approved and issued for construction.

In practice, teams fill this gap with naming conventions: _DRAFT, _FOR_REVIEW, _APPROVED. These conventions are inconsistently applied, manually maintained, and entirely dependent on individual discipline. On a programme with fifty organisations and thousands of live documents, that dependency fails.

A CDE enforces WIP, Shared, and Published transitions through workflow, not convention. No document reaches Published status without an explicit approval action by an authorised user. The state is part of the system architecture, not a label someone added to the filename.

2. ISO 19650 naming convention enforcement

ISO 19650 specifies a structured naming convention for all project information. SharePoint has no mechanism to validate filenames against a schema. A document can be named anything and saved anywhere. The register is only as organised as the people contributing to it.

A CDE validates naming at the point of upload. Incorrectly named documents are rejected before they enter the register. On a programme with thousands of documents across dozens of organisations, enforced naming is what makes the register searchable, auditable, and usable by the asset management team at handover. Unenforced naming produces a register that nobody trusts.

3. Multi-organisation access control

SharePoint was designed for intraorganisational use. Extending it to multiple external organisations — each needing scoped, role-appropriate access to a shared project environment — requires significant custom configuration and ongoing manual maintenance. Guest access, external sharing settings, and permission inheritance are not straightforward at programme scale.

A CDE is designed from the outset for multi-party project environments. Organisations are set up as distinct entities, users are invited with defined project roles, permissions are scoped by project and information state, and all access events are audited automatically. Onboarding a new organisation is a configuration task, not a custom development exercise.

4. Transmittal and formal issue management

On a construction programme, documents are not simply shared — they are formally issued via transmittals, with defined recipients, acknowledgement requirements, and a legal record of issue. Transmittals are the formal mechanism through which one party hands information to another, and they carry contractual significance.

SharePoint has no native transmittal functionality. Teams working in SharePoint manage transmittals separately: via email, a parallel spreadsheet register, or a bespoke add-on. This creates a split record — documents in one place, transmittal history in another — with no guaranteed link between them.

A CDE handles transmittals natively. Issue, receipt, acknowledgement, and full history are part of the system of record, linked directly to the documents they cover.

5. Model coordination and clash detection

As programmes adopt BIM, the document register extends to include 3D models that require federation, clash detection, and issue tracking between disciplines. Model coordination is not a document management feature. It is a distinct capability that connects the formal project record to the collaborative design process.

SharePoint can store an IFC file. It cannot coordinate one. Leading CDE platforms include model coordination modules that federate models from multiple disciplines, detect clashes, raise and track issues, and link those issues back to the document register. SharePoint has no equivalent capability, and no practical path to acquiring it through configuration.

Using SharePoint and a CDE together

A common pattern on large programmes is to use both tools — for different purposes. This is not a compromise. It is often the right architecture.

SharePoint handles what it does well: internal team collaboration, meeting minutes, action logs, HR records, and records management for non-project content. The CDE handles the formal project information register, approval workflows, transmittals, model coordination, and the ISO 19650-compliant document lifecycle.

The integration between the two is achievable and well-established: controlled sync from the CDE to SharePoint records libraries for archival purposes, Power Automate calling CDE APIs to pull document metadata for internal notifications, and deep links from SharePoint pages to specific CDE records. The key principle is that the CDE remains the system of record for all formal project information. SharePoint operates as a collaboration layer alongside it, not as a replacement for it.

For procurement teams facing internal pressure to use existing tools, this framing is often the most productive one. The choice is not SharePoint or a CDE. It is understanding what each tool should own.

When SharePoint is the right answer

SharePoint is a reasonable choice for:

• Small projects with a single organisation and a limited document count

• Internal-only document management where external organisation access is not required

• Programmes where ISO 19650 compliance is not contractually required

• Organisations that need a low-cost starting point and plan to migrate to a CDE as the programme scales

If the programme is small, single-organisation, and not subject to ISO 19650 requirements, SharePoint may be entirely sufficient. The problems begin when those conditions change — and on major UK infrastructure programmes, they almost always do.

Making the move: what a SharePoint-to-CDE migration actually looks like

The most common objection to adopting a CDE mid-programme is “we already have everything in SharePoint.” This is a real constraint, but it is not an insurmountable one. A structured migration is entirely achievable, and the effort involved is usually smaller than teams expect.

A well-run migration follows six stages:

1. Inventory — cataloguing what exists in SharePoint: sites, libraries, item counts, permission structures, and metadata

2. Mapping — translating SharePoint folder structures to ISO 19650-compliant CDE folder trees and metadata schemas

3. Transformation — enriching and normalising metadata, applying correct naming conventions, removing duplicates

4. Loading — moving content into the CDE via API, with the original SharePoint URL stored as a metadata field to preserve traceability

5. Validation — reconciling document counts, verifying permissions, confirming all file formats open correctly

6. Cutover — freezing SharePoint, completing a final delta sync, and going live on the CDE

Migration does not have to be a big-bang event. A phased approach — migrating project by project or programme by programme — is often more practical and lower risk. It also allows the team to build familiarity with the CDE on lower-stakes content before migrating the most critical records.

The bottom line

SharePoint is an excellent general-purpose collaboration platform. It was not designed for construction information governance at scale. The differences that matter — information states, naming enforcement, multi-organisation access control, transmittal management, and model coordination — are not gaps that custom configuration can fully close. They are architectural differences between a tool designed for business collaboration and a tool designed for construction programme delivery.

For small projects and internal collaboration, SharePoint may be entirely adequate. For major infrastructure programmes where ISO 19650 compliance, multi-organisation supply chains, and asset handover are in scope, the gap between SharePoint and a purpose-built CDE is significant — and measurable in time, rework, and risk.

If you are currently using SharePoint for project document management and recognise any of the gaps described above, the next step is a straightforward conversation about current state, target state, and what a transition would involve.

Get in touch now.