SharePoint to Notion Migration: The Complete Technical Guide

There is no native migration path from SharePoint to Notion. No importer, no connector, no "Move to Notion" button. SharePoint stores content as lists with typed columns, document libraries backed by SQL, and modern .aspx pages rendered with CanvasContent1 JSON. Notion stores content as recursive trees of block objects organized into databases with properties. These two data models are structurally incompatible.

The safe approach is a two-track move: extract SharePoint list and library metadata with Microsoft Graph or SharePoint REST, export files and list attachments separately, load flat records into Notion first, then rebuild relations, page bodies, and navigation in a second pass. Notion's official import options include CSV, HTML, Word, PDF, and ZIP — but not SharePoint. (notion.com)

This guide covers what actually breaks, which methods exist for getting data out of SharePoint and into Notion, and where each approach fails at scale.

For a platform-level comparison before committing to a move, see our Notion vs. SharePoint: The Definitive Guide for 2026.

Why Migrating from SharePoint to Notion Is Harder Than It Looks

The fundamental mismatch is structural, not cosmetic. In the Microsoft Graph API, a SharePoint list item exposes fields; document libraries also expose a related driveItem; and version history lives in a separate versions collection. In Notion, page content is stored as blocks, while structured records are pages with typed properties inside databases. The models are different at the storage layer, so there is no clean 1:1 import path. (learn.microsoft.com)

SharePoint lists have typed columns — Choice, Lookup, Person, Managed Metadata, Calculated — backed by SQL Server's AllUserData table. Document libraries are file repositories with metadata columns attached. Site pages are .aspx files rendered through web parts. Hierarchy comes from sites, subsites, and hub associations.

Notion databases are collections of pages. Each page is a block. Each block can contain child blocks, infinitely nested. Database columns are "properties" — Select, Multi-select, Relation, Rollup, Person, Date, Formula. The entire system is block-based and API-driven.

This creates three specific breaking points:

1. SharePoint column types don't map 1:1 to Notion properties. A SharePoint Lookup column references another list by internal ID. A Notion Relation property links to pages in another database. Managed Metadata (term sets) have no Notion equivalent at all.
2. Metadata that SharePoint tracks automatically gets lost in flat exports. Created By, Modified Date, Version History — CSV exports strip most of this. Notion's CSV importer doesn't have fields for these audit columns unless you create them manually.
3. Rich text and HTML from SharePoint pages break in Notion. SharePoint modern pages use CanvasContent1 JSON with web-part-specific rendering. Notion requires content as discrete block objects (paragraph, heading, image, callout). No native parser handles this conversion.

SharePoint scale behavior is the next problem. A list or library can store up to 30 million items, but the List View Threshold is 5,000 items for a database operation. Microsoft recommends indexed columns and filtered views to stay inside that boundary. (support.microsoft.com)

Notion has its own target-side limits. The public API averages about 3 requests per second (roughly 2,700 per 15 minutes), request payloads max out at 1,000 blocks and 500 KB, and one append request can add only 100 child blocks with up to two levels of nesting. Big SharePoint wiki pages, HTML-heavy knowledge articles, and large batches of inline files need chunking, retries, and queuing. (developers.notion.com)

For a deeper look at SharePoint's internal architecture — including hub sites, subsites, and content type inheritance — see The Modern SharePoint Architecture 2026.

How to Export SharePoint Lists and Document Libraries

Getting data out of SharePoint is the first bottleneck. Every native export method drops something. For a full breakdown, see our dedicated guide: How to Export Data from SharePoint: Methods, Limits & Migration Prep.

Start with an inventory, not an export button. Break the source into five tracks: list rows, document library files, list attachments, page content, and version metadata. Each track leaves SharePoint through a different path, and each track maps to Notion differently.

Native CSV Export

SharePoint's "Export to Excel" and "Export to CSV" buttons work for lists, but with significant limitations:

• They export only the current view — columns hidden in the view are omitted
• CSV export is capped at 30,000 rows and is not available for document libraries (support.microsoft.com)
• Created By and Modified By are exported as display names, not emails — useless for Notion's Person property
• Attachment columns are skipped entirely — you get the item row without its files
• Version history is not included

Native export is fine for quick snapshots or pilot migrations, but weak for anything that needs complete field coverage, repeatable reruns, or library file extraction.

Microsoft Graph API (Recommended for Metadata Extraction)

The Graph API is the only reliable method for extracting list items with full metadata, including createdBy, lastModifiedDateTime, and custom field values:

GET https://graph.microsoft.com/v1.0/sites/{site-id}/lists/{list-id}/items?expand=fields

Results are paginated — follow @odata.nextLink until it's absent. Graph supports $expand=fields(select=...) and $filter on listItem properties and fields. Microsoft notes that filtering works best on indexed columns. (learn.microsoft.com)

For file downloads at scale, use the Graph API's batch endpoint (up to 20 requests per batch) to parallelize file retrieval.

Document Library Downloads

Document libraries are a separate extraction path. In Graph, file content downloads from a driveItem endpoint:

GET /sites/{site-id}/drive/items/{item-id}/content

You can sync a library to OneDrive or download files via the browser, but you get files only — no metadata columns, no version history, no audit trail. If your documents have custom metadata (e.g., "Document Type", "Department", "Review Date"), none of it comes with the download.

This matters more than most teams expect: SharePoint supports individual files up to 10 GB, while Notion's simple file upload only covers files up to 20 MB before requiring a multi-part upload flow. If your library contains large design files, media, or long PDFs, file handling becomes an engineering task. (support.microsoft.com)

List Attachments

List attachments are where many first attempts fail. SharePoint exposes them through the AttachmentFiles REST path on each list item, not through a flat CSV export:

GET /_api/web/lists/getbytitle('{list-title}')/items({item-id})/AttachmentFiles
GET /_api/web/lists/getbytitle('{list-title}')/items({item-id})/AttachmentFiles('{file_name}')/$value

Use these endpoints to pull attachment inventories and binary content, then map each file back to its parent row with a stable source key. (learn.microsoft.com)

PnP PowerShell

PnP.PowerShell is a strong option if your team lives in the Microsoft ecosystem. Get-PnPListItem retrieves all items without the 5,000-item threshold issue:

Connect-PnPOnline -Url "https://contoso.sharepoint.com/sites/wiki" -Interactive
$items = Get-PnPListItem -List "Project Tracker" -PageSize 500
$items | Select-Object -ExpandProperty FieldValues |
  Export-Csv -Path "./project-tracker.csv" -NoTypeInformation -Encoding UTF8

For document libraries, Get-PnPFile downloads files programmatically.

Version History

Graph exposes list item history at /sites/{site-id}/lists/{list-id}/items/{item-id}/versions. Preserve versions only when you have a real reason: auditability, legal traceability, editorial history, or approval workflow evidence. For most knowledge-base migrations, a preserved Source Modified At field is enough; for regulated content, you need a separate audit archive. (learn.microsoft.com)

Mapping SharePoint Metadata to Notion Properties

This is where most DIY migrations silently lose data. SharePoint and Notion use different type systems, and the translation is rarely clean. Do the mapping before you import anything — the goal is not just to get data into Notion, but to get data into Notion in a shape the team can trust six months later.

For a detailed structural reference, see The Ultimate Guide to Mapping Notion Databases to SharePoint Lists.

Use a Two-Pass Loading Strategy

Serious SharePoint-to-Notion migrations use two-pass loads. Pass one creates the target databases and flat records with a Source ID field. Pass two resolves lookups into relations, rewrites People values where valid Notion users exist, and attaches files to the correct pages. If you try to do everything in one pass, relations and attachments are the first things to break. (developers.notion.com)

Relations Require Special Handling

SharePoint Lookup columns reference items in another list by internal ID. Notion Relations link pages by matching page references in a target database. This means:

1. Migrate the target database (e.g., "Departments") first
2. Ensure title values match exactly
3. Use the Notion API to set relation properties — CSV imports via Notion's "Merge with CSV" feature only work reliably for a limited number of entries, and Notion states that relation properties cannot be mapped during CSV import (notion.com)

Build a Provenance Layer

Always create permanent provenance fields in Notion: Source ID, Source URL, Source Created By, Source Created At, Source Modified By, Source Modified At, Migration Batch, and Migrated At. That single decision makes validation, reruns, and rollback far easier.

DIY Migration Methods: CSVs, Power Automate, Zapier, and Make

There are several common DIY paths. They solve different problems. Picking the wrong one is how teams end up three weeks in with half the content loaded and no clean rerun strategy.

CSV Export → Notion Import

Best for: Small lists (<1,000 rows) with simple column types (text, select, date).

Process:

1. Export the SharePoint list to CSV (ensure UTF-8 encoding)
2. In Notion, go to Settings → Import → CSV or type /csv on any page
3. Map CSV headers to Notion property types
4. Review the imported database

Where it breaks:

• Notion's CSV importer creates a new database — it doesn't merge into existing ones ("Merge with CSV" only appends and doesn't deduplicate)
• Relation, Person, Rollup, and Formula properties are not imported via CSV (notion.com)
• Files and attachments are not carried over
• CSV files are limited to 5 MB on Free plans and 50 MB on paid plans
• Rich text columns with HTML are ingested as raw HTML tags rather than rendered text
• SharePoint's regional date formats cause parse failures if not converted to ISO 8601

HTML or ZIP Import

Best for: Page-like content and simple document collections.

Notion ZIP imports support DOCX, CSV, Markdown, HTML, XLSX, and more — up to 5 GB per ZIP. Notion warns that very high file counts can fail even under the size limit, and imports of 10,000+ files are likely to fail or import partially. HTML import flattens complex layouts and is rate-limited to about 120 file imports per 12 hours. (notion.com)

Notion's HTML importer supports headings, paragraphs, lists, links, code blocks, simple tables, and images — but does not preserve complex styling, scripts, embeds, comments, or edit history. Use this when you have many simple docs and can tolerate post-import cleanup.

Zapier

Best for: Small ongoing syncs (new items in a SharePoint list → new pages in a Notion database).

Zapier supports a "New List Item" trigger from SharePoint and a "Create Database Item" action in Notion. Each Zap runs per-item.

Limitations:

• Not designed for bulk backfill — one item per trigger
• Cannot natively update Notion Relation properties (requires a "Code by Zapier" step calling the Notion API directly)
• No file transfer between SharePoint and Notion
• Permissions are not synchronized through triggers or actions (zapier.com)
• Rate limits on both sides compound: Notion's ~3 req/s average plus Zapier's plan-based task limits

Power Automate

Best for: Teams already in the Microsoft 365 ecosystem pushing SharePoint events to Notion.

Microsoft documents a Notion (Independent Publisher) connector for Power Platform, and also supports creating custom connectors from an OpenAPI definition. (learn.microsoft.com)

Power Automate is viable as a workflow engine for staged syncs, light backfills, or event-driven coexistence. It does not remove the need to design pagination, source keys, attachment handling, retry logic, or relation sequencing yourself. It works for trickle syncs — not for migrating thousands of existing items.

Make (formerly Integromat)

Similar to Zapier but with more granular control over iteration and HTTP requests. Make allows you to loop through SharePoint list items and create Notion pages in sequence. The same core limitations apply: one-at-a-time processing, no native file transfer, manual rate-limit management.

Rebuilding Your Knowledge Base Architecture in Notion

SharePoint's hierarchy is rigid: tenant → site collection → site → subsite → list/library → folder → item. Notion's hierarchy is flexible: workspace → teamspace → page → nested page → database → page (row).

Don't replicate SharePoint's structure in Notion. Deep folder hierarchies (7+ levels) in SharePoint are usually workarounds for the 5,000-item limit. Use the migration to simplify.

Flatten the Subsite Hierarchy

SharePoint subsites were a pre-hub-site pattern for organizing departmental content. In Notion, use top-level pages per department or team with nested pages underneath. There's no performance penalty for nesting in Notion, but deep nesting (5+ levels) makes search and navigation harder for users.

Convert Document Libraries to Databases

A SharePoint document library with metadata columns maps naturally to a Notion database with a Files & media property plus matching metadata properties (Select, Date, Person). Each document becomes a database page with the file attached.

Replace Folders with Database Views

Instead of recreating folder structures as nested pages, consolidate documents into a single database and use Select properties to tag by Department, Category, or Status. Create filtered database views on your team pages that display only the relevant subset. This gives you the organization of folders without rigid silos.

Linked Databases for Cross-Reference

SharePoint Lookup columns that reference other lists map to Notion Relations + Rollups. Create the databases first, establish Relations between them, then populate data. This preserves the referential integrity that CSV exports destroy.

Handle Rich Text and Page Content

If you're rebuilding pages through the Notion API rather than the importer, chunk aggressively. One append call can add only 100 child blocks, payloads max out at 1,000 blocks and 500 KB, and the API only allows two levels of nesting per append request. (developers.notion.com)

SharePoint pages with complex web parts or nested tables require custom parsing logic — your migration pipeline must parse the HTML into an Abstract Syntax Tree (AST) and translate each element into its corresponding Notion block object (heading_1, paragraph, bulleted_list_item, etc.).

Plan file handling carefully. Notion's file upload flow requires uploaded files to be attached to a block or property within one hour, and Notion-hosted download URLs expire after one hour as well. That's fine for scripted batch loads, but it's one more reason browser-driven manual uploads collapse once the file count gets serious. (developers.notion.com)

What a Custom API Migration Pipeline Looks Like

For teams with engineering resources, here's the architecture of a working SharePoint-to-Notion migration pipeline:

┌─────────────────┐     ┌──────────────────┐     ┌─────────────────┐
│  SharePoint      │     │  Transform Layer │     │  Notion API     │
│  (Graph API)     │────▶│  (Node/Python)   │────▶│  (REST)         │
│                  │     │                  │     │                 │
│  - List items    │     │  - Type mapping  │     │  - Create DB    │
│  - DriveItems    │     │  - HTML → blocks │     │  - Create pages │
│  - Attachments   │     │  - File staging  │     │  - Upload files │
│  - Versions      │     │  - Provenance    │     │  - Set relations│
└─────────────────┘     └──────────────────┘     └─────────────────┘

Pass 1 — Extract: Use the Graph API to pull all list items (paginated), document metadata, file content, and list attachments. Store locally or in cloud staging.

Pass 2 — Transform: Map SharePoint column types to Notion property types per the mapping table above. Convert any rich HTML content into Notion block JSON (paragraph, heading_1, bulleted_list_item, etc.). Stage files for upload. Generate provenance metadata.

Pass 3 — Load flat records: Create Notion databases with the correct schema. Insert pages with properties and basic block content. Populate Source ID fields for every record.

Pass 4 — Load relations and files: Resolve lookups to Notion relations using Source ID → Notion Page ID mappings. Upload files using the File Upload API (single-part for files under 20 MB, multi-part for files up to 5 GiB on paid plans). Handle rate limits with exponential backoff.

When to Hire a Migration Team

DIY works when:

• You have fewer than 500 list items and minimal attachments
• Your SharePoint data lives in one or two simple lists (text, choice, date columns only)
• You don't need to preserve Created By or version history
• You have an engineer who can commit a week to scripting and debugging

DIY breaks when:

• You have multiple interconnected lists with Lookup or Managed Metadata columns
• Document libraries contain thousands of files with custom metadata
• You need to preserve audit history (who created/modified what, and when)
• The SharePoint environment includes classic pages, InfoPath forms, or custom web parts
• The migration must happen without disrupting active users

At ClonePartner, we've built custom extraction scripts that handle the 5,000-item list view threshold, preserve original author and modification timestamps in dedicated Notion properties, and manage file attachments at scale — uploading directly to Notion's storage through the API with built-in rate-limit management and exponential backoff. Our migrations typically complete in days, not weeks, with zero downtime for either platform.

If your SharePoint environment is complex — multiple sites, large document libraries, interconnected lists — it's worth a 30-minute conversation to scope the work before investing engineering time in a DIY approach that may not cover your edge cases.

Migration Checklist: SharePoint to Notion

Use this as your pre-migration planning reference:

• Inventory SharePoint content — List all sites, subsites, lists, libraries, and their item counts
• Document column types — Map every SharePoint column to its target Notion property type
• Identify Lookup/Relation dependencies — Determine migration order (referenced lists first)
• Test CSV export on a small list — Verify which metadata survives and which doesn't
• Register a Microsoft Entra (Azure AD) app — Required for Graph API access with Sites.Read.All or Sites.Selected permissions
• Create a Notion integration — Generate an internal integration token and grant it access to your target pages
• Build the target database schema in Notion — Create databases with correct property types before loading data
• Run a pilot migration — Migrate one list end-to-end to validate mapping and identify issues
• Migrate reference data first — Populate databases that others relate to (Departments, Categories, Users)
• Migrate primary data — Load items with relations, files, and block content
• Validate — Spot-check item counts, property values, file attachments, and relation links
• Redirect and communicate — Update bookmarks, notify users, and archive the SharePoint source

What Happens to Your Data After the Move

Once data lands in Notion, a few things change permanently:

• Version history is gone. Notion tracks its own page history (7 days on Free, 30 on Plus, 90 on Business), but your SharePoint version history doesn't transfer. If compliance requires it, archive SharePoint versions before decommissioning.
• Permissions reset. SharePoint's granular permission model (site-level, list-level, item-level with inheritance) has no equivalent in Notion. You'll need to configure Notion permissions from scratch using teamspaces and page-level sharing.
• Search changes. SharePoint's search is powered by the Microsoft Search index, which crawls content types and managed properties. Notion's search is full-text across all accessible blocks. Users may find things faster in Notion — or slower, depending on how well your databases are structured.