How to Export Data from SharePoint: Methods, Limits & Migration Prep

How to Export Data from SharePoint: The Quick Answer

There is no single "Export Everything" button in SharePoint. Getting your data out means choosing a different method for each data type — lists, document libraries, site content, permissions — and accepting that every native method silently drops something.

If your goal is a compliance-grade extract or a platform migration, native exports will not cut it. The "Export to Excel" and "Export to CSV" buttons are built for quick ad-hoc pulls — they strip version history, ignore permissions, and hit hard row limits that are not always documented in the UI.

Audit data is a separate track entirely. SharePoint activity logging is exported through Microsoft Purview, not through content exports, with its own limits: up to 50,000 records per search for Audit Standard and 100,000 for Audit Premium. (learn.microsoft.com)

The practical rule: use native exports for spot checks, PowerShell for targeted metadata extraction, and API-driven approaches for anything migration-scale.

Many teams are tackling this now ahead of Microsoft's 2026 end-of-support timeline. If your estate relies on a legacy subsite architecture, the export is harder than it needs to be — see our dedicated guides.

Why Exporting Data from SharePoint Is Harder Than It Looks

SharePoint is not a standard file server. It is a complex relational database backed by SQL Server (on-prem) or Azure (Microsoft 365). It stores data in three fundamentally different containers — lists, document libraries, and site-level configuration — each with its own export constraints. Extracting data means untangling files from their associated metadata, permissions, and version histories.

The 5,000-Item List View Threshold

SharePoint Online uses the Large List Resource Throttling feature. By default, the list view threshold is configured at 5,000 items. When the defined item limit in a list is exceeded, the error message is displayed.

This limit exists to prevent SQL lock escalation, and it does not just affect the UI — the threshold impacts everything — from the UI to PowerShell to API performance and list configuration.

What trips people up: if the list view exceeds 5,000 items, Export to Excel fails, even if you're only exporting a subset. You can work around it by creating indexed columns and filtered views that return fewer than 5,000 items, but this requires pre-planning.

Folders help to a point. Microsoft notes that folder access benefits from an internal index, which is why a foldered library can behave better than a flat one. But a folder can still contain more than 5,000 items, and showing everything without the right indexed filter still gets you blocked. (support.microsoft.com)

The 400-Character Path Limit

The entire decoded file path, including the file name, can't contain more than 400 characters for OneDrive, OneDrive for work or school and SharePoint in Microsoft 365. The limit applies to the combination of the folder path and file name after decoding. Any document library with deeply nested folder structures will produce files that silently fail during export or migration.

Permissions Break at Scale

A list can have up to 30 million items and a library can have up to 30 million files and folders. When a list, library, or folder contains more than 100,000 items, you can't break permissions inheritance on the list, library, or folder. You also can't reinherit permissions on it.

The supported limit of unique permissions for items in a list or library is 50,000. However, the recommended general limit is 5,000. If you exceed 5,000 unique permission entries, expect slow exports and complex mapping.

The Deeper Architectural Problem

SharePoint blends content, metadata, and configuration in ways that do not map cleanly to a flat file. Exporting a document library is not "downloading files" — it is extracting the files, their custom metadata columns, their managed metadata term labels, their version history, and their permission inheritance chain. Miss any one of those, and your migration target will be incomplete.

A file download gets you binaries. It does not give you the full content type context, broken inheritance, or version chain. Microsoft is explicit that version history lives in the SharePoint library itself, and File Explorer–style copies only carry the latest or published version. That is why a job can look successful from a file-count perspective and still fail as a migration extract. (support.microsoft.com)

For a deeper look at why metadata architecture matters, see our guide to SharePoint information architecture: content types, metadata & lists.

Native Methods: Exporting Lists and Document Libraries to CSV/Excel

The built-in export buttons are the path most SharePoint admins try first. They work for small, one-off pulls. They fail for anything migration-scale.

Export to Excel (.iqy)

Navigate to any list or library → click Export to Excel in the command bar. This downloads an .iqy file that opens in Excel and creates a live data connection to the SharePoint list.

What it gives you: All columns visible in the current view, including some system metadata (Created, Modified, Author).

What it drops: Version history, permissions, attachments, lookup field values (rendered as Microsoft.SharePoint.Client.FieldLookupValue instead of actual values), and any column not in the selected view.

Hard limits:

• There is another limit in Excel — you can't export more than 52,000 rows from SharePoint into Excel.
• Filtered views on lists exceeding 5,000 items may throw the threshold error even if the view itself returns fewer rows
• Requires desktop Excel — does not work from Excel Online

Export to CSV (Native)

SharePoint Online also offers a direct Export to CSV option in the list toolbar. This is faster for basic downloads but even more limited.

When you choose the CSV export, this message appears: "Export finished. To protect service health, the CSV file contains first 30000 list items." That is a hard cap with no workaround through the native UI.

There is no native one-click CSV export for document libraries that gives you both files and metadata. Microsoft has noted that Export to CSV appeared on document libraries briefly by mistake and was removed. For libraries, native options are about file access: Sync, Add shortcut to OneDrive, or Download. Those are fine when humans need working copies on disk. They are not a high-fidelity export path for migration. (support.microsoft.com)

When Native Exports Are Enough

• Quick inventory of a small list (<5,000 items)
• Spot-checking column data before a migration
• Generating a one-time report for a non-technical stakeholder
• The destination only needs flat tabular data and you do not care about hierarchy, versions, or permissions

For anything else — especially if you are exporting data to move it somewhere — keep reading.

Using PnP PowerShell for Metadata and Document Extraction

PnP PowerShell is the standard workhorse for SharePoint export at scale. It bypasses native UI limits, supports pagination, and gives you control over exactly which fields you extract.

Auth note: Since September 9, 2024, interactive PnP logins require your own Entra ID app registration via -ClientId. For unattended or migration-scale runs, use certificate-based app authentication. (pnp.github.io)

Exporting List Items with Metadata

We can use the PnP PowerShell command Get-PnPListItem to get all list items from the given List/Document library. The key is the -PageSize parameter, which handles pagination automatically:

# Connect with app-based auth (certificate)
Connect-PnPOnline -Url "https://contoso.sharepoint.com/sites/yoursite" `
  -ClientId $ClientId `
  -Tenant "contoso.onmicrosoft.com" `
  -CertificatePath ".\cert.pfx"
 
# Export all items from a list, paginated in chunks of 1000
$items = Get-PnPListItem -List "Your List Name" -PageSize 1000
 
# Build export array with specific fields
$export = $items | ForEach-Object {
    [PSCustomObject]@{
        ID          = $_.FieldValues["ID"]
        UniqueId    = $_.FieldValues["UniqueId"]
        Title       = $_["Title"]
        Created     = $_["Created"]
        Modified    = $_["Modified"]
        Author      = $_["Author"].Email
        FileRef     = $_["FileRef"]
        ContentType = $_["ContentTypeId"]
        CustomField = $_["YourCustomColumn"]
    }
}
 
$export | Export-Csv -Path ".\list-export.csv" -NoTypeInformation

Exporting Document Libraries with File Content

Exporting document libraries is a two-part job: extract the metadata inventory, then download the actual files.

For the metadata inventory, use the same Get-PnPListItem pattern. For file downloads, use Get-PnPFile:

# Download all files from a document library preserving folder structure
$items = Get-PnPListItem -List "Documents" -PageSize 1000 |
    Where-Object { $_["FileLeafRef"] -like "*.*" }
 
foreach ($item in $items) {
    $fileRef = $item["FileRef"]
    $localPath = "C:\Export" + $fileRef.Replace("/sites/yoursite", "")
    $dir = Split-Path $localPath -Parent
    if (!(Test-Path $dir)) { New-Item -ItemType Directory -Path $dir -Force }
    Get-PnPFile -Url $fileRef -Path $dir -FileName $item["FileLeafRef"] -AsFile
}

For large document libraries, Get-PnPFolderItem requires the -List parameter once the library exceeds 5,000 items. (pnp.github.io)

Exporting Version History

Native exports silently drop all version history. PowerShell can extract it, but it requires per-item API calls — which is slow at scale.

As an administrator, there may be occasions when you need to export a SharePoint Online list version history to Excel for further analysis. We can export the list version history to Excel using PowerShell.

The approach: iterate through items, call the Versions property on each file object, then write each version's metadata (version label, modified by, modified date, check-in comment) to CSV. For document libraries with thousands of files and hundreds of versions each, this can take hours.

Query Languages: CAML, OData, and Graph

The query language depends on your export path:

• CAML shows up in PnP PowerShell through the -Query parameter.
• OData powers SharePoint REST: use $select, $expand, $filter, $top, and $skiptoken. Note that $skip does not work for SharePoint list items.
• Microsoft Graph uses ?$expand=fields(select=...) for list items. Lookup values are not returned by default, and Microsoft limits a single query to 12 lookup fields. (pnp.github.io)

Test your column set on a small sample first, then scale out. PnP gives you control; it does not remove SharePoint's schema quirks.

Throttling and Rate Limits

Even with PnP PowerShell, you will hit SharePoint's throttling if you send too many requests too fast. The symptoms: 429 Too Many Requests responses and exponentially slowing scripts.

Best practices:

• Use -PageSize 1000 or 2000 (not higher) for Get-PnPListItem
• Add retry logic with exponential backoff
• Run scripts during off-peak hours
• Use app-based authentication (certificate auth) instead of interactive login for unattended runs

Migration generates workload to the SharePoint backend differently from end user-generated traffic. To properly allocate resources with our elastic capability, only use app-based authentication in your migration solution. Don't use user mode in your migration solution. Running migration in user mode triggers increased throttling, resulting in poor performance.

Power Automate for Narrow, Repeatable Exports

Power Automate is useful when the job is narrow and repeatable: export items modified in the last day, dump one filtered folder, or watch a single library and push deltas elsewhere.

The defaults are conservative. Get items and Get files return 100 items by default; you can raise the working limit to 5,000, and filtered queries on lists over 5,000 items often need pagination turned on or you get partial or empty results. The connector also fails if the list or library has more than 12 lookup columns. (learn.microsoft.com)

Power Automate also has blind spots that matter during migration prep. Get changes for an item or a file requires versioning enabled, supports only column changes, and does not cover file content or attachment changes. Flow runs live inside Power Automate service limits, so a flow that works for nightly deltas can be the wrong tool for a one-time bulk export. (learn.microsoft.com)

The SharePoint Migration API and AMR API

For large-scale exports (tens of thousands of items, terabytes of content), the SharePoint Migration API and its companion Asynchronous Metadata Read (AMR) API are the infrastructure-grade options.

How the Migration API Works

The Migration API does not allow direct, synchronous file transfers. It relies on an asynchronous batch process:

1. Package creation: Data and metadata are bundled into XML manifest files.
2. Azure upload: Content and manifests are uploaded to Azure Blob Storage containers. Migration API uses Azure Blob Storage Containers for temporary storage of content and manifest. SharePoint provides default containers for migration.
3. Job submission: A migration job is submitted via CreateMigrationJob, pointing to the Azure container.
4. Queue processing: SharePoint processes the job asynchronously and writes logs back to the Azure container.

Before migration, customers must store manifest files and content in intermediary Azure Blob containers, which are accessed by import jobs. By default, customers can use SharePoint-provided containers at no cost, with migration jobs accessing them via SAS tokens.

SharePoint-provided containers are in the same datacenter as the tenant, unique per request, and automatically deleted 30 to 90 days after the job completes. If you use SharePoint-provided containers, the payload must be encrypted at rest with AES-256-CBC. (learn.microsoft.com)

The AMR API for Metadata Export

The SharePoint Asynchronous Metadata Read (AMR) API enables the asynchronous export of metadata from SharePoint and OneDrive. Use AMR API to export metadata from SharePoint for incremental migration and post-migration validation.

Performance benchmarks from Microsoft:

• AMR API exported about 400 items per second for every 250K objects, in the average case. The peak performance reached 700 items per second.
• AMR API cancels jobs that run over 10 minutes to protect the SharePoint infrastructure.

Key limitations:

• AMR is designed exclusively for import scenarios. It exhibits poor scalability when handling requests for metadata, permissions, or versions. We can't provide performance assurances for AMR usage in data export scenarios, such as cross-tenant migrations.
• Version reading is opt-in and defaults to off: A Bool value to indicate if AMR API reads multiple versions of files and List Items. Default value is false. When absent or set to false, AMR API only reads the latest version of items.
• Permission reading is also opt-in and generates additional XML in the manifest output

2026 deprecation note: Azure Queues are no longer required for export status tracking. Microsoft has announced that queue-based tracking is planned for deprecation in the second half of 2026. GetMigrationJobProgress is the status path to build around now. (learn.microsoft.com)

When to Use the Migration API Path

• Exporting from SharePoint Server (on-prem) to prepare for a cloud migration
• Extracting metadata for 100K+ items where PnP PowerShell would take days
• Building incremental sync workflows using change tokens
• Post-migration validation (comparing source vs. destination metadata)

For most teams without dedicated migration engineers, the Migration API's XML manifest complexity makes it impractical as a DIY approach. That is where third-party tools or dedicated migration services come in.

Comparing Third-Party SharePoint Export and Migration Tools

SPMT (SharePoint Migration Tool)

Microsoft's free tool for migrating on-prem SharePoint to SharePoint Online.

Strengths: Free, uses the Migration API under the hood, supports files, folders, list items, permissions, versions, managed metadata, bulk CSV/JSON task definitions, and incremental reruns. (learn.microsoft.com)

Limits:

• The SPMT also lacks detailed mapping options for custom metadata and managed properties, leading to data loss or inconsistency. Managed metadata is critical to the SharePoint Online environment, so you may need other options if the SPMT can't accurately transfer your metadata and properties.
• Version history migration is supported by SPMT, but the maximum number of versions that can be migrated is usually 500 per item.
• The SPMT also doesn't directly support custom solutions like workflows, complex web parts, or branding.
• The SPMT's reporting is limited and confusing, and the user experience needs improvement. It lacks detailed insights into specific migration errors or exceptions.
• The tool supports a 250 GB file size maximum for SharePoint migrations.
• Proxy connections are not supported when creating tasks

ShareGate

A desktop Windows application widely used for SharePoint migrations.

When you migrate content to Microsoft 365 in Insane mode, ShareGate Migrate uses Microsoft's Migration API to add functionality and improve performance. With Microsoft's Migration API, your content will first be uploaded to Azure storage and then imported to SharePoint by Microsoft 365.

Performance reality:

• As a rough planning estimate, ShareGate migrations often run around 10 GB per hour per machine, but actual throughput varies widely based on throttling, item count, and content complexity.
• The workstation you are running ShareGate Migrate on plays a large part in setting your options to optimize migration performance.
• ShareGate Migrate works optimally with 4 cores (64 concurrent threads).
• Scale-out requires multiple license activations on separate machines: Use multiple ShareGate activations with one migration per machine. ShareGate Pro supports 5 activations, Enterprise supports 25.

Insane Mode limitations:

• These actions are only supported by Normal mode due to technical limitations of the Azure Migration API or the ShareGate Migrate Server Extension. (ASPX pages, certain web parts)
• When copying a folder that contains multiple versions using Insane Mode, the folder ID changes at the destination. The ID of this folder will not be kept due to a limitation when folders have multiple versions.

Metalogix Content Matrix (Quest)

An enterprise-grade tool aimed at highly customized SharePoint environments. Supports granular mapping of content types, workflows, permissions, and SharePoint Designer form pages. Higher licensing costs. Best suited for organizations with complex on-prem customizations that SPMT and ShareGate struggle with. (support.quest.com)

How They Compare

How to Structure SharePoint Output for Migration

Exporting data is only half the job. The other half is making that output migration-ready — structured so the target system can ingest it without manual cleanup.

Map Permissions Before You Export

SharePoint permissions are hierarchical: site → library → folder → item, with inheritance that can be broken at any level. Before exporting, document:

• Which libraries have broken inheritance
• Which items have unique permissions
• How SharePoint groups map to the target system's role model

If you exceed 5,000 unique permission entries, expect slow exports and complex mapping. For a deep dive, see our SharePoint permissions and security best practices guide.

Flatten Folder Structures Where Possible

Deeply nested folders are the #1 cause of failed migrations. They hit the 400-character path limit, create permission inheritance chains that are hard to replicate, and do not map well to modern platforms that use metadata for organization.

Before exporting:

1. Audit path lengths — Use PnP PowerShell to scan for files exceeding 350 characters (leave margin)
2. Identify folders that should become metadata — A folder tree like Projects/2024/Q3/ClientName/Deliverables is better represented as metadata columns (Year, Quarter, Client, Type)
3. Consolidate redundant nesting — Remove empty intermediate folders

When exporting from SharePoint Server 2016/2019, you are likely moving from a legacy subsite architecture. Structure your export batches so that data from old subsites can be routed to independent, flat hub sites in the destination. See our guide on transitioning from subsites to hub sites.

Preserve Version History Intentionally

Not all version history is worth migrating. A document with 200 minor versions where someone toggled a checkbox is not the same as a contract with 5 major versions representing negotiation stages.

Before exporting, decide:

• How many versions to keep (latest only? Last 10? All major versions?)
• Whether to flatten versions into a separate archive table vs. migrating them as native versions in the target
• Whose versions matter — some targets do not support per-version author attribution

Export Checklist for Migration-Ready Data

• All list items exported with internal field names mapped to target field names
• All documents downloaded with folder structure preserved
• Custom metadata columns extracted (including managed metadata term labels, not just GUIDs)
• Lookup column values resolved to actual text (not FieldLookupValue objects)
• Version history exported for documents/items that require it
• Permission report generated per library/item
• File path audit completed — no paths exceeding target system's limit
• Content types documented and mapped to target equivalents
• Attachments on list items extracted separately (stored differently from document library files)
• Audit data exported from Purview as a separate workstream

A practical way to organize the output:

sharepoint-export/
  binaries/
  list-items/
  library-metadata/
  permissions/
  versions/
  audit/
  manifest/

Those splits exist because SharePoint stores versions, permissions, and audit output in different places and exposes them through different APIs. (support.microsoft.com)

A final practical rule: flatten folder structures only after you capture the original FileRef, FileLeafRef, object IDs, and parent-child relationships. That gives you rollback, QA, and a way to reconstruct the original SharePoint state if the target model turns out to be wrong.

When to Keep It In-House vs. Bring in a Migration Partner

DIY SharePoint export works when you have:

• A small number of sites (under 10)
• Simple metadata (no managed metadata, no complex content types)
• No version history requirements
• Time to iterate on scripts and fix edge cases

It breaks down when:

• You have hundreds of sites with inconsistent structures
• Managed metadata term stores need to be mapped to a different taxonomy
• The 5,000-item threshold forces you to manually chunk every large list
• API throttling turns a 2-hour export into a 2-day ordeal
• Version history and permissions must be preserved with audit-grade accuracy
• You are migrating off a legacy on-prem SharePoint approaching end of support

At ClonePartner, we have built custom extraction pipelines for SharePoint environments with millions of items across hundreds of sites. Our approach uses app-based authentication with automated retry logic to handle throttling gracefully, cloud-native execution that is not bottlenecked by a single desktop machine, and field-level mapping that resolves managed metadata, lookup columns, and people fields into clean, importable formats.

We handle the export, the transformation, and the load — so your team does not spend weeks writing and debugging PowerShell scripts.