Notion or XWiki: which fits a self-hosted knowledge base decision
XWiki is the deeper, LGPL-2.1 option, and Notion is the lighter hosted option. If your renewal, a data residency rule or a lock-in concern is pushing the wiki onto your own infrastructure, the choice is less about features on a comparison sheet and more about how much structure your content needs and who will maintain it. Notion is built for fast adoption: non-technical staff can start writing pages and building databases within minutes, with little administration. XWiki asks more of the team up front, but it gives you structured data (typed objects and applications), fine-grained rights on spaces and pages, and an extension model that can add identity integration and business applications. Notion does not run on your servers, so its residency and lock-in questions are answered by contract and export, not by architecture.
Fit depends on three things: how much structure the content needs, how deeply the wiki must integrate with your identity provider, and how much administration capacity you have. If the knowledge base is mostly prose, runbooks and onboarding material owned by many teams, Notion's editing model and a lighter self-hosted tool may serve better. If you need page-level permissions tied to groups from Active Directory or another directory, reusable data models for policies or service catalogs, or approval-style workflows, XWiki's depth starts to pay off. Confirm with XWiki SAS or your integrator which identity connectors and extensions your version supports, because some of the features you need may sit in the paid XWiki Pro catalog rather than in XWiki Standard.
Before committing, run a short test: take one real space with its permission model, a few structured records and the team that will administer it. Ask who will own the XWiki instance, who handles upgrades between the stable and LTS lines, and who will write any custom applications. Those answers, not the feature list, usually decide the outcome. If the team cannot name an administrator, a lighter tool or a fixed-scope implementation with a support retainer is a safer starting point than a deep platform run without owners.
Which scenarios favor XWiki and which favor Notion
This table matches common team situations to the platform that usually fits better, based on permissions depth, existing Confluence content, document-versus-database mix and available admin capacity. Read each row as a starting point, then confirm the named features against current plan details and your own environment before deciding.
| Scenario | Better fit | Reason |
|---|---|---|
| Regulated team needing fine-grained page and space permissions | XWiki | XWiki Standard is free and open source, and its rights model is set per space and page, so access can be scoped in your own environment. Confirm the exact rights you need against XWiki's documentation. |
| Team with a large Confluence history | XWiki | The Confluence Migrator Pro extension imports XML and CSV backups with pages, spaces, permissions, users and groups, though attachment history is not kept. Plan for a paid migration tool and a review of what the import leaves out. |
| Team with mostly documents and few databases | Notion | Notion's pages and editor suit document-centric work with little structure, and the setup is minimal. Self-hosted options such as Docmost may also fit this profile at lower operational cost. |
| Team with many structured trackers and linked databases | XWiki | XWiki structured data and applications model records and relations inside the wiki, but they need design work. Notion databases are quicker to build but do not map one-to-one, so confirm the data model first. |
| Small team without a dedicated administrator | Notion | Notion is hosted, so no server, upgrades or database maintenance fall on your staff. XWiki self-hosting requires someone to run Tomcat, a database and extension updates. |
| Organization that needs vendor support on premises | XWiki | XWiki SAS offers on-premises professional support, installation help and training under paid plans. Ask for the support tier and response terms in writing before committing. |
| Organization with strict data residency or air-gap rules | XWiki | XWiki runs entirely inside your infrastructure under LGPL-2.1, so content stays within your own network. Notion stores content in its hosted service, which may conflict with these rules. |
| Team that wants a light, fast deployment | Notion | Notion needs no installation and onboarding is immediate. A lighter self-hosted tool such as Docmost may be a better self-hosted fit than XWiki for this profile. |
How XWiki's structured applications differ from Notion databases
Notion databases are block-based tables: each row is a page, properties are columns, and views such as tables, boards or calendars are different lenses on the same records. XWiki works from a different model. Its unit is the wiki page, and pages sit in a hierarchy of spaces. Structured data is added on top of that page model, typically through XWiki's class and object concept, so a page can carry typed fields and the wiki can present many pages of the same kind as a list. The practical difference is that in XWiki structure is a property of the wiki's data model rather than a property of a table block, and that changes who designs it and how it is governed. Before you migrate, confirm with XWiki SAS or in the official XWiki documentation exactly which field types, list views and access controls your chosen version provides, because this page does not rely on feature details beyond those supplied.
The depth matters when records need to be typed, consistently filled, and reused across the wiki. Examples include a register of vendor assessments, a set of runbooks that must each carry an owner and review date, or a catalog of policies that need to be found by attribute. In these cases the value comes from enforcing a schema and from the wiki's existing page permissions applying to the same content. Extensions are the second reason. XWiki Standard is free and open source, while XWiki Pro adds business applications and connectors, so a team should list the specific extensions it needs and check their licensing before it commits to a design. Workflows are the third reason, and they should be confirmed against the supplied extension list rather than assumed.
The depth adds setup without value when your content is mostly prose with a few tables, such as a handbook, an onboarding guide or a set of how-to articles. In those cases a lighter wiki such as Docmost, which the Docmost GitHub repository describes as an AGPL-3.0 project, may be the better fit, and the cost of designing classes and templates is not recovered. A useful test is to count how many Notion databases carry properties that someone filters or reports on each week. If that number is small, plan to keep those tables as simple structured pages and skip the application build. If it is large, budget for schema design as a separate workstream, and ask any implementation partner to define it in a written scope before work begins.
What self-hosting XWiki changes for data location and compliance
Self-hosting XWiki moves the wiki, its database and its attachments into your own cloud account, data center or air-gapped network. The cards below cover where that data sits, how the deployment is built, how users sign in, who owns backups, and what it means for the evidence a compliance assessment will ask for.
Data location is your decision
With a self-run XWiki, pages, attachments, user data and the database stay in the accounts, data centers or air-gapped networks you choose. Notion stores workspace content on its own infrastructure, so the residency question moves from a vendor contract to your architecture. Confirm which regions, subprocessors and log destinations your own environment will use before you pick a hosting model.
Official Docker images
The official XWiki images come in MySQL, PostgreSQL and MariaDB variants, each running on Tomcat, for amd64 and arm64v8. Choosing the database variant fixes a significant part of your operating model, so align it with the database standard your platform team already supports. Check the image tag you pin against the stable, LTS and intermediate LTS lines before you standardize on it.
Identity through SSO
XWiki Pro lists Active Directory and Azure Active Directory SSO applications, which is the commercial route to directory sign-in. Open-source OIDC integration is available through the xwiki-contrib project, but you should test it against your identity provider's claims, group mapping and session rules before relying on it. Document which option you chose, because access reviews depend on it.
Backups are your responsibility
In a self-run deployment, you own database dumps, attachment storage, configuration and restore testing. Atlassian's Confluence Cloud offers space exports and a site backup in its backup manager, but with XWiki there is no vendor-run backup unless you buy it from a hosting provider. Define recovery point and recovery time targets in writing, and test a restore into a separate environment on a schedule.
Cloud hosting versus self-run
XWiki SAS offers XWiki Cloud hosting on ISO 27001 certified infrastructure, which shifts operations to the vendor and its certification scope. A self-run deployment keeps operations, patching and evidence collection with your team, or with a partner you contract. Ask the vendor for the exact scope of any certification it cites, and confirm whether that scope covers your data classification.
Evidence comes from auditors
Compliance evidence for XWiki, such as access reviews, change records and backup test results, is produced by your operations team and reviewed by an independent auditor or certification body. DeployOpen prepares the controls, configurations and evidence sets for that review, but does not issue audit reports, attestations or certifications. Agree with your assessor early which controls they expect to see and in what format.
XWiki Standard, XWiki Pro and what the LGPL-2.1 license allows
XWiki Standard is the free, open-source platform, and the official Docker images are licensed under LGPL-2.1 as well. That means you can download, install and run the core wiki inside your own infrastructure without a subscription from XWiki SAS. The LGPL-2.1 terms govern how you distribute and modify the library code, so a team that only runs XWiki internally and keeps its customizations in its own extensions has a straightforward position. Before you rely on that, have your legal or compliance team read the license with your intended use in mind, and confirm which image variant (MySQL, PostgreSQL or MariaDB) and which release line (stable, LTS or intermediate LTS) your platform team will standardize on. The Docker image documentation and library file list the current tags for each line.
XWiki Pro is a different decision. It bundles business applications such as File Manager, Forum, Polls, Calendar, Ideas, Meeting and Diagram, plus Active Directory and Azure Active Directory SSO applications and connectors for Google Apps, Office365 and OnlyOffice. Support subscriptions are sold in Starter (up to 25 users, XWiki Cloud only), Basic (up to 1,000 users), Business (up to 10,000 users) and Enterprise (unlimited users) tiers. The condition that matters is headcount and whether you need a vendor to answer for production issues. A small internal wiki on Standard with community-level skills may never need the paid tier, while a regulated organization that must show a supported platform and a named escalation path usually will. XWiki SAS states that cloud and on-premises pricing is the same, so confirm which tier and extensions you need and ask for a written quote that lists each one.
On the Notion side, the only plan terms we can confirm from the researched sources are the export and single sign-on limits: Notion's Include subpages option for PDF export is limited to Business and Enterprise plans, SAML SSO is available from Business, and Enterprise workspaces can disable exports in their security settings. Notion's plan structure and pricing change, so confirm current terms directly with Notion before you compare costs. Whatever tier you choose, plan for the cost of running XWiki yourself, including hosting, administration and any paid extensions, and ask any implementation partner to price those components separately.
What the XWiki total cost includes compared with a Notion subscription
What does hosting XWiki cost compared with a Notion subscription?
Hosting is the cost Notion hides in its per-member price, so you pay for it directly with XWiki. Your infrastructure team pays for servers or cloud instances, a database (MySQL, PostgreSQL or MariaDB, matching the official Docker image variants), backups, monitoring and TLS certificates. These costs recur monthly or yearly. They rise with the number of users, attachment volume and the number of environments you run, such as separate test and production instances. Ask your team or provider to price each component for your expected load, and confirm which XWiki Docker image variant and Tomcat setup your platform standard supports before you size anything.
Is XWiki Pro or a support subscription required to run XWiki?
No. XWiki Standard is the free open source version, so the core wiki carries no license fee. XWiki Pro adds business applications and connectors, such as Active Directory and Azure Active Directory SSO applications, File Manager, Polls, Calendar and Office365 connectors, and it comes with XWiki SAS support. Pro and support subscriptions are recurring and are sized by tier: Starter (up to 25 users, XWiki Cloud only), Basic (up to 1,000 users), Business (up to 10,000 users) and Enterprise (unlimited users). XWiki SAS states that cloud and on-premises pricing is the same. Decide which Pro applications you need, then request a quote for that tier from XWiki SAS.
How much does XWiki consulting cost per day?
XWiki SAS lists consulting at 1200 EUR per day, and that rate requires a Business or Enterprise support plan. Consulting is one-time or episodic, which covers configuration help, custom structured applications and integration work. Costs go up with the size of the data model, the number of identity and connector integrations, and how many rounds of review your team needs. They go down when you document requirements first and limit the first release to the spaces and applications you need. Ask for the day estimate in writing, the assumptions behind it, and whether the support plan is included in the consulting quote or billed separately.
What does XWiki training cost and who needs it?
XWiki SAS lists training at 1500 EUR per day. Training is a one-time cost for most teams, although you may repeat it when new administrators or editors join. Administrators need it for upgrades, extension management, permissions and backups. Content editors need it when you build structured applications, forms or templates. Costs rise with the number of cohorts, the number of sessions and whether the course is delivered on your premises. Costs fall when your team trains a small group of internal champions who then teach others. Ask what the course covers, who the trainer is, how many people it accommodates and what materials you keep afterward.
What does the Confluence Migrator Pro extension cost, and is there a trial?
Confluence Migrator Pro is sold as a paid extension by XWiki SAS, and it is priced from 2000 EUR. It is a one-time license cost for the migration itself, separate from any recurring support plan. The trial is limited to 30 pages per migration, so a trial run tests a sample rather than a full workspace. The cost and effort rise with the number of spaces, page history, permissions complexity and the amount of cleanup required afterward. Note that it keeps page history but not attachment history. Ask XWiki SAS for the exact license tier that fits your Confluence source, and ask your team to test the trial against a representative set of pages before you commit.
How much internal admin time does a self-hosted XWiki need?
Internal admin time is the cost most often underestimated. Your team carries recurring work: applying XWiki platform and extension upgrades, monitoring the server, managing users and groups, reviewing permissions, testing backups and restores, and handling support requests from users. The amount depends on how many extensions you run, how many integrations you maintain and whether you choose the stable line or an LTS line, which changes how often you upgrade. Ask your team to estimate those hours per month, and treat that estimate as the largest recurring line in your comparison with Notion's subscription.
What does an XWiki upgrade cost over time?
Each upgrade is a recurring effort, and its cost depends on the extensions and customizations you have added. Upgrades involve a staging test, a database backup, applying the new image or package, checking extensions for compatibility and validating permissions and structured applications. Costs rise when you run many extensions, custom Velocity or Groovy code, or Pro applications that must match the platform version. Costs fall when you keep to standard features, pin a supported LTS line and test on a copy of production. Confirm the upgrade path and support window for your chosen line with XWiki SAS or your provider before you budget for it.
What should I ask for in a quote for an XWiki deployment?
Ask for a written scope that separates one-time and recurring costs. The quote should list each component: hosting assumptions, the Pro or support tier and its user count, consulting days, training sessions, the Confluence Migrator Pro license if you migrate, and an allowance for admin time and upgrades. Ask which items are fixed and which are billed by time, what assumptions drive the estimate, how many pages or users it covers, and what is excluded. For your own cost comparison, ask for a three-year view that shows the first-year setup costs separately from later recurring costs. DeployOpen plans and implements self-hosted platforms in your own infrastructure under a fixed scope agreed in writing, and quotes follow from that scope.
How a move from Notion to XWiki usually proceeds
The sequence turns a Notion workspace into a permissioned XWiki instance that your team hosts, with pages, structured data and access rules checked before anyone is cut over. Each step ends with an output you can review before moving on.
Inventory the workspace and its owners
List every teamspace, top-level page, database, linked view, integration and member group in the Notion workspace, and note who owns each area and who reads it. Record which pages are live reference material, which are stale and which are personal drafts. The output is a shared inventory that business owners have signed off, so that nothing is migrated by accident or dropped without a decision. Confirm with Notion which export options your plan includes before you plan around them.
Export pages and databases from Notion
Workspace owners run the export from Notion's settings, choosing Markdown or HTML for page content and CSV for databases. Notion states that a full workspace export can take up to 30 hours, so schedule it and do not assume it finishes during a single working session. The Include subpages option for PDF export is limited to Business and Enterprise plans, so if you rely on it, confirm your plan first. Enterprise workspaces can disable exports in their security settings, so confirm with the workspace administrator before you start. The output is a complete archive that you check against the inventory, with missing pages logged.
Design the XWiki structure and permissions
Decide how spaces map to Notion teamspaces, how pages nest, and which groups can view, edit or administer each space. Choose the XWiki edition and hosting model, and confirm which identity source will provide users and groups. Document the structure in a short design note that names the owners of each space and the review process for permission changes. The output is an approved design that a security or compliance reviewer can read without asking for context, and it becomes the reference for the import and verification steps.
Rebuild databases as structured data
Notion databases do not move as plain pages. Map each database's properties to XWiki structured data, such as classes and fields, and decide which Notion views, relations and rollups need to be recreated by hand or simplified. Expect this to be the most design-heavy part of the move and to need subject-matter owners to confirm field meanings. The output is a tested data model with a sample of records loaded, plus a list of Notion features that did not carry over, so the business can accept or change them before cutover.
Import pages and verify content
Load the exported content into a staging XWiki instance, converting Markdown or HTML pages and attaching files, then rebuild links and navigation. Compare a defined sample of pages and records against the Notion source, checking text, images, tables, links, page hierarchy and permissions. If you need to move Confluence content as well, XWiki's commercial Confluence Migrator Pro is a separate product with its own licensing, so treat it as a separate scoping decision. The output is a signed verification record that lists the checked items, the defects found and their fixes.
Test access and train the owners
Run user acceptance testing with a representative group for each space, confirming that people can see what they should see and nothing more. Test authentication against your identity provider, administrator roles and the edit workflow. Train space owners and editors on the new structure, the editing conventions and where to raise problems. The output is a test log with each permission scenario recorded as passed or failed, and a list of owners who have completed training.
Cut over and retire the Notion workspace
Agree a cutover date with the business, freeze edits in Notion for the affected areas, run a final delta import and point links, bookmarks and integrations to XWiki. Keep the Notion workspace in read-only mode for a period agreed in advance so that users can check for missing content. Once the owners confirm, retire the workspace and record the decision, the final export archive and where it is stored. The output is a closed migration record, a retained archive and a clear owner for the XWiki instance after handover.
Questions buyers ask before choosing XWiki over Notion
How much effort does a Notion to XWiki move take?
The effort depends mostly on how much of your Notion workspace is structured data rather than prose. Plain pages move through Notion's HTML or Markdown export with modest cleanup, while Notion databases, relations, rollups and linked views must be rebuilt as XWiki structured data or applications. Other drivers include the number of spaces, how permissions were set up in Notion, the volume of attachments, and how many people must be trained on the new editor. Ask any implementation partner to size the work from a sample export of your own workspace, since the workspace itself is the best predictor of effort.
Can our team migrate from Notion to XWiki without outside help?
A capable team can move simple wikis in-house, especially if it already runs Linux, containers and a relational database. The harder parts are rebuilding databases as structured data, mapping Notion's member and guest permissions to XWiki's rights model, and validating that content and links survive the move. Teams without that experience often choose a fixed-scope engagement for the migration and hand over runbooks, so their own staff can operate the platform afterward. DeployOpen plans, implements, integrates, documents and supports self-hosted platforms in your own infrastructure, with scope and deliverables agreed in writing before work starts.
How long does a migration from Notion to XWiki run?
No timeline for this migration has been established here, so treat any figure you see elsewhere with caution. The duration is driven by workspace size, the number of databases to rebuild, permission complexity, integration requirements and how much content review your organization requires before cutover. Notion itself notes that a full workspace export can take up to 30 hours, which is a useful planning input for the export stage alone. Ask for a written schedule that separates discovery, export, rebuild, validation and user training.
Is XWiki free to run in our own infrastructure?
XWiki Standard is free open source software under the LGPL 2.1 license, so there is no license fee to run it yourself. Costs come from the infrastructure that hosts it, the database and Tomcat setup, backups, upgrades, monitoring, and the staff time to operate it. Official Docker images are available in MySQL, PostgreSQL and MariaDB variants, which helps standardize deployment. Paid costs arise only if you add XWiki Pro applications, connectors, a paid migration tool or a support subscription.
When is XWiki Pro or a support subscription worth paying for?
XWiki Pro is worth evaluating when you need specific business applications, such as Active Directory or Azure Active Directory SSO, a File Manager, or connectors for Office365 or OnlyOffice, without building them yourself. A support subscription is worth considering when your organization needs a vendor accountable for fixes and on-premises help. Pricing is tiered by user count, with Starter covering up to 25 users on XWiki Cloud only, and XWiki SAS states that cloud and on-premises pricing is the same. Ask for the tier that matches your user count and compare the Pro applications against what you would otherwise build and maintain.
What does the Confluence Migrator Pro add to the cost?
Confluence Migrator Pro is a paid extension from XWiki SAS, and its published starting price is 2000 EUR, according to XWiki Store. It is relevant only if your source is Confluence rather than Notion, since it imports XML and CSV backups from Confluence Server, Data Center and Cloud. For Notion sources, the open-source path is usually cheaper to start but needs more manual rebuilding. Ask whether the tool is needed at all for your specific source before budgeting for it.
When should we choose Docmost as the first step instead of XWiki?
Choose Docmost first when your Notion use is mostly team documentation, meeting notes and spaces, and you need a lighter tool that is quick to adopt. Docmost is licensed AGPL-3.0, accepts Markdown, HTML and Notion exports in its import dialog, and exports pages as Markdown or HTML. Its Confluence, DOCX and PDF importers are paid-edition features, so confirm that scope before relying on them. XWiki is the stronger choice when you need structured applications, granular permissions and extensibility, and your team can carry the extra setup and operational effort.
What should we confirm before committing to XWiki?
Confirm the list of Notion databases and their relations, the permission model you need to reproduce, the identity provider you will integrate, and the backup and recovery targets your policies require. Ask whether you need Pro applications or a support tier, and request a sample migration from a representative subset of your workspace. Confirm the supported XWiki release line, because stable, intermediate LTS and LTS lines have different upgrade expectations. Put all of these in a written scope before work starts, so the cost and timeline reflect your actual environment.
When XWiki's depth is worth more setup than Docmost
Start with the lighter tool unless you can name the structure you need. Docmost is licensed AGPL-3.0 and its import dialog accepts Notion exports directly, so a team that mostly moves pages, handbooks and runbooks can get a self-hosted wiki running and populated with far less design work than XWiki requires. Its Confluence and DOCX importers are paid-edition features, which matters if your source material sits in those formats. Docmost is the right first step when the content is document-shaped and the access model is space-level. Before committing to XWiki, confirm with each vendor which importers and permission features sit in the edition you plan to run, and test a representative export from your own Notion workspace in both tools.
XWiki's structure pays back when the knowledge base stops being a collection of pages and becomes a system of typed records. Look for several of these conditions together: many record types with defined fields (such as vendors, assets, policies, risks or incidents) that need consistent reporting, permissions that must be enforced per page, per field or per object for different roles, custom applications or macros that your teams will extend over years, and a knowledge base expected to outlive several tool and staff changes. In that situation, the cost of modeling data in XWiki is paid once and returns in queries, templates and access rules. If your need is mostly rich text with a few tables, the same setup effort buys little.
Plan the decision as a pilot with exit criteria rather than a platform choice. Migrate one department's Notion pages and one database into both tools, then measure how long it takes an administrator to model a record type, set permissions and add an extension, and whether an editor can work without help. Ask XWiki SAS, or your implementation partner, what support tier and extension licenses the target design needs, and check that the required Pro applications and connectors exist in the edition you choose. Choosing XWiki after that test is a deliberate investment; choosing it before you know your record types is usually where the extra setup becomes waste.
How DeployOpen evaluates, implements and migrates XWiki
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Notion vs XWiki, the work starts with a written scope that decides which spaces, permissions and structured content move, and which stay in Notion.
How we scope
- Inventory which Notion spaces, pages, databases and permission groups need to become XWiki spaces, pages or structured applications.
- Agree in writing which XWiki extensions, identity integration and hosting model are in scope before any work starts.
- Confirm with your team whether Confluence-style permissions, attachments and page history must carry over, and document the gaps.
How we build
- Install the official XWiki Docker images in your environment, choosing the database variant that matches your standards and approved stack.
- Rebuild the Notion database schemas as XWiki structured data, then test views, permissions and search against sample content.
- Configure single sign-on and group mapping, and run test migrations of Notion HTML or Markdown exports before any production cutover.
How we hand over
- Deliver runbooks for installation, upgrades, backups, restores and the extension list, so your operators can run the platform without us.
- Document the migration decisions, including which content was rebuilt by hand, left in Notion or archived as static exports.
- Provide evidence packs of configuration, access control and backup tests that your internal or external auditors can review.
How we support
- Fixed-scope engagements are agreed in writing, with deliverables and timelines set before work begins.
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped to your XWiki version and extensions.
- Ask your DeployOpen contact to confirm how XWiki version upgrades and extension updates will be tested in your environment.
