Sync SharePoint document libraries to Nextcloud

Sync document libraries from SharePoint to Nextcloud

Content Governance does not only move content once and walk away — it can keep a SharePoint document library and a Nextcloud Team Folder in step on a regular, scheduled basis. Files flow from SharePoint or SharePoint Online into Nextcloud with their version history and their metadata intact, run after run, for as long as you want the two to stay aligned. This is a genuine, repeatable synchronisation — not a one-shot export.

The headline is simple: you can absolutely sync files on a regular basis from SP/SPO to a Nextcloud Team Folder, complete with version history and metadata. Everything below explains how that works, what carries across faithfully, and where the honest limits are.

Summary

• Content Governance can synchronise files on a regular, scheduled basis from SharePoint / SharePoint Online into a Nextcloud Team Folder.
• Version history and metadata travel with the files; the sync is incremental, picking up only what is new or changed.
• SharePoint metadata maps into MetaVox, and the matching MetaVox columns and views are created automatically.
• Fidelity is not 100%, but information is preserved: managed metadata, content type, and sensitivity and retention labels become text columns; check-in/approval context goes into version names. The only thing not replicated is the permission model — re-establish it in Nextcloud (for example with Flow acting on the sensitivity label).
• Optionally, synchronised SharePoint files can be converted into .url stubs — click one and the file opens straight in Nextcloud.
• Files can be restored back to SP/SPO with version history; a custom job brings back the latest metadata from MetaVox, and a Content Governance .url stub restores especially cleanly by feeding the binary (and any new versions) back into the item.
• Keep the scope reasonable — up to roughly 50 libraries, not huge ones. This is targeted sync, not whole-tenant backup.
• The whole thing is managed from a dedicated team in Microsoft Teams, and all SMART BI Power BI reporting is fully enabled.

Synchronisation is about keeping two worlds in step: SharePoint stays usable while Nextcloud fills up with the files, versions and metadata that matter — managed from Teams, measured in Power BI, reversible when you need it back, and faithful in every way Nextcloud can be. Aim it at the libraries that count, not at the whole tenant.

What synchronisation does

The input is the same familiar starting point used elsewhere in Content Governance: a URL pointing to a SharePoint document library. Content Governance scans the library, identifies the files that match your criteria, and writes them into the target Nextcloud Team Folder. On each subsequent run it picks up only what is new or changed — the sync is incremental, so the workload naturally tapers rather than re-copying everything every time.

For every synchronised file, Content Governance carries across:

• The file content itself
• The full version history, version by version
• The metadata, mapped into MetaVox in Nextcloud

What gets synchronised — at a glance

Metadata and MetaVox — created for you, automatically

You do not pre-build anything in Nextcloud by hand. Content Governance reads the SharePoint library’s columns and automatically creates and maps the corresponding MetaVox columns — however many columns the library defines. SharePoint metadata maps directly to MetaVox, and can be transformed or combined along the way. The result is that your SharePoint metadata investment is preserved in Nextcloud, keeping content searchable, classifiable, and governable rather than landing as a flat pile of files.

Fidelity: Nextcloud is not SharePoint

This is the part to be clear-eyed about. Fidelity in Nextcloud cannot be 100% identical to SP/SPO — Nextcloud simply does not have every feature SharePoint has. The important point is that Content Governance preserves the information; it represents some SharePoint-specific constructs in a Nextcloud-native way rather than as an exact replica.

How the main SharePoint-specific items are handled:

• Managed metadata (the Term Store) — captured into a text column in MetaVox. The values are preserved and searchable, but it is not the SharePoint term store itself.
• Content type — mapped to a text column. The sensitivity label and the retention label are handled the same way: each is carried across as a text column value.
• Check-in / check-out comments and approval status / approval comments — folded into the version name in Nextcloud, so that context travels with the version rather than being lost.
• Permissions — not replicated. This is an unavoidable architectural difference: SharePoint’s permission model (per-item permissions, inheritance, Entra principals and sharing links) has no direct equivalent in Nextcloud’s group-and-Team-Folder model. See the manual page on access to Nextcloud Team Folders for how Content Governance manages its own access.

Permissions can still be re-established in Nextcloud — just by a different route. Because the classification travels across as metadata, Nextcloud Flow can automatically set permissions on files based on that metadata: for example, restricting access to every file that carries a particular sensitivity label. You re-derive access from the data rather than copying SharePoint’s ACLs across.

Treat MetaVox as a faithful home for your content and its metadata, not as a pixel-perfect clone of SharePoint’s governance surface. Files, version history and metadata all come across — managed metadata, content type, and sensitivity and retention labels as text columns, and check-in/approval context in version names. The one thing that genuinely does not carry over is the permission model, which must be re-established in Nextcloud — something Nextcloud Flow makes straightforward. Plan around that rather than expecting an identical platform on the other side.

Optional: convert the SharePoint source into .url stubs

Alongside the sync, Content Governance can — if you want it to — convert each synchronised SharePoint file into a lightweight .url stub that points to the file’s new home in Nextcloud. When a user clicks the stub in SharePoint, the file opens directly in Nextcloud — the experience stays familiar even though the binary now lives elsewhere. The stub carries zero storage footprint, so SharePoint storage is reclaimed immediately, and it guarantees a single version of truth: no file is editable in two places at once.

*The .url stub is a powerful option, but it is not the point of this article. The point is the ongoing, reliable synchronisation of files, versions, and metadata from SP/SPO into Nextcloud. Stub conversion is simply something you can layer on top when you also want to retire the SharePoint copy.

Restore: bringing files back from Nextcloud to SP/SPO

The direction can be reversed: files in Nextcloud can be restored back to SharePoint / SharePoint Online. As with everything else here, a 100% identical restore is not possible — for the obvious reason that Nextcloud is a different platform from SP/SPO and never held every SharePoint-specific construct in native form. What can be restored is the substance: the file together with its version history.

Two situations are worth distinguishing:

• A normally synced file. A custom job can be built in the Content Governance engine to restore the file with its version history and to bring back the metadata for the latest version from MetaVox, writing it onto the SharePoint item.
• A Content Governance .url stub. When the SharePoint item is one of Content Governance’s own .url stubs, restore is especially clean: the metadata is restored straight back onto the item, and Content Governance essentially feeds the binary content back into the stub — turning it back into a real document in place. Any new versions added while the file lived in Nextcloud are included in the restore.

Managed from a dedicated Teams team — super simple

The whole operation runs from a dedicated management team in Microsoft Teams. Jobs are defined and controlled through simple SharePoint lists connected to Teams: create a list item describing the source library, the target Team Folder, and the schedule, and Content Governance does the rest. Progress and status are written back to the same list item, so you monitor and manage everything without leaving the Microsoft environment. No PowerApps, no Power Automate flows, no custom Teams app — it is built on out-of-the-box SharePoint features.

Full Power BI visibility — every file, everywhere

All of the SMART BI Power BI reporting is fully enabled for synchronisation. You get a complete, file-level view of what exists, what has been synced, and exactly where every file lives — across the whole tenant if you wish — including version counts, true version-aware volumes, content types, and metadata. Because the BI data is sourced from an external SQL Server or PostgreSQL database, stakeholders can analyse progress and content without any access to the synchronisation server itself.

Keep it sensible — don’t shoot yourself in the foot

The same practical limits that apply to offloading apply here, and they are not optional niceties — they follow directly from how SharePoint works. Synchronisation is fast and reliable when you aim it well, and slow and frustrating when you don’t:

• Keep the scope reasonable. As a rule of thumb, do not sync more than a few dozen libraries (around 50), and certainly not very large ones holding hundreds of thousands — or millions — of folders and files. This is simply not feasible: it takes real time to scan the source content, and not least to compare it against the destination Nextcloud Team Folder on every run. That is an unavoidable fact of SharePoint’s underlying architecture.
• Avoid oversized libraries. Microsoft itself does not recommend very large document libraries (list view threshold limits, among other reasons). Smaller, well-structured libraries sync faster and more reliably.
• Keep criteria simple. Hunting for a handful of files inside a library holding hundreds of thousands — or millions — across many folders is extremely time-consuming. Do not force the engine to comb an enormous library for a few narrow matches.
• Don’t over-scan. Initiating a scan and locating files takes time (a SharePoint limitation). Match the cadence of synchronisation to how often the source genuinely changes rather than sweeping constantly for the sake of it.

This is a targeted synchronisation feature for reasonable numbers of files and libraries — not a tool for replicating an entire tenant into Nextcloud as a backup. If whole-tenant backup is the goal, this is the wrong instrument; point sync only at the specific libraries that genuinely need to live in Nextcloud.

*Use SMART BI first to see where your content and your volume actually live, then point synchronisation at well-structured libraries with broad, simple criteria. That is how you keep the sync fast, predictable, and cheap to run.