Confluence vs XWiki: which to choose

Confluence or XWiki: when each option fits

Confluence fits best when your organization wants Atlassian to run the hosting, the patching and the data residency for the wiki, and when the team already works in Jira and depends on the Confluence Marketplace apps that Atlassian and its partners maintain. XWiki fits when you need the code and the data on infrastructure you control, under the LGPL-2.1 license, and when you want documentation modeled as structured data rather than only as pages. Both answers depend on how the wiki is used today, so the first step is an inventory rather than a feature comparison.

XWiki's strongest fit is structured data. Its object model lets teams attach typed fields to pages, such as owner, review date or system identifier, and query them across spaces, which is useful for registers, runbooks and policy libraries that Confluence usually handles through macros and labels. Self-hosting rights mean the platform can run in your data center or a cloud account you already govern, and the official Docker images for MySQL, PostgreSQL and MariaDB give platform teams a standard deployment path. The free core is LGPL-2.1, while support, the Confluence Migrator Pro and consulting are paid services from XWiki SAS, so you should price those separately from the software itself.

The decision turns on three checks. First, list every Marketplace app and macro your spaces depend on, and confirm which of them has an XWiki extension or a rebuild path, because some Confluence apps have no direct equivalent. Second, document where page content, attachments and user data must physically sit under your residency or sector rules. Third, plan the migration path: the Confluence Cloud XML export reaches end of life on December 1, 2026, so confirm which export format your migration tool reads and whether attachment history must survive, since XWiki's migrator keeps page history but not attachment history.

Which option fits which scenario

This table maps common Confluence situations to the option that usually fits better, the reason, and the condition under which the other option wins. Read each row against your own constraints, since the right answer depends on your apps, your sovereignty rules and your admin capacity.

Scenario	Better fit	Reason	Condition where the other option wins
Marketplace-heavy Confluence site with many paid apps	Confluence (stay on Cloud or Data Center for now)	Many Marketplace apps have no XWiki equivalent, so each app needs a replacement, a custom build or a dropped feature before migration	XWiki wins once an inventory shows most apps are unused or covered by XWiki extensions or macros
Data residency or air-gapped requirement	XWiki (self-hosted)	Content and users stay on infrastructure you control, and Docker images and packages can be mirrored offline	Confluence wins only if an approved Atlassian data residency arrangement already meets your rules and no offline network is needed
Team wants structured data and forms	XWiki (self-hosted)	XWiki's data model supports structured objects and custom application building, which suits teams that outgrow flat pages	A team that mainly needs simple pages and Confluence-style macros may find Confluence or a lighter wiki sufficient
Team with no wiki admin capacity	Confluence Cloud (managed by Atlassian)	Atlassian operates the platform, upgrades and backups, which removes routine admin work	XWiki wins if you can fund a support subscription from XWiki SAS or a DeployOpen retainer that covers upgrades and backups
Data Center exit with a fixed deadline	XWiki (plan migration early)	Data Center licenses become read-only on March 28, 2029, so a self-hosted target must be in place well before then	Confluence Cloud remains the choice if your policy accepts cloud hosting and you can meet the December 1, 2026 XML export end of life
Organization needs paid vendor support for the wiki itself	XWiki Pro or support subscription	XWiki SAS offers on-premises professional support and installation help under its published tiers	Confluence fits if your contract with Atlassian already covers the support model you require
Team needs Confluence-style page-level and space-level permissions with minimal setup	Confluence (Cloud)	Permissions are part of the standard product and familiar to most users	XWiki fits when rights must be modeled per object, form or application, which requires confirming the permission model in your own test instance

Where the data lives and who runs the platform

Confluence and XWiki differ mainly in who hosts the data and who operates the platform. The cards below cover the hosting choices, the Data Center timeline, and the identity and compliance work that follows from each choice.

Atlassian Cloud residency scope

Atlassian Cloud data residency keeps page content in a region you choose, but user account data sits outside that scope. For a regulated organization, the residency question is therefore only part of the picture. Ask Atlassian in writing which data categories are covered, where backups and logs are stored, and which sub-processors touch content. Compare those answers with the hosting and access model you would accept for XWiki.

Data Center end of life

Atlassian stopped support for Confluence Server on February 15, 2024, and Data Center licenses expire and become read-only on March 28, 2029. Atlassian has also set a date after which new Data Center purchases and expansions end. Plan the move on a timeline that fits your renewal calendar, not on the expiry date. Any content you still need after March 2029 must already be in a platform you control.

Self-hosting XWiki in your environment

XWiki is licensed under LGPL 2.1 and can run in your own cloud account, data center or disconnected network, using the official Docker images for MySQL, PostgreSQL or MariaDB. Your team then owns the database, backups, TLS, patching and access logs. Confirm which database, Tomcat and Java versions match your support policy, and assign a named owner for upgrades between the stable, LTS and intermediate LTS lines.

XWiki SAS hosting and support

XWiki SAS, the company behind XWiki, offers XWiki Cloud hosting on ISO 27001 certified infrastructure, along with on-premises support and training. This moves operations to a vendor while the software stays open source, so the contract matters more than the license. Ask for the certificate scope, the data processing terms, the locations of hosting and support staff, and the exit procedure for returning your content.

Identity and compliance evidence

Whichever hosting model you choose, your auditor will ask how users sign in, how access is reviewed and how changes are logged. Confluence relies on Atlassian's own compliance reports for its cloud service, while a self-hosted XWiki puts that evidence in your hands. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those decisions.

What the LGPL core and XWiki Pro each include

XWiki Standard is the free, open source version of XWiki, licensed under the LGPL 2.1. The current stable release line is xwiki-platform 18.4.7, published October 15, 2026, and the official Docker images are available in MySQL, PostgreSQL and MariaDB variants running on Tomcat. Using the core software does not require a license fee, but your organization still pays for the servers, database, storage, backups, upgrades and the staff who run them.

Core wiki features: Spaces, page trees, wiki pages, attachments, and the structured data and scripting model that XWiki is known for are part of the free core.
Deployment choice: You can run the official images or package builds in your own cloud account, data center or air-gapped network.
Release lines: XWiki publishes a stable line and LTS lines, so you can choose the cadence that matches your change control.
Self-supported operation: Without a support subscription, your team handles installation, patching, backup testing and troubleshooting, using public documentation and community channels.
Confluence import: The open-source Confluence XML filter stream is part of the open source base, while the packaged migrator is a paid extension.

Before you commit, confirm which release line fits your upgrade policy and which components you will need to test in your own environment.

What the Confluence migration to XWiki involves

The migration starts with choosing between two routes. The first is XWiki's Confluence Migrator Pro, a paid extension from XWiki SAS that reads XML and CSV backups from Confluence Server, Data Center and Cloud and carries across pages, spaces, attachments, permissions, blog posts, and users and groups. It keeps page history but does not keep attachment history, so anyone who relies on attachment versions must plan to archive them separately. The extension is priced from 2000 EUR, and its trial is limited to 30 pages per migration, which makes it useful as a rehearsal on a representative sample before committing. Confirm the current price and licence terms with XWiki SAS in writing. The second route is the open-source Confluence XML filter stream, the component the Migrator Pro is built on. It costs nothing to license, but your team or a services partner carries the mapping, scripting and error handling that the paid extension provides.

The end of XML export support changes the input decision. Atlassian's support for Confluence Cloud XML site and space export ends on December 1, 2026, after which the features still work but Atlassian will no longer fix bugs or accept tickets for them and recommends CSV export instead. Because the Migrator Pro reads both XML and CSV, a team that starts now should export in the format it expects to rely on and run a full test import before that date. Whatever the route, check by hand after import: macro output in XWiki (Confluence macros rarely map one to one, so inspect each space that uses them), page-level and space-level permissions against the source, group membership, internal links, and attachment version history, which will be missing. Record the results in a sign-off checklist per space so that auditors and content owners can see what was verified.

What drives the cost of each option

The cost of moving from Confluence to XWiki is split across several components, each paid to a different party and each recurring on a different schedule. Separating them lets you compare a Confluence subscription with a self-hosted XWiki deployment on equal terms.

Confluence subscription

This is the recurring fee you pay Atlassian, and its basis depends on your edition and deployment, including Cloud or Data Center. Confluence subscription prices are not part of the facts supplied for this page, so get the current figure from Atlassian's price list or your reseller quote. Data Center subscriptions have a fixed end date, so ask whether your renewal term runs past the point where new Data Center subscriptions stop. Include any Marketplace app fees in the baseline, since those often sit outside the core license.

XWiki software license

XWiki Standard is free and licensed under LGPL-2.1, so there is no per-user software fee for the core platform. Its official Docker images are also LGPL-2.1 and come in MySQL, PostgreSQL and MariaDB variants. The cost to check is which line you run: stable, long term support or intermediate LTS. Each line has its own upgrade cadence, which affects how often your team spends time on upgrades. Software cost is therefore close to zero, but it is not the whole cost.

Optional XWiki SAS support

Support subscriptions from XWiki SAS are optional and are priced by user tier, with Starter, Basic, Business and Enterprise levels. XWiki SAS states that cloud and on-premises pricing is the same, so the tier, not the hosting location, drives the fee. Ask which tier matches your user count and whether it includes the connectors and SSO applications you need. Support is recurring, and it is the main variable cost on the XWiki side.

Consulting and training

Consulting from XWiki SAS is listed at 1200 EUR per day and requires a Business or Enterprise support plan. Training is listed at 1500 EUR per day. These are one-time or occasional costs tied to days of work, not a recurring fee. Ask for a written scope that names deliverables, such as the permission model, macro replacement and SSO setup, so that day counts can be checked against the work.

Confluence migrator

Confluence Migrator Pro from XWiki SAS is a one-time purchase for the migration itself, priced from 2000 EUR, and the trial is limited to 30 pages per migration. The open-source Confluence XML filter is the component it builds on, so you can plan a migration without the paid extension, but with more manual work. Ask whether the quote covers Confluence Cloud CSV or XML input and whether it includes a second test run, since attachment history is not preserved.

Hosting and internal admin time

Hosting covers the servers or cloud accounts, database, storage, backups and monitoring that run XWiki in your environment, plus the staff time to patch Tomcat, the database and XWiki itself. These costs recur every month and rise with user count, data volume and the number of environments you keep. Ask your infrastructure team for the monthly hosting and backup figures, and ask the XWiki partner whether the quote includes upgrade and backup runbooks.

How a move from Confluence to XWiki proceeds

The sequence turns an inventory of Confluence content into a tested XWiki instance, a verified trial migration and a controlled cutover. Each step ends with a check that the client's own admins and decision owners can sign off before the next one starts.

Inventory spaces, apps and macros
Your Confluence admins list every space, its owner, page count, attachment volume, blog posts, user and group permissions, and every Marketplace app and macro in use. Most of the risk sits in the macros and apps, so this list also records which ones have an XWiki equivalent, which need rework, and which have no match. The output is a signed inventory that decision owners review and approve, with the gap list as the basis for scope.
Choose the export format and deadline
Confirm your Confluence edition, because Cloud, Data Center and Server offer different export routes. Check the XML export end of life date of December 1, 2026 in Atlassian's support notes, and decide whether to use XML or CSV backups as the input to XWiki's migrator or its open-source Confluence XML filter. Record the chosen format, the export owner and the date the export was taken, so the trial and final runs use the same source.
Stand up a test XWiki from official images
Your platform team deploys a non-production XWiki from the official Docker images, choosing the MySQL, PostgreSQL or MariaDB variant, each running on Tomcat. Pick a stable, LTS or intermediate LTS tag according to your upgrade policy and document the choice. The check is a running instance behind your identity and TLS standards, with backups of its database and attachment storage configured before any content is loaded.
Run a trial migration
Load a representative subset of spaces into the test instance using the chosen migrator, either XWiki's paid Confluence Migrator Pro or the open-source XML filter that it builds on. Expect a trial to be limited, so confirm the page allowance and licensing terms with XWiki SAS before you start. Log the import errors, skipped items and warnings. The step closes when a written trial report lists what migrated, what failed and what needs manual rework.
Verify permissions, macros and links
Test a sample of pages against the permissions in the source: space admins, restricted pages, groups and anonymous access. Check each macro and Marketplace app replacement, internal links, page trees and attachments, and confirm that page history was kept while attachment history was not. Business owners sign off on each functional area. The step is complete when the test list shows a pass or a documented workaround for every item in the gap list.
Plan cutover and user communication
Agree a freeze window for Confluence edits, a final export, a final import into production XWiki and a rollback plan in case the import fails. Prepare user guidance on new URLs, sign-in, editor differences and where to find archived content. Confirm the cutover plan with your decision owners, security team and compliance lead. The output is an approved runbook, with named owners for each action and a go or no-go checkpoint.
Cut over and decommission the old wiki
Run the final export and import on the agreed date, repeat the permission and link checks on production, and switch users to XWiki. Keep the Confluence instance read-only for a period your records and retention rules require, then retire it and remove its data according to your data handling policy. The step closes with a documented cutover record, retained export archives and a decommission certificate signed by the system owner.

Questions buyers ask before choosing XWiki over Confluence

What drives the cost difference between Confluence and self-hosted XWiki?

The cost difference depends on what you pay Atlassian today, what you pay for hosting and administration, and whether you buy XWiki SAS support. XWiki Standard is free and open source under LGPL 2.1, so the license line is zero, but you still pay for servers or a cloud account, database operations, backups, upgrades and the staff time to run them. Optional costs include XWiki SAS support subscriptions, on-premises professional support, training and the paid Confluence Migrator Pro, which XWiki SAS lists from 2000 EUR. Ask any vendor or partner for a quote that separates one-time migration work from recurring hosting, support and administration, and ask for the assumed user count, since XWiki's support tiers are sized by users.

How long does a Confluence to XWiki migration take?

No supplied source gives a fixed duration, so treat any timeline as something to agree in writing before work starts. The main drivers are the number of spaces, pages, attachments and users, how many permission schemes you need to map, whether you migrate from a Server, Data Center or Cloud backup, and how much page history and attachment history matters to you. XML site export reaches end of life on December 1, 2026, so the export format you choose can change the work. Migration tooling also needs a test pass on a copy, and that test cycle usually takes longer than the import itself.

Can our own team migrate Confluence to XWiki without outside help?

Yes, a team with Linux, database and Tomcat experience can install the official XWiki Docker images and try the open-source Confluence XML filter, but the work is still an engineering task. The paid Confluence Migrator Pro handles spaces, pages, users, groups, permissions, attachments and metadata, and a trial is limited to 30 pages per migration, so you can test your content before you buy. Outside help is most useful for mapping permissions, validating macros, planning cutover and building backup and upgrade routines. Ask for a fixed-scope written plan that names what your staff will do and what the outside team will do.

What work must our staff supply during the migration?

Your staff must supply decisions and checks that no tool can make for you. Space administrators need to confirm which spaces are current and which can be archived, owners must review page content and macros after import, and security or identity staff must define groups and permissions and approve the sign-in method. Testers from each team should check a sample of pages, attachments and links on a staging copy. Plan for an administrator to own the XWiki platform after go-live, covering upgrades, backups and extension updates, and name a sponsor who can approve scope changes.

Does XWiki replace Confluence Marketplace apps?

XWiki covers many core wiki needs, but it does not have a one-to-one equivalent for every Confluence Marketplace app. XWiki Pro lists features such as Active Directory and Azure Active Directory SSO applications, File Manager, Forum, Polls, Calendar, Ideas, Meeting, Diagram, Pro Macros, and Google Apps, Office365 and OnlyOffice connectors, and those are paid offerings. Inventory every Marketplace app your spaces depend on, then check each one against XWiki's extensions catalog and the XWiki Pro list. Any app with no match needs a decision: replace it with a different tool, rebuild the function with macros or scripts, or drop it.

Can self-hosted XWiki run in an air-gapped network?

XWiki can be deployed in a disconnected network because its official Docker images and packages can be installed from an internal copy, but you must plan how images, extensions and updates reach the offline environment. Confirm that every image variant you need (MySQL, PostgreSQL or MariaDB on Tomcat, for amd64 or arm64v8) and every extension you rely on is mirrored into your internal registry or repository before cutover. Updates then follow your own change process, with a staging instance used to test each new release. Ask your implementation partner to document the transfer path and the approval steps for each update.

How DeployOpen helps evaluate and implement XWiki

DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Confluence vs XWiki, we help teams test the migration assumptions on this page against their own spaces, permissions and macros before committing to a target.

How we scope

We inventory spaces, page trees, macros, Marketplace apps and permission schemes actually in use at your site.
We map each Confluence feature to an XWiki capability and mark gaps that need a workaround or a decision.
Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.

How we build

We deploy XWiki in your cloud account, data center or air-gapped network, using the Docker images or packages you choose.
We configure authentication, groups and permissions against your identity provider and test access rules by role.
We run a trial migration on a representative subset of spaces and check page history, attachments and users.

How we hand over

We document the target architecture, backup and restore steps, upgrade procedure and the list of known migration gaps.
We provide a record of which Confluence content moved, which was rewritten by hand and which was retired.
We train administrators on space, group and extension management so the team can run the wiki after handover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
We can plan upgrades across XWiki release lines and test extensions before they reach production.
Ask us to confirm which parts of the scope, such as extension licensing or XWiki SAS support, fall outside our work.

Confluence vs XWiki