A comprehensive guide to migrating between Notion and SharePoint. Covers why native exports fail, how to map Notion's block architecture to SharePoint lists, API extraction strategies, and a complete guide to mapping permissions when moving from SharePoint to Notion.
There is no native migration path from Notion to SharePoint — no connector, no importer, no "Move to SharePoint" button. Notion stores content as a recursive tree of JSON blocks where every element is an individual block object. SharePoint stores content as modern pages with CanvasContent1 JSON, structured lists with typed columns, and document libraries. The two architectures are fundamentally incompatible at the data-model level, which means every migration requires an extraction layer, a transformation layer, and a loading strategy — all custom.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Notion workspace exports create deeply nested folder structures
On Windows, path lengths exceeding 260 characters will prevent the ZIP from extracting. Notion appends hexadecimal hashes to every file path, making this a common issue for large workspaces.
Take the native export anyway
It gives you rollback insurance, raw assets, and a defensible backup point before you start transforming data through the API.
Use Power Automate or Zapier for post-migration deltas and lightweight syncs
Use embeds when you intentionally want coexistence. Use a scripted API-to-API migration when the goal is to actually move the knowledge base.
SharePoint lists can hold up to 30 million items, but the List View Threshold kicks in at
SharePoint lists can hold up to 30 million items, but the List View Threshold kicks in at 5,000 items per view query. Index your most-filtered columns before importing data. You cannot create indexes on lists that already exceed 20,000 items without workarounds. (learn.microsoft.com)
Do not break inheritance on every single SharePoint list item to replicate Notion's
Do not break inheritance on every single SharePoint list item to replicate Notion's per-page permissions. This creates a performance and governance nightmare. Group content by audience into separate lists, libraries, or sites, and apply permissions at the container level.
A linked view is not a security boundary
If you share a filtered view without underlying database restrictions, users can click "Open as page" and remove the filter to see all records.
Never sign off on row counts alone
A migration can be numerically complete and still be broken if permissions, links, page layouts, or file downloads fail.
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Decide what content deserves to move before you plan how to move it.
Objective A content inventory with a keep/rewrite/retire decision on every article and an agreed URL strategy.
Keep these open
-
Inventory all content in Notion
Count articles, categories, attachments, images and embedded media, and pull page views and last-updated dates for each article. Usage data is what makes the next decision defensible rather than political.
Data Profiler Get real record counts instead of estimating from memory -
Make a keep, rewrite or retire call on every article
Most knowledge bases are half stale. Migrating everything imports the staleness and doubles the work; use views and last-updated to triage, and get the owning team to confirm. This usually removes 30-50% of scope.
Migrating stale content is the most common knowledge-base migration mistake — it costs effort and actively degrades the new site.
-
Agree the URL and redirect strategy
Decide the SharePoint URL structure and whether you can serve 301 redirects from the old paths. Public help centres carry real search traffic and inbound links; losing it is a measurable commercial impact.
Without 301 redirects from old article URLs you lose accumulated search ranking and every external link and bookmark breaks.
-
Map the information architecture
Document the current category tree and design the target one, checking whether SharePoint supports your nesting depth. Deeply nested hierarchies frequently have to be flattened, which changes navigation for everyone.
-
Confirm permissions, audiences and localisation scope
Establish which content is public, internal or restricted, and how SharePoint models that. Then confirm how many locales you have and whether translation relationships between articles survive the move.
Don't move on until
- Full content inventory with page views and last-updated dates
- Keep / rewrite / retire decision recorded per article
- URL and redirect strategy agreed with whoever owns SEO
02 Data Audit Audit the markup, the links and the assets — that is where KB migrations break.
Objective A content export with markup, internal links and every embedded asset accounted for.
Keep these open
-
Export content and assess markup fidelity
Export articles in the richest format available and inspect what survived: tables, code blocks, callouts, nested lists, anchors and embedded video. Rich formatting is where fidelity is lost, and it is lost quietly.
HTML-to-Markdown conversion routinely mangles nested lists, tables and code blocks. Inspect the output rather than trusting the converter.
Data Profiler Profile the Notion export for nulls, outliers and type drift -
Inventory every internal link and cross-reference
Extract all internal links, anchor links and article cross-references. These break by default: the target URL structure differs, so every internal link needs rewriting as part of the load, not afterwards.
Internal links left pointing at old URLs turn the new knowledge base into a maze of 404s on day one.
-
Inventory images, attachments and embedded media
List every asset with its URL, size and type, and confirm each still resolves. Assets hosted on the old platform's CDN will 404 the moment you decommission it, so they must be rehosted, not referenced.
Images referenced from the source platform's CDN break when the old account closes. Download and rehost every asset.
-
Find and fix broken links and orphans
Crawl for existing broken internal and external links, and find articles no category links to. Fix them before migrating — a migration is a bad time to discover pre-existing rot.
-
Check for PII and internal information in public content
Scan for customer names, internal hostnames, credentials in code samples and screenshots containing real data. Republishing these on a public help centre is a disclosure, and screenshots are the usual culprit.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Normalise metadata
Standardise authors, tags, timestamps to UTC, and locale codes. Author mapping needs a decision for people who have left — attribution to a deleted user usually fails the import.
-
Extract file URLs
via the Notion API (each File block returns a file.url and file.expiry_time).
-
Upload to a SharePoint Document Library
via Microsoft Graph API or the SharePoint REST API.
-
Update the reference
in the corresponding SharePoint page or list item to point to the new SharePoint-hosted URL.
Notion → SharePoint specifics
- Permission audit
- confirm the right groups have access to the right sites/lists
Don't move on until
- Content exported with markup fidelity assessed
- Every internal link and asset reference inventoried
- Broken links and missing assets fixed or logged
03 Field Mapping Map structure, metadata, permissions and — above all — URLs.
Objective A mapping covering article fields, taxonomy, permissions and a complete old-to-new URL map.
Keep these open
-
Map the article schema
Map title, body, excerpt, author, dates, status, tags, SEO metadata and any custom properties. Confirm which fields SharePoint lets you set on import versus which it computes — computed dates are a common surprise.
Schema Mapper Opens pre-loaded with the Notion → SharePoint field pair -
Map the taxonomy and hierarchy
Map categories, sections and tags to the target structure, resolving any nesting-depth limit explicitly. If you must flatten, decide how the lost level is preserved — usually as a tag or a title prefix.
JSON to CSV Converter Flatten nested API responses into a reviewable sheet -
Map permissions and audience segmentation
Map public, logged-in, and role-restricted visibility to SharePoint's model. Verify the mapping deliberately: internal content accidentally published publicly is the highest-severity failure in this whole category.
Permission mapping errors publish internal documentation to the open web. Verify visibility on every restricted article after load.
-
Build the complete old-to-new URL map
Produce a row per article mapping the old URL to the new one, then confirm exactly where the 301s will be served — SharePoint, a CDN, or your own web layer. Without this artifact the redirect step cannot be executed at all.
-
Define the markup conversion and link-rewrite rules
Specify how each markup construct converts and how internal links are rewritten using the URL map. Write it as a repeatable transform, not manual edits — you will run it more than once.
Data Format Converter Reshape the export into the format SharePoint's importer expects -
Plan localisation and freeze the spec
Confirm how translated articles link to their source language in SharePoint, then version and sign off the mapping spec.
Don't move on until
- Article schema and taxonomy mapped
- Permission and audience model mapped to target equivalents
- Complete URL map produced and redirect method confirmed
04 Test Migration Pilot the hardest articles, then read them.
Objective A pilot load whose formatting, links, assets and search all hold up under human review.
Keep these open
-
Configure SharePoint with the agreed structure
Create the category tree, permission groups, locales and branding before loading. Articles loaded before their categories exist land uncategorised and have to be moved by hand.
-
Pick the most difficult articles as the pilot
Choose 20-50 articles for difficulty: the longest, the most heavily formatted, ones with tables and code blocks, deep internal linking, many images, embedded video, restricted visibility, and non-Latin scripts. Easy articles prove nothing.
-
Run the conversion and load with link rewriting
Apply the markup conversion, rewrite internal links from the URL map, upload and re-reference assets, then load. Log every conversion warning rather than suppressing it.
-
Read every pilot article side by side
Open source and target together and compare rendering. This step is manual on purpose: no automated check catches a table that collapsed into a paragraph or a code block that lost its indentation.
-
Click every link and load every asset
Verify each internal link resolves, each image loads from the new host, each attachment downloads and each embed plays. Assets still served from the old CDN are the defect that surfaces only after decommissioning.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Test search and permissions
Search for known terms and confirm the right articles rank, then verify every restricted pilot article is invisible to an anonymous browser. Test permissions from a logged-out session, not an admin one.
Don't move on until
- Complex articles render correctly with formatting intact
- Every internal link and asset in the pilot resolves
- Search returns sensible results for the pilot content
05 Cutover Publish, redirect, and keep the search traffic.
Objective All in-scope content live in SharePoint with redirects serving and search engines informed.
Keep these open
-
Load the full content set ahead of the switch
Run the full conversion and load into SharePoint, unpublished or on a staging domain. Content migration differs from data migration here: you can stage the whole thing before anyone sees it.
-
Publish the runbook with the redirect step first-class
Sequence the freeze, final delta, publish, redirect activation, sitemap submission and link updates, with owners for each. Redirect activation is the step with lasting commercial consequences, so it gets explicit ownership.
-
Freeze editing and migrate the delta
Stop editing in Notion, then convert and load anything changed since the full load. Announce the freeze to every team that publishes — content teams are used to editing whenever they like.
-
Publish and verify permissions live
Publish the content set, then immediately verify restricted articles are not publicly reachable using an anonymous session. Do this before announcing the new site, not after.
Verify restricted content from a logged-out browser. An admin session will show you everything and tell you nothing.
Migration Validation Tool Confirm the final delta landed before you reopen -
Activate 301 redirects and submit the sitemap
Turn on the redirects from the URL map, then spot-check a sample of high-traffic old URLs and confirm each returns 301 to the right article. Submit the new sitemap and keep the old one reachable until search engines have recrawled.
Redirect chains and redirect loops both leak ranking. Verify each redirect resolves in a single hop.
-
Repoint in-product and support links
Update help links embedded in your product, in support macros, in email templates and in onboarding material. These are the links your existing customers actually use, and they are easy to forget.
Don't move on until
- All content loaded, categorised and correctly permissioned
- 301 redirects live and verified from a sample of old URLs
- Sitemap submitted and support links repointed
06 Validation Watch traffic, links and search rankings for weeks, not hours.
Objective Verified content completeness, healthy redirects, and search traffic recovered to baseline.
Keep these open
-
Reconcile content counts and assets
Compare article counts by category and status, plus asset counts, against source. Confirm every article in the keep list is present and every retired one genuinely is not.
Migration Validation Tool Reconcile Notion and SharePoint record-for-record -
Crawl the new site for broken links and assets
Run a full crawl for 404s, broken images and missing attachments, and fix everything it finds. Repeat the crawl after the fixes rather than assuming they worked.
-
Verify the redirects at scale
Test every mapped old URL for a single-hop 301 to the right destination. Chains and loops both leak ranking and are invisible unless you check the whole map, not a sample.
-
Monitor organic traffic and rankings for four to eight weeks
Track organic sessions, impressions and rankings for your top articles against baseline. A dip in the first two weeks is normal; one that has not recovered by week six is a redirect or indexing problem to investigate.
Do not decommission the old platform until search traffic has recovered — you may still need the old URLs to diagnose a ranking loss.
-
Verify search, permissions and feedback loops
Confirm on-site search returns good results for real queries, re-verify restricted content from a logged-out session, and check article feedback and analytics are collecting.
-
Sign off and decommission on a delay
Get acceptance against the Discovery criteria, keep Notion available read-only until traffic has recovered, take a final export, and only then close the account.
Notion → SharePoint specifics
- Page count match
- same number of pages in SharePoint as source Notion pages
- File integrity
- spot-check file sizes and content hashes
- Relation integrity
- verify Lookup columns resolve to the correct target items
- Search indexing
- ensure SharePoint Search has crawled the new content
Don't move on until
- Article counts reconciled and no broken links remain
- Redirects returning 301 with no chains or loops
- Organic traffic recovered to within tolerance of baseline
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
Property Type Column Type
| Notion field | SharePoint field | Notes |
|---|---|---|
| Title | Single line of text (Title column) | Direct mapping |
| Text | Single/Multiple lines of text | Multi-line loses rich formatting |
| Number | Number | Direct mapping |
| Select / Status | Choice | Map option values 1:1 |
| Multi-select | Choice (allow multiple) or Managed Metadata | Managed Metadata is better for enterprise governance |
| Date | Date/Time | Notion uses ISO 8601; SharePoint accepts it |
| Person | Person or Group | Requires identity mapping (Notion email → Entra ID). If a user has left the company, the import fails unless you map them to a generic account |
| Checkbox | Yes/No | Direct mapping |
| URL | Hyperlink | Direct mapping |
| Email / Phone | Single line of text | No native email or phone column type in SharePoint |
| Relation | Lookup column | Requires the related list to exist first; limited to 12 lookup-type columns per view |
| Rollup | Calculated column (limited) | Cannot cross-reference other lists |
| Formula | Calculated column | Must be manually recreated; Notion formula syntax ≠ SharePoint formula syntax |
| Files & Media | Document Library link or Attachment | Files must be downloaded from Notion and re-uploaded. Libraries allow up to 250 GB per file; list attachments cap at 250 MB (learn.microsoft.com) |
| Created time | Created (built-in) | Only preserved if scripted via API; native export drops it |
| Created by | Created By (built-in) | Same — requires API-level metadata injection |
SharePoint Notion permissions mapping
| Notion field | SharePoint field | Notes |
|---|---|---|
| Site Collection / Hub | Teamspace | The highest level of grouping. Teamspaces can be open, closed, or private. |
| SharePoint Group | Notion Group | Map your Entra ID (Azure AD) groups to Notion Groups. |
| Library Permissions | Database Permissions | Applied at the top-level database. |
| Item-Level Permissions | Page-Level Access | Notion's granular database permissions (introduced in 2025) allow property-based access rules. |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Relations | high | Break on export — SharePoint Lookup columns limited to 12 per view |
| Rollups | high | No cross-list equivalent in SharePoint — must flatten or automate externally |
| Formulas | high | Notion formula syntax is incompatible with SharePoint calculated columns |
| Internal Links | high | All notion.so URLs break — require mapping table and full rewrite pass |
| File Attachments | high | Notion CDN URLs expire within ~1 hour — must download and re-upload |
| Permissions | medium | Page-centric model must be redesigned for inheritance-based SharePoint model |
| Created By / Created Date | medium | Native export strips authorship — requires API-level metadata injection |
| Board & Timeline Views | medium | Flatten to standard tables — visual layout is permanently lost |
| Nested Page Hierarchy | medium | Notion's infinite nesting does not map to SharePoint's flat page model |
| Simple Text Content | low | Maps to Text Web Part HTML with standard sanitization |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Block Transformation
Every Notion block must be converted to SharePoint web parts, list items, or document library entries. Only 14 web parts are supported via the API.
Relation Mapping
Notion relations must be mapped to SharePoint Lookup columns, which are limited to 12 lookup-type columns per view.
Permission Remapping
Notion's page-centric sharing model must be redesigned for SharePoint's inheritance-based permission architecture.
File Re-hosting
Notion CDN file URLs expire within roughly one hour. Every embedded file must be downloaded and re-uploaded to Document Libraries.
Rollup Translation
SharePoint has no native cross-list aggregation. Rollups must be flattened to static values or automated via Power Automate.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
Can you migrate Notion databases to SharePoint lists?
Yes, but not with a native export. Notion relations lose their programmatic links in CSV, rollups disappear, and formulas don't transfer. You need to map each Notion property to a SharePoint column type (e.g., Select → Choice, Relation → Lookup) and use the Notion API plus Microsoft Graph API to transfer data with structure intact. SharePoint views are limited to 12 lookup-type columns, so audit your relations first.
Does Notion have a SharePoint migration tool?
No. There is no native Notion-to-SharePoint migration tool from either vendor. The available approaches are: manual export (CSV/HTML) and rebuild, Zapier/Power Automate for small ongoing syncs, embedding Notion pages in SharePoint as a temporary bridge, or custom API-to-API scripting for full-fidelity migration.
What data is lost when exporting from Notion?
Native Notion exports lose: relational links between databases, rollup and formula logic, Created By and Created Date metadata, board and timeline view layouts, live embeds, and synced block references. Large workspace exports may also take up to 30 hours or fail entirely, and may exclude private pages the exporter cannot access.
Can Zapier or Power Automate handle a full Notion workspace migration?
Not effectively. The Power Automate Notion connector has a 100-calls-per-60-seconds throttle, and Zapier cannot retrieve file attachments, formula values, or relation properties from Notion. On the SharePoint side, Zapier cannot write to Person/Group or Managed Metadata columns. Both are useful for small ongoing syncs, not bulk historical migration.
How do you map Notion permissions to SharePoint?
Map Notion workspace members to SharePoint site member groups and Notion teamspaces to separate SharePoint sites. SharePoint supports up to 50,000 unique security scopes per list, but Microsoft recommends staying under 5,000. Avoid breaking inheritance on every individual item — restructure content by audience into separate containers and apply permissions at the site, library, or folder level.