---
title: "How to Migrate from Notion to a Help Centre"
canonical: https://supportpages.io/guides/migrate-from-notion-to-a-help-centre
updated: 2026-08-13
---

Your customer-facing Notion pages published as help centre articles, with readable URLs, working links and images that load - plus a deliberate decision about what stays in Notion for the team.

## Before you start

Work out who has export rights. Exporting a single page needs nothing unusual, but exporting an entire workspace in one pass is an admin action and on some plans a paid one. If you only need thirty pages, per-page exports sidestep the question.

Settle the audience question before you touch anything. A Notion workspace usually holds three kinds of page: things customers need, things the team needs, and things that were true in March. Only the first kind is migrating.

![A migration sequence: inventory, pick the canonical copy, move it, then redirect the original.](/images/guides/figures/migrate-from-notion-to-a-help-centre.webp)

*The redirect is the step teams skip, and the one that decides whether links survive.*

## Steps

1. **List the pages a customer would plausibly need.**
   Work from your support inbox rather than the sidebar. The pages people link in replies are the migration list; everything else is a separate decision you can make later.

2. **Export as Markdown, including subpages.**
   Look for **Export** in the page's overflow menu, or the workspace-wide export in settings. Choose the Markdown option rather than HTML or PDF - the HTML carries Notion's own markup, and the PDF carries nothing you can edit. Enable the option to include subpages so nested content comes across with its parent.

3. **Strip the page IDs from filenames and links.**
   Notion appends a long hexadecimal ID to every exported file and folder name, and the same ID appears inside the relative links in those files. Rename the files and rewrite the links in one pass, or you will fix the URLs and break every cross-reference.

4. **Repoint the images.**
   Exported images land in a folder beside the markdown file. Upload them wherever your help centre stores images and rewrite the `src` paths. Anything still pointing at a Notion-hosted URL will break the moment workspace access changes.

5. **Find the links that lead back to Notion.**
   Links to pages you did not export stay as full Notion URLs. To a logged-out reader those are either a 404 or a login screen, and both read as a broken help centre. Search the exported files for `notion.so` and `notion.site` and resolve every hit.

6. **Check what the export dropped.**
   Comments, page history, permissions, database views, synced blocks and anything rendering a live view of other content do not survive. Toggles, callouts and columns arrive flattened at best, so re-read any page that relied on layout to make sense.

7. **Rewrite each page for someone outside your workspace.**
   Remove @-mentions, internal team names, and sentences that assume the reader knows why a feature exists. This is the slowest step and the one that decides whether the migration was worth doing.

8. **Publish, then close the loop on the old URLs.**
   Update the links you control - support macros, in-app help, README files - and leave a pointer on the Notion original rather than deleting it outright.

## Common mistakes

**Exporting the whole workspace and sorting it out afterwards.** A full export of a busy workspace produces thousands of files, most of them meeting notes. Filtering after the export takes far longer than choosing before it.

**Keeping the page ID in the published URL.** A URL ending in a 32-character hex string is unshareable, unmemorable, and looks broken to anyone who reads it aloud. Set the slug from the title before publishing, not after search engines have indexed it.

**Treating a database as an article list.** Databases export as a CSV of properties plus a folder of individual pages. Neither half on its own is the article, and importing only the CSV produces a set of titles with no bodies.

**Publishing a page that names a customer.** Internal pages routinely contain account names, pricing exceptions and workarounds written for one client. Read every page you migrate, and read the screenshots inside them too.

**Leaving Notion as the place people write.** If the team keeps editing the Notion original afterwards, you now maintain two versions, and the public one is the one that falls behind.

## When this stops scaling

Exporting is a one-off and the effort is roughly linear, so this method holds for as long as you are willing to re-read every page. The point where it stops being sensible is not the page count; it is the moment the migration stops being a migration and turns into a habit.

That happens when several teams keep writing in Notion because it is where they think, and someone re-exports every month to keep the public documentation current. Past two or three writers on a weekly release cadence, a manual sync fails quietly: the export succeeds, the review does not happen, and the help centre sits a version behind the product.

The alternative is to stop treating documentation as content that has to be moved, and start treating it as something derived from the product itself. [SupportPages](https://supportpages.io) generates a help centre from your codebase, which is frequently less work than migrating pages that were already out of date in Notion. If most of what you are about to export needs rewriting anyway, that is worth weighing before you begin.