Which wiki fits a Confluence replacement shortlist
Teams replacing Confluence with a self-hosted wiki usually shortlist three options, and the choice turns on how much content you will hold and how fine-grained your permissions must be. XWiki fits structured, permission-heavy content at scale, with rights that can be set at wiki, page or hierarchy level. BookStack fits a simpler book, chapter and page model under MIT terms, which suits documentation shelves with moderate permission needs. Wiki.js 2.x fits Markdown-first teams that can dedicate a domain or subdomain to the wiki, but the 3.0 line is still in beta and marked not for production use, so plan around the 2.x line. Start by counting your pages, listing the spaces that need restricted access, and noting whether you need an extension ecosystem for business apps.
Licensing and runtime requirements should be checked before any demo. XWiki is LGPL-2.1-or-later, BookStack is MIT licensed and requires PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 or later, and Wiki.js is AGPL-3.0 licensed with PostgreSQL recommended. Confirm with your platform team which stack your operations group already runs, because a PHP or Node.js footprint is a different maintenance load from XWiki's Java and Tomcat setup. Ask each vendor or community which version line receives security fixes and for how long, since XWiki maintains several release branches in parallel.
Your identity provider is the next filter. BookStack supports OIDC, SAML2 and LDAP sign-in, and Wiki.js offers SAML 2.0, OpenID Connect and LDAP modules, so confirm the exact group mapping and role sync you need in your environment. Plan the migration effort separately, since a Confluence export is not a single click for any of the three. Pilot the shortlist on a representative slice of spaces, including one restricted space, and make the decision on what you observe in your own environment rather than on feature lists alone.
Which scenario points to which wiki
This table maps common replacement scenarios to the wiki that fits best and the supplied fact that drives the choice. Read each row as a starting point, then confirm the listed item in your own environment before you decide, since the fit depends on your page volume, permission model and migration source.
| Scenario | Best fit | Driving fact and what to confirm |
|---|---|---|
| Large page counts with per-page or hierarchy rights | XWiki | XWiki grants view, comment, edit and delete rights at wiki, page or hierarchy level. Confirm the number of spaces, pages and groups you need to model, and test the rights model on a sample before migrating. |
| Small team documenting procedures | BookStack | BookStack organizes content into books, chapters and pages on shelves, with a WYSIWYG editor and a full role and permission system. Confirm that shelf and book-level roles cover your access rules without per-page exceptions. |
| Markdown-first engineering group | Wiki.js | Wiki.js 2.x offers an optional Git storage module that synchronizes content in both directions. Confirm that the stable 2.x line meets your needs, because the 3.0 successor is still in beta and marked not for production use. |
| Markdown-first group that also needs a wiki-level editor | BookStack | BookStack offers an optional Markdown editor alongside its WYSIWYG editor and built-in diagrams.net diagrams. Confirm whether Git-based version control matters to your team, since BookStack does not list a Git storage module in the supplied facts. |
| Team that needs Confluence page history migrated | XWiki | Confluence Migrator Pro from XWiki SAS keeps page history but not attachment history, and migrates spaces, users, groups and permissions. Confirm with XWiki SAS whether attachment history loss is acceptable and run the 30-page trial limit on a representative space first. |
| Teams that need SSO and MFA enforced by role | BookStack | BookStack supports OIDC, SAML2 and LDAP sign-in and multi-factor authentication enforced per role. Confirm the identity provider you use is covered by these protocols and that the enforcement setting matches your policy. |
| Teams that need Active Directory or Azure AD SSO on XWiki | XWiki | XWiki Pro lists Active Directory and Azure Active Directory SSO applications, which are paid Pro components. Confirm the edition, user tier and support plan with XWiki SAS before you plan around them. |
| Teams with no internet access at install time | Wiki.js | Wiki.js supports sideloading files for environments without internet access and runs on Linux, Docker and Kubernetes. Confirm that your offline install path and plugin needs are covered before you commit. |
What is free and what is paid in each wiki
XWiki is licensed under the LGPL 2.1, and the free XWiki Standard edition is the open source version you can self-host without a license fee. XWiki Pro is the paid layer from XWiki SAS. It bundles business applications and connectors with XWiki SAS support, including Active Directory and Azure Active Directory SSO applications, File Manager, Forum, Polls, Calendar, Diagram, and Google Apps, Office365 and OnlyOffice connectors. Pro and support subscriptions come 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.
- Free core: XWiki Standard carries no license fee under the LGPL 2.1, so the cost is the servers, the database and the staff who run it.
- Same price in cloud or on premises: XWiki SAS states that cloud and on-premises pricing is the same for Pro and support subscriptions, per xwiki.com pricing.
- Consulting and training rates: XWiki SAS lists consulting at 1200 EUR per day, which requires a Business or Enterprise support plan, and training at 1500 EUR per day, per xwiki.com pricing.
- Confluence migration tooling: Confluence Migrator Pro is priced from 2000 EUR, with a trial limited to 30 pages per migration, per the XWiki Store.
- Recurring versus one-time: Subscriptions recur, while consulting, training and migration tooling are typically one-time purchases.
Confirm with XWiki SAS which apps, connectors and user tier your organization needs, and ask for the support hours and channels in writing before you sign.
BookStack is MIT licensed, so the core platform is free to use, modify and self-host without a license fee. The project is developed with community contributors and offers paid support plans and sponsorship, which are the only commercial routes listed on its site. Features that many teams expect to pay for, such as multi-factor authentication and role-based permissions, sit in the core rather than behind a paid edition.
- MIT core: The platform itself carries no license fee, and you can change it without a copyleft obligation.
- Paid support plans: Support is sold by the project, and BookStack's site lists paid support plans and sponsorship. Ask for the price, response scope and what the plan covers in writing, because the site does not publish those terms.
- Built-in security controls: Multi-factor authentication can be enforced per role, and the full role and permission system is included, per bookstackapp.com.
- Sign-in options: OIDC, SAML2 and LDAP sign-in are part of the core, so identity integration does not require a paid tier.
- Hosting cost: You pay for PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 or later, plus the staff time to patch and back up the system.
Ask the project directly which support plan fits your environment, and confirm that every identity and MFA feature you need is in the version you intend to run.
Wiki.js is licensed under AGPL-3.0, so the code is free to use, but anyone who modifies it and offers it over a network must share those changes. The stable line is the 2.x series, now maintained in the requarks/wiki-v2 repository, where v2.5.316 was published on October 2, 2026. The 3.0 release lives in the main requarks/wiki repository and is marked as beta and not for production use, so it is not a choice for a regulated production deployment today.
- AGPL-3.0 obligations: Modified deployments that are offered to users over a network must make the source of those changes available.
- Stable 2.x line: Plan on v2.5.316 or a later 2.x release for production, and confirm the release status before you commit.
- 3.0 beta: The 3.0 code in the main repository is labeled not for production use, so treat it as a test track only.
- Authentication without a paid tier: Azure AD, GitHub, Google, Keycloak, LDAP, OpenID, Okta and SAML 2.0 modules are documented, with TOTP two-factor authentication.
- Commercial support: Confirm with the maintainers or a third party whether paid support exists, since the topic sources do not list a paid tier.
Ask whether your team will run 2.x long term or wait for 3.0, and check the release notes before planning an upgrade path.
What drives the running cost of each wiki
Running cost for these three wikis comes from a handful of recurring components: the database and runtime you commit to, the hosting and backups you operate, the SSO and connector work you take on, and the staff time to upgrade. The Confluence migration tooling is a one-time cost, while the rest recur for as long as the wiki is in use.
Database and runtime choices
XWiki's official Docker images come in MySQL, PostgreSQL and MariaDB variants, each running on Tomcat. BookStack requires PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 or later. Wiki.js 2.x recommends PostgreSQL and also supports MySQL, MariaDB, MS SQL and SQLite. Your database choice sets which skills and patching cycles you pay for every year. Ask your team which engine they already operate, and confirm the minimum versions with each vendor before you size the environment.
Hosting and backups
All three wikis are self-hosted in your infrastructure, so you carry the compute, storage, backup schedule and restore testing. Wiki.js requires a dedicated domain or subdomain and at least 1 GB of RAM on Linux. BookStack publishes installation scripts for Ubuntu and points to community Docker setups rather than official images. XWiki's images are maintained by its core dev team. Quote backup and restore tests as a recurring line item, not a one-time setup task.
SSO and connector work
BookStack supports OIDC, SAML2 and LDAP sign-in with role-based MFA. Wiki.js ships authentication modules for Azure AD, Keycloak, LDAP, Okta and SAML 2.0. XWiki Pro lists Active Directory and Azure Active Directory SSO applications and Office365 and OnlyOffice connectors, and its paid tiers sit on top of the free Standard edition. Each identity integration needs testing, certificate or secret rotation and support when your identity provider changes. Ask for SSO setup and connector work to be written as a fixed scope with named test cases.
Confluence migration tooling
Confluence Migrator Pro from XWiki SAS moves spaces, pages, users, groups, permissions and attachments, and keeps page history but not attachment history. It is priced from 2000 EUR, and its trial is limited to 30 pages per migration, so a full estimate needs a test run on your own content. This is a one-time cost for the move. BookStack and Wiki.js migrations require your own scripts or manual work, so budget that effort separately and ask each vendor what is included.
Staff time for release branch upgrades
XWiki runs parallel release branches: 18.8.0 is the stable line, 18.4.7 is the intermediate LTS and 17.10.14 is the LTS line. Choosing a branch decides how often your team upgrades and how long each upgrade cycle takes. BookStack ships frequent minor releases, and Wiki.js 2.x is maintained on its own repository. Ask each vendor for its support window per branch and agree who tests upgrades, who approves them and who is paid to do the work.
Recovering if Wiki.js 3.0 lands late
Wiki.js 3.0 sits in the main repository as a beta marked not for production use, while the stable 2.x line is maintained separately. If you adopt 2.x now and 3.0 arrives later, migration to it is an unscheduled project that you may have to fund. Treat that as a contingency. Ask any implementer whether a 3.0 upgrade is in scope, what it would cost to rebuild content and integrations, and whether you can keep 2.x supported until you choose to move.
How the wiki, database and identity provider connect
The deployment shape differs more than the feature lists suggest, so map it before comparing anything else. XWiki runs on Tomcat from one of its official Docker images, which come in MySQL, PostgreSQL and MariaDB variants, so the database choice is made at image selection and carried into every environment. BookStack runs on PHP with MySQL 8.0 or MariaDB 10.6 or later behind a web server you provide, and it does not publish official Docker images, so your team owns the container or host setup. Wiki.js 2.x runs on Node.js, needs a dedicated domain or subdomain because it cannot be mapped to a subfolder, and recommends PostgreSQL 9.5 or later. Confirm with your platform team which database engine and container standard you already operate, because that choice drives backup, patching and on-call effort for each wiki.
Sign-in is brokered by the identity provider, not by the wiki. BookStack supports OIDC, SAML2 and LDAP, and Wiki.js ships modules for Keycloak OpenID Connect, LDAP and Active Directory, generic OpenID and OAuth2, Okta and SAML 2.0, with TOTP two-factor authentication. XWiki SSO depends on extensions: Pro lists Active Directory and Azure Active Directory SSO applications, and the community xwiki-contrib/oidc project is the public starting point for OIDC. Check whether your SSO requirement is met by a free module, a paid Pro application, or a custom extension you will have to maintain across upgrades. Test group mapping and account deprovisioning end to end, since a disabled directory account should lose wiki access without manual cleanup.
Permissions are enforced inside each wiki, so the identity provider supplies users and groups while the wiki decides what they can see. XWiki applies view, comment, edit and delete rights at wiki, page or hierarchy level, which is the control most likely to matter for regulated content. BookStack enforces its role and permission system at the shelf, book, chapter and page level and can require multi-factor authentication per role. Wiki.js access control is narrower in its documented scope, so verify the page-level rules you need against a test space before committing. Whatever you choose, write down which group maps to which right, test it with a non-administrator account, and keep the mapping under version control so audits can trace it.
How Wiki.js 3.0 beta changes the maintenance risk
The stable Wiki.js line today is 2.x, maintained in the requarks/wiki-v2 repository, where v2.5.316 was published on October 2, 2026. The 3.0 code sits in the main requarks/wiki repository, and its README marks it as beta and not for production use. For a wiki that a team expects to run for many years, the decision is therefore not about which version has the newest features. It is about whether you are willing to build on a stable line whose named successor is unfinished, and what you will do when the 2.x line eventually stops receiving the fixes you depend on.
The practical risk has three parts. First, a future move from 2.x to 3.0 could change the database schema, authentication modules, storage modules or the editor, so the content you migrate in 2026 may need another migration later. Second, if 3.0 slips, the 2.x line may carry security fixes for longer than you planned, or it may not, and no public end-of-life date is supplied for us to quote. Third, a small maintainer base means a single lapse in release activity can leave a production wiki waiting. Treat these as open questions to plan around, not as predictions.
Before committing, ask the Wiki.js maintainers in writing: whether 2.x will receive security fixes after 3.0 reaches a stable release, what the published support window for 2.x is, whether there is a documented upgrade path and migration tool from 2.x to 3.0, and whether 3.0 changes the supported databases, authentication modules or storage modules. Then check the Wiki.js 2 releases page on a schedule, and record in your runbook who would patch the wiki and how a forced move would be funded if a critical fix never arrives. If you cannot get clear answers, that uncertainty is itself a reason to weigh XWiki or BookStack more heavily.
What implementing each wiki involves
The sequence turns an inventory of Confluence content and permissions into a tested, cut-over wiki with a rollback path that the team has already rehearsed.
Inventory content, permissions and attachments
Export a full picture of the Confluence estate: spaces, page counts, page history needs, attachment sizes, users, groups and space-level permissions. Your team owns the inventory, and DeployOpen or your platform engineers can script the export if that is in the agreed scope. It is done when every space has an owner, a volume figure and a named permission model that can be written down in one table. For XWiki, note that Confluence Migrator Pro moves pages, users, groups, permissions, attachments and metadata, keeps page history but not attachment history, so any attachment history you need must be kept in an archive or accepted as lost before you commit to that path.
Choose the database and SSO path
Decide the database engine and how sign-in will work before any installation. XWiki's official Docker images come in MySQL, PostgreSQL and MariaDB variants, BookStack requires MySQL 8.0 or MariaDB 10.6 or later, and Wiki.js 2.x recommends PostgreSQL 9.5 or later. Confirm which SSO protocol your identity provider supports (OIDC, SAML2, LDAP or an extension) and whether MFA must be enforced per role. XWiki SSO through Active Directory or Azure AD sits in XWiki Pro, so confirm licensing before design. The step closes with a signed-off architecture note that names the database, the identity source and the hosting target.
Build a staging instance and run a representative pilot
Stand up each candidate in a non-production environment, then migrate one representative space that mixes the hardest content: deep page hierarchies, restricted pages, attachments and macros or diagrams. Your administrators run the test with a small set of real users, and the platform team measures page load, search results and permission behavior. For BookStack, check how the books, chapters and shelves map from the source. For Wiki.js, confirm that the Git or storage module fits your backup and review process. The pilot is complete when a written result shows which content types moved cleanly and which need manual rework.
Migrate pages, attachments and permissions
Run the full migration against the agreed scope, with a fixed freeze window and a clear rule on whether edits in Confluence are blocked during the run. For XWiki, the migrator carries pages, users, groups, permissions and attachments, but it does not carry attachment history. For BookStack and Wiki.js, the transfer usually depends on import tooling or scripts that your team or DeployOpen would write and test. Reconcile counts of spaces, pages and attachments against the inventory from step one, and sample permissions on restricted content. The step is done when the reconciliation report shows no unexplained gaps and each exception has an owner.
Validate permissions, search and backups
Test the target against the access model, not just the content. Confirm that view, edit and delete rights hold at space, page and hierarchy level where the design needs them, that search returns expected results, and that backups restore into a clean instance. Include a restore test of the database and attachment store. For Wiki.js, the PostgreSQL search module needs the pg_trgm extension, so confirm it is enabled. The step closes with a signed test log showing each permission case passed or was documented as an accepted difference.
Cut over with a documented rollback
Switch users to the new wiki on an agreed date, redirect links where possible, and keep the Confluence instance read-only for a defined retention period set by your governance team. Write the rollback procedure before cutover: who decides, which backup is restored, how DNS or redirects change back, and how edits made after cutover are reconciled. Rehearse it in staging. The cutover is complete when users can log in through the chosen SSO path, the first support questions are logged, and the rollback runbook is filed with the change record.
Hand over operations and the upgrade cadence
Transfer runbooks, admin credentials, backup schedules and the upgrade plan to the team that will run the wiki. Choose the release line deliberately: XWiki publishes a stable line and LTS lines that receive parallel maintenance, while Wiki.js should stay on the stable 2.x line while 3.0 remains in beta. Record who applies patches and how often each platform is reviewed. The handover is done when the operations owner signs a document listing the release line, patch owner, backup test date and the support route, whether that is internal staff, a retainer or community channels.
Questions teams ask before choosing a self-hosted wiki
How much effort does each wiki take to run after launch?
Effort depends less on the license and more on the stack you already operate. BookStack requires PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 or later, and its official installation scripts cover Ubuntu 26.04, 24.04 and 22.04, so a team comfortable with a LAMP-style stack has a short path. XWiki runs on Tomcat in official MySQL, PostgreSQL or MariaDB images, and it has three release lines (stable, intermediate LTS and LTS) that you must choose between and upgrade along. Wiki.js 2.x is a Node.js application that recommends PostgreSQL 9.5 or later and needs a dedicated domain or subdomain. Ask each vendor or your own platform team to estimate upgrade cadence, backup procedure and monitoring for your chosen database.
Can our team install and operate the wiki without outside help?
Yes for many teams, provided someone owns the database, reverse proxy, TLS, backups and upgrades. BookStack is the simplest to start with because its installation path is documented for common Ubuntu releases, though it publishes no official Docker images and points to community setups such as LinuxServer.io. XWiki's official Docker images make containerized deployment straightforward, but a Java and Tomcat operator must be comfortable with its tuning and upgrades. Wiki.js needs a dedicated domain and at least 1 GB of RAM on Linux. If your team has no one who runs these stacks today, plan for an implementation partner. DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted platforms inside your own infrastructure under a written, fixed scope.
What does outside help cover and how is it priced?
Outside help is usually bought in three pieces: installation and configuration, ongoing support, and training. XWiki SAS lists on-premises professional support, installation and configuration help, training and Confluence to XWiki migration services. Its published consulting rate is 1200 EUR per day, which requires a Business or Enterprise support plan, and its training rate is 1500 EUR per day (XWiki pricing page). BookStack offers paid support plans and sponsorship, and Wiki.js has no comparable published price list in the sources we reviewed, so ask its maintainers directly. DeployOpen does not publish a price list. Request a quote built from a written scope that names the platform, the environment, the integrations and the deliverables.
How long does a migration from Confluence take, and what does it depend on?
No duration is fixed by the research, so treat any timeline as something to confirm for your content. The effort is driven by page count, attachment volume, the number of spaces, how many users and groups must be mapped, and how much permission logic you need to reproduce. Confluence Migrator Pro from XWiki SAS migrates spaces, pages, users, groups, permissions, attachments and metadata, and its trial is limited to 30 pages per migration, which lets you test a sample before committing. Ask each candidate for a dry run on a representative space, a list of what does not map cleanly, and a written plan for cutover and rollback.
Does the Confluence migration tool keep page history and attachments?
It keeps page history but not attachment history. According to the XWiki Store listing for Confluence Migrator Pro, the tool migrates spaces, pages, users, groups, permissions, attachments and metadata, retains page history, and does not carry over attachment history. If your compliance or legal teams need every prior attachment version, plan an export of those versions to a separate archive before cutover. Confirm this behavior against the current extension documentation and a test migration, since the tool's licensing starts at 2000 EUR according to the same listing.
Should we deploy Wiki.js 3.0 now that it is still in beta?
Not for production. The main requarks/wiki repository holds Wiki.js 3.0, which its README marks as beta and not for production use. The stable line is the 2.x series in the requarks/wiki-v2 repository, where v2.5.316 was published on October 2, 2026. Choose 2.x if you pick Wiki.js, and watch the 3.0 release notes before planning any move. Ask the maintainers what a 2.x to 3.0 upgrade involves, whether data migration is supported and how long 2.x will receive fixes. This maintenance question is the main reason Wiki.js carries more risk than the other two options for a long-lived internal wiki.
When is paid XWiki Pro worth the cost over XWiki Standard?
Pay for XWiki Pro when you need its bundled applications, connectors or SSO integrations, or when you need vendor support with defined response commitments. XWiki Standard is the free open source version. XWiki Pro adds applications such as Active Directory and Azure Active Directory SSO, File Manager, Forum, Polls, Calendar and Diagram, plus connectors for Google Apps, Office365 and OnlyOffice, according to the XWiki Pro page. Subscriptions come in Starter (up to 25 users, cloud only), Basic (up to 1,000 users), Business (up to 10,000 users) and Enterprise (unlimited users), and cloud and on-premises pricing are stated as the same. If you only need a documentation shelf with local accounts, the free path may be enough. Confirm the exact apps in your tier before you commit.
Official sources to read before deciding
Before you commit to a wiki, read the license and release pages yourself, because the facts that matter most here change between releases. Start with the xwiki-platform LICENSE file to confirm the LGPL terms apply to the edition you plan to run, then check the xwiki-platform releases page to see which branch fits your upgrade cadence. XWiki publishes a stable line and LTS lines in parallel, so confirm which one your support plan and internal change process expect. For the official container images, the Docker official image documentation for XWiki explains the MySQL, PostgreSQL and MariaDB variants and the Tomcat runtime.
For BookStack, the installation documentation sets the PHP and database baseline and lists the Ubuntu versions with official install scripts. Read it against your own build standard, since BookStack does not publish official Docker images and you will need to decide whether to accept a community container image. The BookStack GitHub releases page shows the current release cadence, which you should compare with your patch window before choosing. Confirm the OIDC, SAML2 and LDAP settings and the role-based permission model in your own test instance, not only on the marketing page.
For Wiki.js, the Wiki.js requirements documentation covers the supported databases, the dedicated domain requirement and the memory baseline, and the requarks/wiki-v2 releases page shows the stable 2.x line you would deploy today. Open the main requarks/wiki repository and read the 3.0 beta notice yourself, then ask the maintainers or your own engineers what migration path they expect from 2.x. Check the Wiki.js authentication documentation against your identity provider, since module availability decides how much SSO work your team takes on.
How DeployOpen helps choose and implement a self-hosted wiki
DeployOpen plans, implements and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, so the choice between XWiki, BookStack and Wiki.js is tested against your real content and permission model. We start from the written scope and work through the decision with your team before any installation begins.
How we scope
- Inventory your Confluence or existing wiki spaces, page counts, attachments and who needs which rights.
- Confirm which SSO protocol, directory and multi-factor method your identity team requires for the wiki.
- Agree in writing which platform, edition and hosting model the engagement covers before work starts.
How we build
- Install the chosen wiki in your environment with the database engine your standards already support.
- Configure SSO, directory sync, roles and page or space permissions, then test them with named sample users.
- Run a content migration trial on a sample of pages, then review structure, history and attachments with your owners.
How we hand over
- Document the installation, configuration, permission model and backup and restore steps for your operators.
- Deliver runbooks covering upgrade paths, including how the release branch you chose is kept patched.
- Walk your administrators and content owners through editing, permissions and daily administration in a working session.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Re-check release lines and licensing changes against your scope when a new version or edition is announced.
- Confirm with the vendor any feature, edition or migration limit that matters to your environment before committing.
