Why Construction Teams Are Moving Spatial Data Off SharePoint

SharePoint runs the document management for a substantial fraction of the global construction industry. RFIs, submittals, contracts, drawings, specifications, meeting minutes, transmittals — for documents, it works. Most large construction projects are unimaginable without it.

But over the last five years, the deliverables that flow through a construction project have changed. The proportion that are documents — Word files, PDFs, spreadsheets — has shrunk relative to the proportion that are spatial data. Drone orthomosaics. LiDAR point clouds. IFC models. 3D photogrammetric captures. As-built scans. Progress videos. The new categories don’t fit the document management pattern, and SharePoint shows the strain at exactly these edges.

This post is about where the strain shows, why it matters, and what construction teams are doing about it.

What’s flowing into projects now

A modern construction project — say, a mid-sized commercial build, a transport infrastructure job, or a multi-stage subdivision — receives spatial data continuously. A representative monthly inflow:

• Drone orthomosaics and digital surface models from the monthly progress flight (5–15 GB)
• Terrestrial LiDAR scans of areas under active construction (10–40 GB)
• IFC models from the BIM coordination process (variable; often updated weekly)
• 360° photo tours of completed areas for record purposes (1–5 GB)
• Progress video for stakeholder reporting (5–20 GB)
• As-built point clouds for quality verification (variable, sometimes very large)
• 3D models from specialist subcontractors (façade, MEP, structural)
• Survey data from boundary, levels, and setting-out work

This isn’t an outlier project profile. This is what an average mid-sized job looks like today, and it’s growing. The sites where this data isn’t flowing are the sites that aren’t keeping up with industry practice.

For background on the formats themselves, see what is an IFC file, what is a point cloud, and what is a GeoTIFF.

Where SharePoint shows the strain

SharePoint isn’t bad at any single thing the construction industry asks of it. It’s just optimised for documents, and spatial data has different shape and different needs.

File size limits and upload reliability

SharePoint’s per-file upload limit (currently 250 GB on most plans) is high in the abstract and low in practice. Most spatial files fit. But the reliability of large uploads is the problem: a 4 GB LAS file uploaded over a typical office connection takes long enough that any connection blip restarts it. Surveyors and drone contractors regularly report spending an hour uploading the same file three times because the connection dropped at 80%.

Multi-part uploads with resume-on-failure — the standard for direct-to-cloud-storage transfer — would solve this. SharePoint’s web upload doesn’t natively offer it for arbitrary file types.

No viewers for spatial formats

This is the biggest gap. SharePoint can render Office documents in the browser. It cannot render LAS, LAZ, E57, GeoTIFF, IFC, OBJ, FBX, or 3D Tiles. The user has to download the file and open it in specialist software.

In a construction project, this means the people who most need to see the spatial data — site engineers, project managers, client representatives — usually don’t. The data is technically delivered. It’s effectively unused.

Document organisation, not site organisation

SharePoint’s organisational model is libraries and folders. Construction projects map onto this awkwardly. A project library typically has a folder structure like 01_Contracts / 02_Design / 03_Construction / 04_Survey / 05_QA. Spatial deliverables tend to land in 04_Survey and stay there, organised by month or by survey contractor.

What’s missing is the site dimension. A point cloud belongs to a specific physical location — a section of the site, a particular building, a stage of the works. The folder model doesn’t capture this; everything just lives in the survey folder.

Audit trail is for documents

SharePoint’s audit features were built for document compliance — who accessed which contract, who downloaded which spec. They work well for that. They’re less useful for spatial-data-specific events: who viewed a point cloud (rather than downloaded the file), who looked at the orthomosaic for the disputed area, who accessed which session’s deliverables.

The events SharePoint captures aren’t wrong; they’re just not the events the spatial data conversation is about.

BIM workflows are bolted on

SharePoint isn’t a BIM common data environment (CDE). It can be configured to act as one with effort, and many firms run their BIM coordination through SharePoint folders and metadata. But the IFC files themselves are unviewable in the browser. Coordination requires that everyone download the model into Navisworks or Solibri or BIMCollab. The CDE in this configuration is essentially a file dropbox for BIM software.

Dedicated BIM CDEs (Autodesk Construction Cloud, BIM 360, Trimble Connect, others) solve this for IFC and BIM models specifically, but introduce their own siloing problem: the BIM data lives in one platform, the survey data lives in SharePoint, and the orthos and 360s live somewhere else again.

What’s replacing it

The pattern that’s emerging — and it’s emerging across both the contractor side and the asset owner side of construction — is that spatial data moves to a spatial-data-specific platform, while documents stay in SharePoint. The two systems coexist. SharePoint keeps doing what it’s good at; spatial data goes where it can actually be used.

A spatial-data-specific platform looks like the site record model:

• The project is broken into sites — physical locations or stages of the works
• Spatial deliverables are uploaded against the relevant site, time-stamped to capture date
• Every format renders in the browser without plugins or downloads
• Access is controlled per site, with audit logs that capture viewing as well as downloading
• Share links can be issued for specific sites or specific sessions, with branded delivery to clients, subcontractors, or asset owners

For the construction project, this means the survey data is finally usable. The site engineer pulls up the latest progress orthomosaic on their tablet at the job site. The project manager checks the recent point cloud against the design model. The client representative reviews the monthly progress video without having to install anything.

For more on what the construction-side experience looks like, see file sharing for construction and send large files to clients construction.

What stays in SharePoint

Most construction documentation should still live in SharePoint. The split is roughly:

The principle: documents stay where document workflows already work. Spatial files move to where they can actually be viewed.

This split doesn’t require any heroic change management. The survey contractor delivers their spatial data into the spatial platform; everything else continues to flow through SharePoint as it always has. The PDF report from the survey can live in either place; both are accessible.

What changes for the BIM team

For BIM coordinators specifically, the spatial data platform isn’t a replacement for the dedicated BIM CDE. The CDE remains the place where the active coordination happens — clash detection, model versioning, federated views, the day-to-day work of BIM coordination.

The spatial platform sits alongside, providing the site record that the BIM model attaches to. It holds the as-built scans the model is being verified against, the survey data the model was built on top of, the photogrammetric captures of existing conditions, and the cross-references to construction reality that the BIM model itself doesn’t contain.

For asset owners taking handover, the IFC model and the as-built point cloud and the construction-period progress imagery all need to live somewhere persistent — outside the project-specific BIM CDE, which often gets archived once the project closes. A spatial site record keyed to the asset’s address gives the asset owner a single place to find all of it for the rest of the asset’s life.

What changes for the asset owner

The bigger story is on the asset-owner side of the handover. When a construction project completes, the asset owner takes possession of a building, an infrastructure asset, or a portfolio of properties. They also take possession of — or are supposed to take possession of — the documentation supporting that asset.

In the current pattern, the documentation arrives as a final handover deliverable: a hard drive, a SharePoint export, a series of emails with WeTransfer links. The asset owner ingests it into whatever system they use, the BIM model goes into facilities management software (sometimes), and the bulk of the spatial data goes into a folder somewhere that nobody opens again.

A site-based record is a different handover. The construction project’s spatial data record is already organised against the asset’s physical location and time-indexed across the construction period. The handover is, effectively, a transfer of the platform tenancy or an integration into the asset owner’s existing tenancy. The asset owner inherits a record that’s already in a usable form.

This matters because the asset owner is going to keep capturing data against the same location for the rest of the asset’s life. Routine inspections, maintenance work, refurbishment projects, eventual modifications. The construction-period record becomes the baseline that everything else is added to. Five years later, the operations team can pull up the asset and see the full history from foundation pour to most recent inspection.

For more on the asset owner perspective, see the asset owners page.

Getting started

For a project team currently running everything through SharePoint, the transition doesn’t have to be ambitious:

1. Pick a single project — ideally one with a heavy spatial data component, like a job that’s getting regular drone flights or an infrastructure project with active LiDAR scanning.
2. Set up the project as one or more sites in the spatial platform. Don’t migrate historical data; route new captures only.
3. Tell the survey and drone contractors where to deliver spatial files going forward. They will usually be relieved — uploading to a platform with multi-part upload and direct browser viewing is easier than fighting SharePoint’s web upload.
4. Continue everything else through SharePoint. Don’t fight the established workflow.
5. After a month, the project team can compare. The spatial data is being used; the SharePoint workflow is unchanged. Expand to the next project.

The change is incremental, the disruption is small, and the upside is that the spatial data on the project finally gets seen by the people who need it.

Why this is happening now

The shift isn’t ideological — nobody is replacing SharePoint because they don’t like it. The shift is that spatial deliverables have become a large enough fraction of construction project content that the gap in SharePoint’s spatial handling has become operationally significant. Five years ago, it was tolerable. Today, it’s costing time and money on every project.

Construction firms are pragmatic. When the cost of the workaround exceeds the cost of adding a dedicated tool, the dedicated tool wins. For spatial data on construction projects, that crossover happened a couple of years ago. The tooling is just catching up to the workflow that the industry already needs.