Migrate from Notion to XWiki

Migrate from Notion to XWiki: what the move involves

Notion pages move into XWiki through Notion's HTML or Markdown export, followed by manual cleanup, while Notion databases have to be rebuilt as XWiki structured data. Notion exports pages and databases as PDF, HTML or Markdown and CSV, and a workspace owner can export everything, a job Notion says can take up to 30 hours. Expect to review each imported page for broken links, lost formatting, embedded blocks and attachments that did not come across cleanly. Plan the cleanup as a real work item, not a footnote, because the export gives you the content but not the structure XWiki needs to behave like a permissioned knowledge base.

The work usually falls to an internal platform or IT team, often with an implementation partner for the database modelling and permission design. The effort and risk depend mainly on two things: how many Notion databases the workspace holds and how permissions are set up in Notion today. Each database needs a decision about which XWiki application or class models its fields, how relations between records are represented, and how views are reproduced. Permissions are the second driver. Confirm which Notion spaces, teams and page-level restrictions must map to XWiki groups, rights and space levels before anyone imports content, because retrofitting access rules after a bulk load is where errors reach users.

XWiki Standard is free and open source under the LGPL-2.1, so the platform itself carries no licence fee. Paid options exist and are worth pricing separately: XWiki Pro adds business applications and connectors, support subscriptions cover on-premises help, and consulting and training are sold per day. Ask XWiki SAS or your implementation partner for a written scope that lists each database, each permission model and each extension you need, since that scope, not the platform licence, will determine most of the cost.

Which Notion features map to XWiki, and which need rework

This table maps Notion's main features to their closest XWiki equivalents and marks each as clean, needs rework or gap. Read the rows as a planning checklist: a clean match still needs a test import, while rework and gap rows set the rebuild effort. Confirm each feature against the XWiki version you plan to run before you commit.

Notion feature	XWiki equivalent	Status	Notes for the migration
Pages and page content	Wiki pages with the XWiki syntax editor and rich text editing	Needs rework	Text, headings, lists and tables convert, but block-level formatting and colored callouts need manual cleanup.
Subpages and page hierarchy	Nested pages under a parent page or space	Clean	Hierarchy usually carries over from the export folder structure. Check that page names remain unique within each space.
Databases	Structured data using XClass objects, shown through live tables	Needs rework	Each database becomes a class with typed properties. Relations and rollups must be rebuilt as links and queries.
Database views (table, board, gallery)	Live table macros and custom application views	Gap	Board and gallery views have no direct equivalent in core XWiki. Plan custom views or a paid application from XWiki Pro.
Permissions and sharing	Rights on spaces and pages, with groups	Needs rework	Notion's page-level sharing must be remapped to XWiki groups and rights. Confirm which group model your identity source provides.
Comments and discussions	Page comments and discussion features	Needs rework	Inline comments on blocks do not move as threads. Export the thread text and attach it to the page or archive it.
Attachments and files	Page attachments stored in the XWiki database	Clean	Files referenced from exported pages can be uploaded and relinked. Large files need storage sizing before import.
Search and workspace structure	Full-text search, spaces and the wiki home page	Needs rework	Search covers the rebuilt content. Notion teamspaces must be recreated as spaces, and link targets updated after import.
Synced blocks and templates	Includes, transclusion macros and page templates	Gap	Notion synced blocks have no automatic equivalent. Rebuild each one as a shared include and test every page that uses it.

What data can be exported from Notion and what must be rebuilt

Notion gives you several export paths, but each one carries different content, and some depend on plan level or admin settings. The cards below cover what you can pull out, what the export tends to leave behind, and what your team must recreate by hand in XWiki.

Page and database export formats

Notion exports pages and databases as PDF, HTML or Markdown, and databases as CSV. For a wiki move, Markdown or HTML carries page text and structure best, while CSV is the only practical route for database rows. Plan to map each database to an XWiki structured application, since CSV holds values but not views, relations or formulas.

Workspace-wide export timing

A full workspace export can take up to 30 hours, according to Notion. Start it early, run it when the owner can watch for completion, and download the archive promptly, since the download link is time-limited. Verify that the archive opens and that page counts match your inventory before you decommission anything.

Subpage inclusion in PDF exports

The Include subpages option for PDF export is limited to Business and Enterprise plans. If your workspace is on a lower plan, subpages will not come out in a single PDF, so you will need page-by-page exports. This matters less for XWiki, which imports from HTML or Markdown, but it affects any archival PDF copies you keep.

Export permissions set by admins

On Enterprise workspaces, admins can disable exports in security settings. Confirm with the workspace owner before the project starts that exports are enabled for the account doing the migration. Agree on who runs the export, who holds the archive, and how it is stored, because the archive contains the full content of the workspace.

Users, groups and page permissions

Notion exports carry content but do not translate Notion's member roles, teamspace access or page-level sharing into XWiki rights. Build a mapping from Notion roles to XWiki users, groups and page rights, then recreate those rights in XWiki's rights model. Confirm how your identity provider will supply accounts before importing content.

Integrations, embeds and linked tools

Embedded content, synced blocks, integrations and links to external tools such as Google Drive or Figma usually arrive as links or placeholders, not working widgets. Inventory every integration and embed, decide whether each becomes an XWiki macro, an iframe or a plain link, and rebuild automations outside the wiki. Confirm with a test export what the archive keeps and what it drops.

How the migration runs from inventory to decommission

The sequence moves Notion content into XWiki in controlled stages, so each space is inventoried, tested on a pilot, run in parallel and only then retired. Each phase produces a written artifact that the next phase depends on.

Inventory spaces, pages, databases and owners
Start by listing every teamspace, top-level page, subpage, database, attachment and external embed in the Notion workspace, and record who owns and who edits each area. Notion workspace-wide exports can take a long time, so confirm with the workspace owner that a full export is permitted and scheduled, and check whether Enterprise security settings disable exports. The output is a page and asset inventory with an owner, a target XWiki space and a decision for each item: migrate, rebuild, archive or delete. The step is done when every owner has signed off their section.
Export and convert a pilot space
Choose one low-risk space with a mix of rich text, images, tables and attachments, then export it from Notion as HTML or Markdown and convert it for XWiki import. Check how headings, callouts, toggles, embedded files and internal links survive the conversion, and note every construct that needs manual rework. Illustrative example: a single team handbook with linked subpages would test link rewriting before any larger space is attempted. The output is a validated pilot with a list of known conversion defects and a fix or workaround for each.
Map databases to XClasses and applications
Notion databases do not move as plain pages, so each one needs a design decision before import. Map each property to an XWiki class property, decide which views become XWiki application pages, live queries or search results, and rebuild relations between records as object links. Export the database as CSV first to check row counts and property types. The output is a mapping sheet that lists each Notion database, its target XClass, property types, relations and the views to rebuild, reviewed by the database owner. Confirm with the implementer whether the XWiki applications needed are part of the standard distribution or a paid extension.
Import and validate each space
Import the remaining spaces in batches using the mapping sheet and the conventions proven on the pilot. After each batch, compare page counts, attachment counts, permissions and internal links against the inventory, and have owners review a sample of pages for formatting and content loss. Record every discrepancy and its resolution in the same inventory, so the state of each space is visible. The output is a reconciliation report per space, signed off by the owner, that shows which items are complete, which are excepted and why.
Run a parallel period with users
Keep Notion available while teams begin working in XWiki for their migrated spaces, and set a clear rule on where new edits go during this period, so content does not diverge. Monitor support questions, broken links and permission complaints, and fix the mapping or the import script where problems repeat. Confirm the length of the parallel period with the project sponsor in writing, because no duration is established here. The output is a log of open issues with an owner and status, and a list of spaces ready for cutover.
Cut over with a read-only Notion workspace
Before cutover, take a final export of each space, confirm the delta since the last import, and then set the Notion pages to read-only for the migrated scope. Announce the change to all members, point old links to the XWiki location where possible, and keep the final export as a retained archive. The output is a signed-off cutover checklist covering the final export checksum, the delta import, permission checks, link redirects and the named approver for each space.
Decommission Notion and retain records
After the read-only period agreed with stakeholders ends, remove Notion seats for migrated teams, cancel the subscription when no scope remains, and confirm that the retained export is stored under your own retention policy. Check whether any compliance or legal hold applies to Notion content, and keep the reconciliation reports as evidence of what moved. Ask your procurement team to confirm the notice period and any data deletion terms in the Notion contract. The output is a decommission record listing cancelled seats, archived exports and the approver for each closure.

What drives cost and duration in a Notion to XWiki move

This table lists the factors that change the effort and spend of moving Notion content into XWiki, and the components you pay for in each. Read it as a checklist: the rows on databases, attachments and permissions usually decide the timeline more than the page count does. The main takeaway is that most of the cost sits in staff time and structure work, not in the software licence, which is free under LGPL-2.1.

Driver or component	Why it moves cost or effort	How to keep it down
Number of Notion databases and relations	Each database must be rebuilt as XWiki structured data with its own classes, fields and views, and relations between databases need explicit links that the export does not carry across.	Inventory every database before starting, retire stale ones, and rebuild only the tables people still use as live structured data.
Volume of attachments and embedded media	Notion's export places files alongside pages, and each attachment must be checked for links, naming and placement in XWiki attachments, which adds time in proportion to file count and size.	Archive large or old media separately, deduplicate files, and set a rule for which attachments are migrated versus referenced.
Permission model complexity	Notion's sharing settings do not map one to one onto XWiki rights at page, space and group level, so each restricted area needs a deliberate rights design and testing.	Simplify to a small set of groups and spaces first, then add exceptions only where a documented business need exists.
Export method and page structure	HTML and Markdown exports differ in how they handle tables, toggles, callouts and nested subpages, so conversion checks and manual fixes scale with the number of unusual layouts.	Pick one export format for a pilot set, document the conversion losses, and standardize templates before bulk moves.
SSO and identity integration	Connecting XWiki to your corporate directory, for example through an OpenID Connect extension such as xwiki-contrib/oidc, requires configuration, testing and ongoing maintenance of that integration.	Confirm the identity provider and protocol early, and check which extension version matches your XWiki release line.
XWiki Pro apps and connectors	Paid Pro applications and connectors, such as those for Active Directory or Office365, add licence cost and configuration work only if your target workflows depend on them.	Start on XWiki Standard, list the features you truly need, and price Pro apps only for those gaps.
XWiki SAS services (consulting and training)	XWiki SAS publishes consulting at 1200 EUR per day, requiring a Business or Enterprise support plan, and training at 1500 EUR per day. Use of these is optional but moves cost directly.	Ask for a fixed-scope written proposal, limit consulting to the specific gaps you cannot fill internally, and train core admins instead of all users.
Internal staff time, hosting and admin	Your own staff plan the move, test content, run the server and patch it. Hosting, backups and upgrades recur for as long as XWiki runs in your environment.	Assign named owners, budget recurring admin hours, and confirm your backup and upgrade routine before go-live.

How the move differs by workspace size and starting point

A small Notion workspace is mostly pages, a few nested sections and perhaps one or two simple tables. For this profile the migration is mainly about moving text, images and attachments into XWiki spaces and pages, with little need to model data. XWiki's depth is available but rarely needed here, so the decision often turns on whether a lighter tool such as Docmost would serve the team with less administration.

Page content: Notion's HTML or Markdown export covers most text, but expect to re-check tables, callouts, toggles and embedded content after import.
Structure: Map Notion's top-level pages to XWiki spaces and keep the hierarchy shallow so navigation stays readable.
Simple tables: Convert small tables to plain wiki tables rather than building structured applications.
Pilot scope: A pilot on a handful of representative pages is usually enough to test formatting and attachment handling.
Paid tiers: XWiki Pro and support subscriptions are generally hard to justify for a small wiki unless the team also needs specific business applications or vendor support.

Before committing, confirm with the XWiki documentation how your exported attachments and embedded media will appear in the target space.

What usually goes wrong and how to prevent it

Most failed Notion-to-XWiki moves fail in predictable places: the export itself, the structure that does not survive it, and the cutover. The cards below pair each risk with a check to run before, during or after the migration, so problems surface in a test space rather than in front of users.

Flattened links and broken references

Notion exports rewrite internal page links and subpage references into file paths, and some links do not resolve once the files are imported into XWiki. Pages then point at old names or at nothing. Before the full run, import a sample of pages that contain heavy cross-linking and count the links that break. Map each broken link to its target page in XWiki and decide whether to repair links by hand or by script.

Lost database relations and views

Notion databases export as CSV, which keeps rows and simple properties but drops relations, rollups, linked views and formulas. In XWiki, rebuilding these means designing structured data classes and applications, which is design work rather than file conversion. Inventory every database, list the relations and views each one depends on, and decide which become XWiki structured objects, which become live-query pages, and which stay as static tables.

Attachment loss or mismatched paths

Exported attachments are stored in folders whose names can change during import, so an image may render in one page and disappear in another. Duplicate file names across pages are a common source of silent overwrites. Verify attachment counts per page against the source export, check that every embedded image and file resolves after import, and record the mapping from original file names to XWiki attachments.

Permissions that do not translate

Notion teamspaces, page-level sharing and guest access have no one-to-one equivalent in XWiki, which uses spaces, page rights and groups. Permissions are often lost or widened during a file-based move, exposing restricted content. Write down the access model for each space before import, recreate groups and rights in XWiki, and test access as a sample of users from each group, including a user who should be denied.

Editing continues in Notion during the run

If people keep editing Notion while the export runs, the XWiki copy starts stale and edits made after the snapshot never arrive. Teams then discover two versions of a policy or runbook. Freeze editing in the affected workspace for the export window, announce the freeze date in writing, and compare the last-modified dates of key pages against the export timestamp before sign-off.

Cutover without an agreed rollback

A cutover with no written rollback path leaves teams unsure which system is authoritative when something breaks. Notion is also the source for the export, so it should stay readable until the new wiki is accepted. Agree in writing who approves go-live, how long Notion stays read-only or available, what triggers a rollback, and how edits made in XWiki during the first days are reconciled.

When XWiki's depth justifies the extra effort

XWiki's extra setup pays off when the knowledge base is itself a system of record. Its strengths are structured data (XWiki applications with typed fields, which is what replaces Notion databases with real schemas), page-level and space-level rights that can be audited, and an extension model that lets you add business applications without forking the core. Those features matter most when documents feed approval flows, policy registers or regulated records, when several business units need different permissions inside one platform, or when you want the Java-based stack and LGPL-2.1 license to sit under your own change control. Before committing, confirm which of these you actually need, and list which Notion databases must behave as queryable data rather than as tables of notes.

Teams that use Notion mainly as a simple wiki are usually better served by a lighter tool. If most of your content is handbooks, meeting notes and how-to articles with a few shared spaces, a tool such as Docmost will migrate faster, needs less administration and asks less of your Tomcat and database operations. Running XWiki well also means someone owns the extensions you choose, the Docker image tag you pin (the official images track stable, LTS and intermediate LTS lines) and the upgrade calendar. If the structured features will sit unused, that ongoing admin time is cost without return. For a side-by-side view of the two platforms against Notion's own model, read the sibling comparison Notion vs XWiki.

Questions buyers ask before moving Notion to XWiki

How much does moving Notion to XWiki cost?

The cost depends on the work you pay for, not on a single license fee, because XWiki Standard is free and open source under LGPL-2.1. The main cost components are the people who prepare the export, convert databases into XWiki structured data, rebuild permissions and navigation, test the result and train users, plus hosting and database infrastructure in your own environment. Recurring costs are hosting, upgrades and support, while most migration work is one-time. The main cost drivers are the number of databases, the volume of attachments, how much permission logic you need to recreate, and whether you use paid extensions. XWiki SAS lists consulting at 1200 EUR per day and training at 1500 EUR per day on its pricing page, and those rates apply only to the engagements its pricing describes. Ask any provider for a written quote that separates one-time migration work from recurring support.

How long does a Notion to XWiki migration take?

Duration depends mainly on how much of your Notion workspace is databases rather than plain pages. Pages exported as HTML or Markdown can be imported with relatively little manual work, while each Notion database needs a decision about how it becomes XWiki structured data, including its properties, relations and views. Notion's own help center says a full workspace export can take up to 30 hours, so the export step alone can add elapsed time before any conversion starts. Ask for a timeline in the written scope that lists pages, databases, attachments, permissions and the test cycle separately, and confirm which of these your provider will deliver.

Why do Notion databases make the migration harder?

Notion databases are tables with typed properties, relations and multiple views, and an HTML or Markdown export flattens much of that structure into documents. Converting them means choosing an XWiki data model for each database, mapping each property to a field, and rebuilding relations and filtered views in a form XWiki can query. The CSV export keeps rows but not the full set of relations and view logic, so you need to plan that rebuild as separate work. Confirm with the provider how many databases you have, which ones are used for live operational tracking, and whether any should move to a different tool instead.

What does the internal team need to provide?

The migration needs a named owner who decides how the wiki will be organized, a reviewer for each space or section who confirms content is still accurate, and someone who can answer questions about permissions and who should see what. Your infrastructure team must provide the hosting environment, database service, backup target and access to the network where XWiki will run. Plan time for stakeholders to approve the information architecture before conversion starts, because restructuring after import is expensive. Ask the provider to list these roles and hours in the written scope so you can assign them before work begins.

Can we do the Notion to XWiki migration ourselves?

Yes, a team with Linux, container and database skills can deploy XWiki and import content without an outside partner, because the official Docker images run on Tomcat with MySQL, PostgreSQL or MariaDB and are maintained by the XWiki Core Dev Team. The harder part is not the installation but the conversion of databases, the permission model and the testing that proves pages and links still work. Do it yourself if you have a small workspace with few databases and staff time to review results. Consider a fixed-scope engagement if your workspace has many databases, strict access rules or a deadline that your own team cannot absorb. Either way, document the steps so the result can be reproduced and audited.

Does XWiki's free edition cover the migration?

XWiki Standard is the free open source edition, and it includes the core wiki features you need to host imported pages and structured data. It does not include a Notion importer, so you must convert the export yourself or use a separate method. The Confluence Migrator Pro extension is a paid product for Confluence backups, not Notion exports, so it does not help with a Notion migration. Confirm with your provider which conversion tooling they will use, whether it is open source, and whether any paid extension is needed for your content.

What do XWiki Pro and Confluence Migrator Pro cover, and what don't they?

XWiki Pro combines XWiki with business applications such as Active Directory and Azure AD SSO, File Manager, Calendar, Diagram and several connectors, and it comes with XWiki SAS support in tiers based on user counts. Confluence Migrator Pro imports Confluence spaces, pages, users, groups, permissions, attachments and page history from XML or CSV backups, but it does not preserve attachment history and it is priced from 2000 EUR per the XWiki Store. Neither product converts Notion exports, and neither covers your permission redesign, database modeling or user acceptance testing. Ask what is in scope for each paid item and whether it is needed at all.

What a DeployOpen migration engagement covers

A DeployOpen engagement plans, implements, integrates, hardens, backs up and documents a self-hosted XWiki inside your own infrastructure, whether that is your cloud account, a data center or an air-gapped network. For a Notion move, the work usually includes choosing the XWiki image variant (the official Docker images come in MySQL, PostgreSQL and MariaDB variants running on Tomcat), setting up the database and attachment storage, configuring authentication and permissions to match your Notion teamspaces, and writing the runbooks your administrators will use after handover. The scope also settles which Notion databases are rebuilt as XWiki structured data and which are flattened into pages, because that decision drives most of the effort.

Migration work runs under a written, fixed scope. Before work starts, the parties agree in writing on which Notion workspaces, page trees and databases are in scope, the target XWiki version and line (stable, LTS or intermediate LTS), the deliverables, and the timeline. Ask for the scope to name the export format you expect (Markdown or HTML from Notion), how attachments and page history will be handled, and what acceptance testing looks like for a sample of migrated pages. If you plan to use XWiki's Confluence Migrator Pro as well, confirm that it is outside the Notion scope and priced separately by XWiki SAS. DeployOpen does not issue audit reports, attestations or certifications. If your organization needs evidence for a compliance assessment, DeployOpen can prepare the systems, controls and records, and the independent auditor or certification body performs the assessment.

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work is complete. A retainer is a sensible choice when your team wants help applying XWiki version upgrades, extension updates and backup restore tests on a recurring basis. Before you sign, confirm in writing what the retainer covers, how requests are prioritized, and who on the DeployOpen side is accountable for each area. Pricing follows from the written scope and is never published as a list.

How DeployOpen scopes and runs a Notion to XWiki migration

DeployOpen plans and implements self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For a Notion to XWiki move, we start with a written scope that fixes which workspaces, pages, databases and permissions are in play before any content is moved.

How we scope

Inventory of Notion workspaces, teams, page trees, databases and attachments that must move
Decision on which Notion databases become XWiki structured data and which stay as static pages
Agreed list of XWiki extensions, authentication method and hosting target before work starts
Written deliverables and timeline agreed in writing, since most engagements are fixed-scope

How we build

Install the official XWiki Docker image variant matching the chosen database, inside the client's environment
Convert Notion HTML or Markdown exports into XWiki pages and check links, images and attachments
Rebuild database views as XWiki structured data classes and test filtering and permissions against the scope
Test access rules with sample users from each group before any production content is loaded

How we hand over

Runbook covering installation, configuration, upgrade steps and backup and restore procedures
Migration log listing every page, space and attachment moved and any items left behind
Documentation of permission model, extension versions and how to add new spaces or applications
Knowledge transfer sessions with the administrators who will own the platform after handover

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Retainer scope to be agreed in writing, including which XWiki release lines are covered
Ask for the support boundary in writing, including which XWiki SAS extensions are included

Migrate from Notion to XWiki