Migrate from Notion to Docmost

How to migrate from Notion to Docmost without losing the wiki

Docmost can take a Notion workspace export as Markdown or HTML, and the wiki pages carry over into it, but Notion databases need separate handling and should be planned as their own workstream. The usual trigger is a renewal, a data residency requirement or a lock-in concern, and the work is typically done by internal admins, with an implementation partner brought in for the parts that need specialist judgment, such as permissions mapping, identity integration and cutover. The hard part is rarely the page text. It is the structure around it: nested subpages, internal links, embedded files and who can see what.

Start by exporting a test subset rather than the whole workspace. Notion's help center notes that a full workspace export can take up to 30 hours, so a pilot export of one team's space lets you check how Docmost's import dialog handles headings, tables, images and links before you commit to a full run. Docmost's import dialog accepts Markdown, HTML, Word, Notion and Confluence exports, and the Docmost import and export documentation describes the supported formats. Confirm with Docmost's current documentation which import paths are available in your edition, because its documentation lists the Confluence, DOCX and PDF importers as paid-edition features.

Plan the cutover with a clear view of what will not come across cleanly. Attachments, embedded media and internal page links should be checked page by page on the pilot, and any page that depends on Notion-only blocks should be rebuilt by hand. Confirm with your Notion plan whether your admins can export at all, since Enterprise workspaces can disable exports in security settings. Before the final export, decide who signs off on the migrated content, how the Notion workspace will be kept read-only for a defined period, and how you will confirm permissions in Docmost match the intended access model. Budget effort for review and rework, not just the import run.

What Notion features map to Docmost, and what needs rework

This table compares the Notion features most teams rely on with Docmost's spaces, pages, import and permissions. Each row is marked clean, needs rework or gap, so you can see where a Notion ZIP import will carry content directly and where you will need manual steps. Confirm current Docmost coverage in your own test import before you commit to a cutover plan.

Notion feature	Docmost equivalent	Migration status
Pages and rich text	Docmost pages, exported as Markdown or HTML	Clean: headings, lists and basic formatting usually convert. Verify tables, toggles and callouts in a test import.
Nested subpages	Page hierarchy within a Docmost space	Needs rework: Confirm the parent and child structure survives the ZIP. Relink or flatten pages that do not.
Attachments and images	Files and images uploaded to Docmost pages	Needs rework: Check that exported files are imported and still linked. Re-upload any that are missing.
Databases	No direct equivalent to Notion database views, relations or rollups	Needs rework: Export database CSV files separately. Rebuild them as tables or move trackers to a dedicated tool.
Permissions and teamspaces	Docmost spaces with groups and member roles	Needs rework: Map Notion page and workspace access to spaces and groups. Confirm roles after import.
Comments and discussions	Page comments in Docmost	Gap: Confirm whether comments and threads appear in the import. If not, archive them before cutover.
Notion AI features	No confirmed equivalent in Docmost	Gap: AI summaries and Q&A do not carry over. Check Docmost's current feature set before you plan around it.
Export and volume	Docmost import accepts Notion exports	Needs rework: Notion says a full workspace export can take up to 30 hours. Run a test export on a sample first.

What moves cleanly from a Notion export into Docmost

The export ZIP is the working unit for this migration. Notion exports pages and databases as PDF, HTML or Markdown and CSV, and Docmost's import dialog accepts Markdown, HTML, Word, Notion and Confluence exports. For a Notion path, the practical choice is to export the workspace as Markdown or HTML, then import that ZIP into Docmost and check the result before anyone is asked to rely on it. Docmost's own pages export as Markdown or HTML, so the format you pick here also shapes how easily content can leave Docmost later. Confirm in the Docmost version you run which Notion import options appear in the dialog, because the import screen is the authority for what your edition accepts.

Once the import finishes, check page hierarchy and attachments before you move users in. Compare a sample of parent pages and their nested children against the Notion sidebar, since nesting is the part most likely to flatten or shift during conversion. Open pages with images, files and embedded media and confirm each attachment opens and points to the right page. Notion's own export behaves differently depending on options: its Include subpages option for PDF export is limited to Business and Enterprise plans, so a team on a lower plan may not be able to produce a single PDF that carries child pages. Plan level therefore affects how you package the source material, not only what you pay. Record which plan the export was taken from so the migration log is accurate.

The Docmost import options named in its documentation are the Confluence, DOCX and PDF importers, and the documentation lists them as paid-edition features. The Notion import path is not on that list, but that does not confirm it is available in every edition, so test it on the exact edition you plan to run. Ask your Docmost licensing contact or check the current documentation for which features your edition includes. Run a pilot import of a representative space, including deep nesting, databases and large attachments, and keep the results as evidence for the rollout decision. Notion databases are not covered by this page's path and need separate handling, as described in the sibling topic on Notion databases.

Which data and integrations need manual rebuilding

A Notion export moves page text and files, but several parts of a workspace need separate handling in Docmost. The cards below cover what the export carries, what it flattens, and what your team must rebuild or verify by hand before cutover.

Page content and hierarchy

Notion's Markdown and HTML exports keep page text, headings and nesting of subpages, but the tree is only as reliable as the folder structure in the ZIP. Docmost's import dialog accepts Markdown and HTML, so start there rather than converting PDF. Check that parent-child relationships landed under the right spaces, that internal links between pages still resolve, and that toggles, callouts and synced blocks rendered as readable content. Rebuild the navigation tree by hand if links break.

Attachments and embedded files

Uploaded files and images are packaged alongside pages in the export, but embedded content such as Google Docs, Figma frames or videos often stays a link to an external service. Verify every image renders, every file opens, and every embed that pointed to a Notion-hosted resource still has a valid target. Notion's own help text describes the export as a bundle of files, so expect to reattach anything that was referenced by a hosted URL rather than stored in the workspace.

Notion databases exported as CSV

Databases leave Notion as CSV files, which Notion exports as separate files from the page tree. CSV keeps rows and column values but drops relations, rollups, formulas, views, filters and sort orders. Docmost's import does not rebuild those structures, so each tracker or table needs a decision: keep it as a static table page, or move it to a dedicated tool. Plan this as its own workstream with a named owner, because the export carries data but not the logic that made the database useful.

User identities and page permissions

Notion's export does not carry workspace membership, guest access or page-level sharing into Docmost. Map each Notion member to a Docmost account, decide which spaces they join, and recreate space and page permissions by hand. Confirm who may edit, who may only view, and which pages were restricted in Notion before import. Do not assume the import reproduces access rules, since an imported page left open to the wrong group is a data exposure risk.

Integrations and embeds pointing at Notion

Automations, Slack or Zapier hooks, and links from other tools that target Notion URLs will break once the workspace is retired. Inventory every external reference to a Notion page or database, including bookmarks in browsers, runbooks and onboarding documents. Repoint each one to its new Docmost address, and keep Notion read-only for a defined period so links can be checked. Confirm the export time before scheduling cutover, since Notion says a full workspace export can take up to 30 hours.

The migration sequence from inventory to decommission

This sequence moves a Notion workspace into Docmost in controlled stages, so each space is proven on a pilot before the full set moves, and Notion access is removed only after the team has confirmed nothing still depends on it. Each step ends with a written output that the next step relies on.

Inventory spaces, pages and owners
Start by listing every teamspace, top-level page and database in the workspace, and record who owns each one, who edits it and who only reads it. Link each item to a business function, such as HR policies or engineering runbooks, so the team can see which content is live and which is stale. Note pages that rely on linked databases, embedded files, synced blocks or external integrations, because these need separate handling later. The output is a written inventory with an owner and a keep, archive or retire decision for every item. The step is done when the page owners have each confirmed their list in writing.
Export a pilot space and map its structure
Pick one representative space that includes ordinary pages, nested subpages, images, attachments and at least one database, then export it from Notion as Markdown or HTML using a workspace owner account. Import the ZIP into a test Docmost instance and compare the result against the source page by page. Check headings, tables, links between pages, image references, file attachments and permissions, and record which pages arrived complete and which did not. The output is a pilot defect log that lists each problem, its cause and the fix or workaround. The step is done when the pilot space has been reviewed by one of its owners and every defect has a disposition.
Decide how databases and special content are handled
Notion databases do not carry over as Docmost pages in the same form, so decide for each database whether it becomes a list in a page, a CSV kept as an attachment, or a separate tool such as a tracker. Review the pilot defect log to confirm which content types need manual rebuilding, and assign an owner to each one. Record any content that cannot be exported, such as pages a user cannot access, and agree with the page owner whether it moves, is rewritten or is retired. The output is a signed-off page map that lists each source page, its Docmost destination, its format and the person accountable for it. The step is done when the page map has been approved by the owners and the security or compliance lead.
Run the full import and archive the export
Export every approved space from Notion, record the export date, file size and the export owner, then import the ZIP files into a staging Docmost instance. Verify a sample of pages in each space against the signed-off page map, and correct any page where the import differs from the source. Store the original Notion export in a restricted, versioned location with a checksum, because it is the record of what was migrated. The output is a verified staging workspace and an archived export with its checksum and manifest. The step is done when the staging counts and sample checks match the page map and the archive is confirmed as readable.
Run a parallel period with clear write rules
Before cutover, tell users which wiki is the system of record for each space, and either freeze Notion edits for migrated spaces or require that edits made in Notion are repeated in Docmost. Track any questions, broken links and missing content in a shared log, and fix them in Docmost. Confirm that search, permissions and links behave as the owners expect, and that team members can find the pages they need without help. The output is a parallel-run issue log with every item closed or accepted. The step is done when the page owners agree that no content is missing and that the open items do not block daily use.
Cut over and redirect users
Set a cutover date with the page owners, make the final incremental changes in Notion, then repeat the export and import for any content that changed since the staging run. Update internal links, onboarding material and team bookmarks to point to Docmost, and state in the company wiki index where each space now lives. Confirm that Docmost accounts, group access and space permissions match the approved access model. The output is a cutover record that lists the final export, the final import and the links updated. The step is done when a spot check of each space in production matches the page map and the owners have signed off.
Decommission Notion access
Once the cutover record is signed off, remove members from the Notion workspace or restrict them to read-only access, disable new sharing and public links for migrated content, and confirm the workspace owner has an archived copy of the final export. Review any integrations, automations or connected tools that used Notion as a source and redirect them or retire them. Keep the archived export and its manifest for the period your records policy requires, and confirm the retention rule with your compliance lead. The output is a decommission record that lists the access changes, the integrations retired and the location of the archive. The step is done when no active editing paths to Notion remain and the record has been filed with the owners.

Why Notion databases need their own migration track

Notion databases should be inventoried and rebuilt in a table tool, not forced into wiki pages. Notion exports databases as CSV, and that file carries row data but not the rest of what makes a database work: relations between tables, rollups, formula logic, linked views, filters and the permissions attached to each view. A CSV export of a project tracker therefore gives you the rows and column values, while the behavior that made the tracker useful has to be recreated by hand. Pushing these databases into Docmost pages as flat tables usually loses that behavior without anyone noticing until a team member goes looking for a rollup that no longer exists.

Before you choose a destination, list every database in the workspace and record who uses it, how often, which views people open, and which other databases it links to. Some databases are reference lists that a wiki page can hold well. Others are operational trackers that need relations and filtered views. For the second group, check the options in the sibling topic on Notion databases: Docmost Bases, which is part of its paid edition, and Grist or Baserow for relational tables and views are the candidates to evaluate. Confirm with each vendor which features the edition you plan to run actually includes, and test a representative database before committing to one tool for all of them.

Plan the database track as a separate workstream with its own owner and acceptance test. Export each database as CSV, load it into the chosen table tool, and rebuild the relations and views against a checklist drawn from the original Notion layout. Keep the Notion export of the wiki pages and the database CSVs side by side so that links in documents can be repointed to the rebuilt tables. Ask the owner of each database to sign off that the rebuilt version answers the questions the team asked of the original, because row counts matching does not show that the logic carried over.

What drives the cost and duration of this migration

This table lists the factors that change how long a Notion to Docmost move takes and what it costs in staff time and hosting. Read each row as a lever: the driver, why it matters, and how to keep it under control. The main takeaway is that the Notion export itself can take up to 30 hours according to Notion, so the export window should be planned first and the review work sized against it.

Driver	Why it changes cost or effort	How to keep it down
Page count	Every page is converted, reviewed and often re-linked, so review time grows with volume and with cross-page links.	Archive stale pages before export, and migrate only the spaces people still use.
Attachment volume	Large or numerous files lengthen the export, increase storage needs and make broken references more likely.	Inventory attachments by size, confirm with a test import which types carry over, and host large files in a planned location.
Number of databases	Notion databases do not map directly to Docmost pages, so each one needs a separate decision and rebuild.	Export databases as CSV, list the ones that must stay structured, and decide early whether they stay in Docmost or move elsewhere.
Permission complexity	Notion teamspace and page-level sharing must be recreated as Docmost spaces and groups, which takes admin decisions and checks.	Simplify sharing rules before migration and map each Notion teamspace to one Docmost space where possible.
Reviewers who verify content	Someone must confirm that tables, embeds, toggles and formatting survived conversion, and reviewer hours usually exceed import hours.	Name a small set of reviewers per space, sample high-value pages first, and agree acceptance criteria in writing.
Hosting and admin time	Self-hosting adds infrastructure, backup, upgrade and access setup work that a hosted tool handles for the customer.	Confirm the target environment, backup approach and upgrade schedule before the import, and ask for these items in any written scope.
Paid Docmost edition features	Docmost documents its Confluence, DOCX and PDF importers as paid-edition features, so their use depends on the edition chosen.	Confirm which importers the Notion workflow requires, and check with Docmost whether the import path needed is in the community edition.
Notion export access	Notion says a workspace export can take up to 30 hours, and Enterprise workspaces can disable exports in security settings.	Ask a workspace owner to confirm export rights and schedule the export in a quiet window with time for a re-run if it fails.

What usually goes wrong and how to prevent it

Most Notion-to-Docmost problems come from the export format, not the destination. The cards below cover the failure points that show up after import, and each one names a check to run before people depend on the new wiki.

Links that break after import

Internal links in Notion point to page IDs and workspace URLs, and those references do not always resolve once pages are re-imported under new paths. Before cutover, sample pages that link heavily to other pages, subpages and databases, and confirm that each link opens the right destination in Docmost. Keep a redirect or mapping list from old Notion titles to new Docmost paths so you can repair links in bulk.

Attachments that do not follow pages

Notion exports can separate embedded files, images and PDFs from the page files that reference them, so a page can import with its text but with missing or broken media. Check the export folder for the attachments each page expects before importing, and compare a set of pages with images and files against what Docmost shows. Plan a second pass for any file that does not come through.

Databases flattened into unusable pages

Notion databases export as CSV or as pages with property values as text, which loses relations, rollups, formulas, filters and linked views. Teams often find trackers become long, unsorted tables that no one maintains. Decide before migration which databases stay as Docmost pages, which move to a dedicated tool, and which need to be rebuilt by hand, and list the properties each one must keep.

Permissions that are not recreated

Notion sharing settings, teamspace membership and guest access do not carry over as Docmost spaces and groups by default. Pages can become visible to everyone who has the workspace, or private to the person who ran the import. Map each Notion teamspace to a Docmost space, assign group roles before users log in, and test access with a non-admin account for restricted content.

Users editing in both systems

During a parallel run, people who keep editing in Notion create content that never reaches Docmost, and the two copies diverge quickly. Set a freeze date for each space, announce it with the export timeline, and make Notion read-only for migrated content once the final export is taken. Confirm that Notion's export link and any sharing you rely on have not expired before the freeze begins.

How the work changes by workspace size and starting point

A small team with a handful of spaces usually has a workspace that a single owner can export and review in one sitting. The main risk is not volume but drift: pages edited during the move, informal links that break after import, and people who keep writing in Notion after Docmost is live. Because the page count is modest, the most practical approach is to export by teamspace or top-level page, import into a test Docmost instance, and read a sample of pages side by side with the originals.

Export scope: Export the pages you need as Markdown or HTML, which keeps the work manageable for a short list of spaces.
Freeze point: Agree a cutover date after which Notion is read-only for these pages, so nothing is written in two places.
Link checks: Review internal links and embedded images by hand, since a small team can do this quickly and it is where small imports usually break.
Owner sign-off: Assign one person per space to confirm the imported content matches the original.
Database pages: Identify any Notion databases early, because they need a separate plan regardless of team size.

Before you start, confirm which of your pages are databases and which plan your Notion workspace is on, since that affects which export options you can use.

Questions buyers ask before migrating from Notion to Docmost

How long does a Notion export take for a full workspace?

Notion says a full workspace export can take up to 30 hours, so start it early and do not plan a cutover on the same day. The duration depends on how much content the workspace holds, how many attachments it contains and how many pages a single export job covers. Workspace owners start the export from the workspace settings, and Notion sends a download link that expires after a limited period, so the team should download and store the ZIP promptly. Ask the workspace owner to confirm the current export options for your plan, because Notion's help center describes some export features as tied to specific plan levels and, on Enterprise workspaces, admins may have disabled exports in security settings. Read the Notion export guide before scheduling the work.

Do attachments and page history carry over from Notion to Docmost?

Page content and embedded files usually need checking after import, and page version history from Notion should not be assumed to carry over. A Notion export packages pages as Markdown or HTML with their attachments, but the exact handling of images, file links and embedded media varies by content type. Docmost's import dialog accepts Markdown, HTML and Notion exports, and it lists some importers as paid-edition features, so confirm which import paths your edition includes. Run a sample import of representative pages with images, files and nested subpages, then compare the results against the originals before committing to the full workspace.

Can Notion databases move into Docmost as they are?

No, Notion databases should be handled as a separate workstream rather than expected to import as working tables. Notion exports databases as CSV, which keeps rows and columns but not views, formulas, rollups, relations or linked views in a form Docmost can rebuild automatically. Plan to inventory each database, decide which ones belong in the wiki as reference tables and which should move to a dedicated tracker, and rebuild the required relations and views by hand. This is the main source of rework in most Notion migrations, so size it on its own line item in any quote.

Can our own team run this migration without an outside partner?

Yes, a team with one or two administrators and a clear content owner can run a small workspace migration in-house, provided they have time for export, sample testing and page cleanup. The work becomes harder when the workspace is large, has many databases, relies on permissions copied across many teams, or must be validated for an audit. Teams with a fixed deadline often bring in an implementation partner to plan the scope in writing, run the import and rehearsal, and document the result. DeployOpen plans, implements and documents self-hosted platforms inside the client's own infrastructure, typically under a fixed-scope agreement with written deliverables and timelines.

What do our admins and content owners need to provide?

Admins need a Notion workspace owner who can run the export, a Docmost instance in the organization's own infrastructure with an administrator account, and a decision on the target space structure and permissions. Content owners need to review their areas after import, mark outdated pages for archive, and confirm links, images and databases. Security or compliance staff should confirm where the export ZIP is stored during the move, who can access it and when it is deleted, since the export contains the full workspace content. Ask the vendor or your own team to confirm the current Docmost edition features and any Enterprise options before the plan is final.

How should we choose between Docmost and XWiki?

Choose Docmost when the priority is a fast, familiar workspace with spaces, real-time editing and an import path from Notion, and choose XWiki when the knowledge base needs deeper structure, such as typed data, application-style content or a larger extension ecosystem. Docmost is licensed AGPL-3.0, and XWiki is licensed LGPL-2.1, so confirm the license terms with your legal team for your intended use. XWiki's Notion path is typically heavier because it works from HTML or Markdown exports and needs more modeling work. Run both options against the same sample of pages and databases, and compare the rework each one requires before deciding.

Confirming Docmost's license and edition fit before cutover

Before any Notion export is run, confirm that Docmost's licensing and edition fit the way your organization intends to run it. Docmost is licensed AGPL-3.0, which governs the copy of the software you run and modify, and the AGPL obligations for network-accessed modifications should be reviewed by your legal team before you deploy a changed build. The import dialog accepts Markdown, HTML, Word, Notion and Confluence exports, but Docmost's import and export documentation lists the Confluence, DOCX and PDF importers as paid-edition features. That means a Notion migration through the standard importer is not the same decision as a Confluence or Word one, and you should not assume the paid importers are available in the build you pull from the public repository.

Confirm the current release before you write the pilot plan. The most recent version we have verified is v0.96.0, published on September 8, 2026, but release cadence means your pilot may run on a later tag. Check the Docmost GitHub repository for the tag you intend to deploy, read its release notes for importer changes, and record the exact version in your change record so that exported Notion files, import results and the admin runbook all refer to the same build. Ask the vendor or check the repository to confirm which edition each importer belongs to on that tag, because edition boundaries can move between releases.

Write down the features you need before the pilot starts, and map each one to an edition. Typical items include the Notion importer, page permissions and spaces, SSO requirements, audit or administrative controls, and any attachment handling that matters to you. For each item, record whether it is in the AGPL core or in the paid edition, who will support it, and whether a paid edition would add a recurring license cost. If a required feature sits behind a paid edition, that cost belongs in the total cost comparison before you commit to cutover, not after the first import has been run.

How DeployOpen scopes and runs a Notion to Docmost migration

DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, so a Notion to Docmost move runs in your cloud account or data center. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory which Notion workspaces, teamspaces, pages and attachments are in the migration and which are excluded.
Agree in writing how Notion databases are handled, either as Docmost pages or as a separate data structure.
Confirm who owns Notion export access, since Enterprise workspaces can disable exports in security settings.

How we build

Stand up the Docmost instance in your environment, with its database, storage and access settings configured to your policies.
Run test imports from a sample Notion export and review how headings, links, images and attachments render.
Document the export, import and cleanup steps so your team can repeat or audit the migration.

How we hand over

Deliver a written migration record listing what moved, what was rebuilt by hand and what was left behind.
Provide admin documentation for spaces, permissions, backups and upgrades in your own environment.
Walk your administrators through the cutover checklist and the read-only period for the old Notion workspace.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work ends.
Plan Docmost version upgrades and backups as recurring operations that your team or our retainer covers.
Confirm with your team which Docmost edition features you need before deciding whether paid importers are in scope.