How to export your data from SharePoint without losing version history
SharePoint content can leave through a few documented paths, but no single button moves a full tenant with its version history, permissions and site structure intact. Document libraries are the part that exports as files. Lists, site pages, workflows and permission settings do not come out as usable data, so they need their own inventory and rebuild plan. A renewal date, a licensing change or a residency deadline sets the clock, which is why the export should start with an inventory of sites, libraries, file counts, sizes and versions before anyone runs a download. Treat the whole exercise as a project with verification, not a copy operation.
The most common route is a download from the library or site, but it is not built for a full exit. Bulk downloads are limited, and long file paths can fail to copy, so the failures often appear only after the transfer looks finished. Sync clients copy the current file, not the version history behind it. For version history, Microsoft Purview eDiscovery can export SharePoint and OneDrive content as native documents, with a choice of which versions to include. Search export packages expire 14 days after creation, and exporting requires a Microsoft 365 E3 or E5 license, so confirm with your tenant administrator that the account and license are in place before the window opens. The eDiscovery export documentation lists the export options. Microsoft's own migration tool only moves content into SharePoint, so it does not help with an exit.
Verification is what makes the export defensible. Compare exported file counts, version counts, sizes and path lengths against the inventory, library by library, and log every mismatch with its cause. Keep a separate manifest for what cannot travel as files, including permission groups, column metadata, retention labels and list definitions, because the destination will need it to rebuild access and structure. Ask any partner for a written scope that names the libraries, the versions in scope, the verification method and the acceptance criteria before work starts. Once the files are in the destination, such as a self-hosted Nextcloud instance, run a sample of restores and opens in Collabora Online to confirm that the documents work as they did in SharePoint.
What SharePoint lets you export and in which formats
This table maps each SharePoint and OneDrive data type to the export method Microsoft documents for it, the format that comes out, and the limits to check before you plan a copy. The eDiscovery route keeps version history but depends on licensing and short-lived packages, while simpler downloads carry less structure and metadata. Microsoft changes export limits over time, so confirm each limit against current Microsoft documentation before you set a schedule.
| Data type | Documented export method | Output format | Known limits and checks |
|---|---|---|---|
| Document libraries | Microsoft Purview eDiscovery search, exported as native documents | Native files such as .docx, .xlsx and .pdf | Requires an E3 or E5 license. Search export packages expire 14 days after creation. |
| Version history | Purview eDiscovery export with selectable version history | Native documents, one per selected version | Choose versions deliberately, since large histories increase package size. Test one library first. |
| Folder structure | eDiscovery package or ZIP download of the library or folder | Folders in the package or archive | Confirm the package layout in a test export. Long paths can break copies, so check them first. |
| Metadata (columns, authors, dates) | Check Microsoft's current documentation for whether eDiscovery exports include column values | Native files, plus any load file or report Microsoft documents | Plain file downloads may not carry SharePoint column values. Ask for a sample export and inspect it. |
| OneDrive content | Purview eDiscovery export of OneDrive content as native documents | Native documents with selectable version history | Same license requirement and 14-day package expiry as SharePoint content. |
| Mailbox items linked to the project | Purview eDiscovery export of Exchange mailbox items | PST or .msg files | PST files need an import path into the target mail platform. Each .msg file holds one item. |
| Bulk copies with long or blocked names | Downloads or copies from the library, outside eDiscovery | Partial or failed copies where paths exceed limits | Shorten or rename paths before export. Verify file counts after each copy. |
| Bulk migration tooling | Microsoft's own migration tool moves content into SharePoint and OneDrive | Not an export path | Plan a separate export route. Confirm the current scope of Microsoft's tools with Microsoft. |
What does not export from SharePoint and how to work around it
Document libraries are the easy part of a SharePoint exit. Permissions, list data, pages, workflows and metadata either have no file form or have no documented export path, so they need an inventory and a rebuild plan before the first copy starts. The cards below cover each gap and the workaround that fits it.
Site permissions and groups
Permissions are not stored as file attributes, so a copy of a library carries no record of who could see what. Export the membership of each site group, the unique permission levels on libraries and folders, and any sharing links that were created, into a spreadsheet before the export starts. Map those groups to Nextcloud users, groups or shares during the rebuild, and check that nothing was granted through a broad group such as all company users. Treat this inventory as the record of access, since it cannot be recovered from the copied files.
List items and their columns
SharePoint lists hold rows with typed columns, lookups and attachments, and a file export keeps only the attachments. Where the list view offers export to a spreadsheet, use it to capture the columns and values as CSV, and record the column types and lookup targets separately because CSV does not carry them. Expect to rebuild the list as a database or table in the target platform, then re-import the CSV and check row counts against the source.
Site pages, news and wiki content
Modern site pages and news posts are stored as page objects with embedded web parts, not as documents. The page body, images and layout do not come across in a library export, so the content needs to be copied by hand or through a scripted extraction of the page text and images. Decide early whether pages move to a wiki such as XWiki or to Nextcloud Collectives, and record which pages are current, which are drafts and which are retired.
Power Automate flows and workflows
Flows, approval workflows and classic SharePoint workflows run in Microsoft's service and are not exported as files. A library export carries the documents but not the triggers, conditions, approvers or the connectors they used. Export each flow definition where your tenant allows it, list every flow that touches the site, and document the business rule behind each one. Plan to rebuild them in an automation tool or as explicit Nextcloud processes, and test them against sample files.
Custom solutions and web parts
Custom web parts, SharePoint Framework solutions and add-ins contain code and configuration that no file export can package. Their data is usually in external databases or in the same lists the solution reads. Inventory each solution, its owner, the data it reads and writes, and whether the business still uses it. Replace the features that matter with native target functions or small applications that you run yourself, and retire the rest.
Metadata that does not survive
Managed metadata, content types, custom column values and retention labels are stored in SharePoint or Purview, and most of them do not become file properties when files are downloaded. Export the column values per library with the list export, and check whether any values depend on term store entries that must be recreated. Record retention labels and their periods from the compliance center before the export, because a copied file keeps none of its label history. Confirm with your records team which of these must survive the move as searchable fields in the target.
Sequence for a complete SharePoint export and verification
This sequence turns a SharePoint tenant into a verified set of exported files, with version history where needed and a reconciliation report. Each step produces a dated artifact, so the team can prove what was exported before any content moves to Nextcloud.
Inventory sites, libraries, owners and sizes
A SharePoint administrator or site owner lists every site, document library, named business owner, approximate size and item count, using the admin center and library settings. The output is an inventory workbook with one row per library. The step is complete when the row count matches the site list in the admin center and every library has a named owner who can answer questions about its contents during the export.
Confirm licenses and admin roles
Confirm that the account running the export holds a Microsoft 365 E3 or E5 license, which Microsoft Learn lists as required for exporting. Confirm that the account holds the eDiscovery role needed to create cases and exports, and ask your Microsoft 365 administrator to document every other holder of that role. The artifact is a short access record listing account names, license types and role assignments. It is done when a test export of one small library completes under that account.
Run eDiscovery searches for each site
Create an eDiscovery case and build one search per site or library, scoped to SharePoint and OneDrive content, with the version option set if earlier versions will be needed. Record the item count each search returns in the inventory. The artifact is a search record for each site. Investigate any site where the count is zero or does not match the inventory before exporting.
Export packages within the 14-day window
Export each search as native documents with the version history option selected, so earlier versions travel with the files. Microsoft Learn states that search export packages expire 14 days after creation, so schedule the export and download in the same working session and log the creation date on each package. The artifact is a completed export package for every site. The step is done when each package shows a completed status and was downloaded before its expiry date.
Store packages in a controlled location
Move each downloaded package to storage that your security team controls, such as an encrypted volume with restricted write access and access logging. Generate a checksum for every package and record it in a manifest kept alongside the packages. The artifact is a manifest listing file names, sizes and checksums. The step is complete when a second person recomputes a checksum and gets the same value, and access to the store is limited to named staff.
Reconcile counts, sizes and versions
Unpack each package and compare file counts, total sizes and version counts per library against the inventory and the search records. Check for long file paths, blocked file names and files that were skipped or renamed during export, and list each one. The artifact is a reconciliation report with one line per library showing expected and actual values. It is complete when every library either matches or has a logged variance with a stated cause.
Resolve exceptions and sign off the record
Work through every variance with the library owner, re-export or copy missing content by a documented route, and rerun the comparison for the affected libraries. Keep the final report, the exception log and the manifest together as one export record. The artifact is that record, approved by the data owner. It is complete when no library has an open variance and the owner accepts the record before any migration begins.
How to verify an export before you rely on it
Treat the export as unverified until it has been reconciled against the source library. Start with item counts and total size per library, recorded from SharePoint before the export begins and again on the copy. Compare folder by folder rather than only at the top level, because a single missing subfolder can hide inside a matching total. Record the date and time of the source snapshot, since files edited during a long export will legitimately differ, and agree with the library owners how those differences will be handled.
Then sample for content and metadata. Open a set of files from each library, including the oldest, the largest, and any Office documents with co-authored or embedded content, and confirm they render and contain what was expected. Check that author, modified dates and custom columns survived the copy, since a plain file download may carry only the file name and timestamp. Where version history was requested, pick several files with multiple versions and confirm each prior version is present and opens. If the export came from a Purview eDiscovery package, confirm which version settings were selected, because that choice determines what the package contains. The Purview export settings are described in Microsoft's eDiscovery export documentation.
Finally, check for silent loss. Look for paths that exceed the length limits of the tool or the target file system, and for names with characters that were replaced, trimmed or collided during transfer. Compare file names in the source and copy using a script rather than by eye, and log every exception. Generate checksums for each file in the export and store the manifest with the copy, so that the integrity of the data can be shown later. Keep the verification record with the exit file as evidence of how the copy was checked. It supports the migration, but it does not replace an independent review by your auditor or assessor, and you should confirm with them in advance what format they expect.
What to plan before your Microsoft 365 contract ends
The cards below cover the decisions that set the pace of a SharePoint export: licensing, the export window, legal rules, target capacity and sign-off. Each one needs an owner and an answer before the export starts, because several of them close off options once access is reduced.
Confirm the eDiscovery license tier
Exporting SharePoint and OneDrive content as native documents with selectable version history through Microsoft Purview eDiscovery requires a Microsoft 365 E3 or E5 license. Ask your Microsoft account team or licensing administrator which tier your tenant holds and whether the people running the export have the roles they need. If the tier does not cover the export, plan for that gap now rather than during the cutover window.
Set the export window early
Search export packages expire 14 days after creation, so a download that starts late can fail and need a new search. Agree with the business owners when the content must be out of SharePoint and when read access will be reduced. Build a calendar that leaves room for a failed package, a re-run and a verification pass before any license or access change takes effect.
Agree retention and legal hold rules
Before you export or delete anything, ask legal counsel which sites, libraries and mailboxes are under legal hold or retention policies, and whether the export must preserve metadata and version history for them. Confirm in writing who decides when a hold is released. Exporting content does not release it from Microsoft-side holds, so record what was exported, when, and under which hold.
Plan the target environment's capacity
Estimate the total size of document libraries, version history and attachments with the business owners, then confirm that the target Nextcloud servers and object storage can hold them with room for growth. Check the storage that your chosen Nextcloud Hub version and database require. Ask who provisions and pays for that capacity, and whether it is in your own cloud account or data center.
Map the path and naming limits
Long paths and unsupported characters are common reasons copies fail. Before export, ask the site owners which libraries have deep folder trees or long file names, and agree how they will be shortened or renamed, and who approves changes. Record each rename so that links and permissions can be traced back to the original location during verification.
Name the verification sign-off owner
Decide who confirms that the export is complete before access is removed: file counts, folder structure, version history and permissions for each site. Name a business owner per site and a technical owner for the checks, and agree the acceptance criteria in writing. Without a named signer, a partial export can be treated as finished when access is cut off.
How much effort does a SharePoint export take and what does it need from us?
What makes a SharePoint export take more effort than expected?
Effort rises with the number of document libraries and sites, total content size, version depth, and how complex the permissions are. Each of these multiplies the checks needed after the copy. Deep version history means more files to reconcile, and broken inheritance means more groups to map. Legal holds, retention labels and custom lists or workflows add further work, because they either need a separate export path or no file equivalent at all. Ask the provider to show how each of these factors was counted in the estimate, rather than a single headline figure.
Which internal people does a SharePoint export need?
Most exports stall because no one with the right authority is available. Plan for four roles:
- A Microsoft 365 global or SharePoint administrator who can grant access, run exports and confirm tenant settings.
- A data owner for each site who decides what is current, what is archived and what must not move.
- A legal or records reviewer who signs off on holds, retention obligations and personal data before anything leaves the tenant.
- A named owner for the target environment who can provision Nextcloud and approve access groups.
Agree these names in writing before the work starts.
Can our own IT team export SharePoint content without outside help?
A small team can export a few libraries with the built-in download and sync tools, and this is reasonable for low volumes without legal holds. The gaps appear at scale. ZIP downloads from SharePoint Online are capped, and sync clients struggle with long paths and very large folders. Preserving version history, mapping permissions to groups and proving that counts and checksums match take specialist time. If the export is tied to a renewal or a deadline, weigh the staff hours and the risk of a partial copy against an external quote.
What should a written scope for a SharePoint export include?
A written scope turns a vague export into something you can check. Ask that it lists:
- Every site, library and folder in or out of scope, with item counts and total size taken from the tenant.
- How version history will be handled, including how many versions are kept.
- How permissions, groups and external sharing are mapped, and which items are excluded.
- How long paths, invalid characters and locked files will be detected and resolved.
- Legal hold and retention treatment, and who signs off.
- Verification steps, such as item counts, checksums and sample reviews, plus the acceptance criteria.
- Deliverables, responsibilities on each side and the change process.
What should we ask for in a quote for a SharePoint export?
Ask the provider to price the work by component rather than as one lump sum. Useful line items include discovery and inventory of the tenant, export tooling and runs, version and permission handling, verification, and any remediation of long paths or unsupported content. Ask which items are one-time and which recur, such as ongoing support after cutover. Request the assumptions behind each line, including the library count and data volume they used, so you can see what changes the number. Fixed-scope engagements agree deliverables and timelines in writing before work begins.
Which SharePoint content types need extra work during an export?
Document libraries are the simplest case. Lists, site pages, workflows, Power Automate flows and custom web parts usually have no direct file equivalent, so they need to be inventoried and either rebuilt or retired. Ask the provider to classify every site by content type early, since this decides whether the work is mainly copying files or also redesigning processes. Confirm in your own tenant which list and page types are in use before you agree a scope.
Does an export need access to a Microsoft 365 license or eDiscovery role?
Yes, some parts of an export depend on Microsoft 365 licensing and roles. Purview eDiscovery exports, which can carry SharePoint and OneDrive content with selected version history, require a Microsoft 365 E3 or E5 license according to Microsoft's documentation, and search export packages expire 14 days after creation. Confirm which licenses your organization holds, which administrators can create cases and export, and whether your legal team has access to the case. Also confirm whether any export will be made in a regulated or segregated tenant.
What evidence should we expect after a SharePoint export is finished?
Expect a written reconciliation that compares source and target. It should show item counts per library, total size, version counts for sampled files, permission mappings and a list of excluded or failed items with reasons. Ask for a sign-off record from each data owner and the legal reviewer. This evidence helps your internal audit or compliance team, but it does not replace an independent assessment. Confirm with your auditor which records they will ask to see before the export starts.
How DeployOpen scopes and delivers a SharePoint exit
DeployOpen plans and delivers the export as a fixed-scope engagement inside your own infrastructure, starting from an inventory of what SharePoint actually holds. The work covers extraction, verification and handover, so the exported libraries, versions and permission records can be checked before anything is switched off.
How we scope
- We inventory the sites, libraries, file counts, sizes and version depth you need to export.
- We identify paths that exceed Windows limits and agree how they are shortened or renamed.
- The written scope names which export routes apply, such as ZIP, eDiscovery or a migration tool.
How we build
- We set up export tooling and the target storage inside your own cloud account or data center.
- We run test exports on a sample library and compare file counts, hashes and version history.
- We record permission and group data alongside content so access history is not lost.
How we hand over
- You receive an export report listing scope, totals, exceptions and the verification results.
- We document each export step so your team can repeat or audit the process later.
- Exported data is handed over to your team with an agreed retention and deletion plan.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing first.
- Ongoing support, upgrades and continuous testing are available as a retainer.
- Ask for the quote to itemize tooling, storage, verification and handover effort separately.
