XWiki vs Confluence: What to Know Before Leaving Data Center

TL;DR

• Both are wikis. XWiki is open source and runs on your own servers. Confluence is closed source and is moving to cloud only.
• XWiki is the closest feature match to Confluence, but it asks more of your infrastructure team, and its editor is a step down for people who write occasionally.
• Running XWiki yourself costs nothing in license fees. But once you start paying XWiki for support, the price gets much closer to Confluence than you'd expect.

Think about the person who made the call on Confluence Data Center back in 2019. They didn't choose it because it was affordable or because the editor was pleasant to use. They chose it because legal said company documentation couldn't sit on somebody else's servers, and Data Center was the version that let them satisfy that.

Seven years later, Atlassian reversed that decision for them. New Data Center licenses stopped being sold on March 30, 2026. Existing customers lose the ability to expand their licenses on March 30, 2028. And on March 28, 2029, every Data Center instance goes read only. Your team can still read the wiki, they just can't write to it anymore. If you want the full timeline, we've covered that in our guide to the Confluence Data Center end of life.

Now, the compliance requirement hasn't changed. Legal still doesn't want company documentation to sit on somebody else's servers. But the tool that satisfied it is going away. That's the reason most teams are here. They want to know whether XWiki is the answer.

Sometimes it is. Here's how to tell.

XWiki vs Confluence

What XWiki does well

XWiki has been in continuous development since 2004, and that maturity shows up when you're replacing an enterprise wiki.

Permission control at three levels

You can set access at the page level, the space level, and the wiki level. XWiki also lets you block access outright, rather than only granting it. Picture one person on a ten-person team who shouldn't see a single page. If a wiki can only grant access, your only option is to unpick the whole team's permissions and rebuild them around that one exception. A deny rule handles it in a single step.

If your Confluence instance has been running for six years, your permission structure has probably grown into something complex. Most platforms force you to simplify it during a migration, which means somebody has to make judgment calls about who loses access to what. XWiki is one of the few options that can represent a complex permission structure without flattening it first.

Multiple isolated wikis from one installation

XWiki supports real multi-tenancy. A single installation can host several separate wikis, each with its own users, its own permissions, and its own branding, and none of them can see the others.

That's useful if you're a consulting firm keeping client work separated, or a large organization with business units that aren't supposed to read each other's documentation. With most platforms you'd solve this by running several installations and maintaining all of them. But here, it's built into how the product works.

Authentication: free basics, paid enterprise

Generic LDAP works in the free community edition, and there's a free OpenID Connect authenticator if you want basic single sign-on. That's already more than Confluence gives you, since it has no free SSO path at all above the 10-user tier.

On higher tiers, the Active Directory management app, Microsoft Entra ID connector, and enterprise SAML come as paid extensions, or arrive bundled once you're on a support plan. So if your organization runs Entra ID and expects SAML, budget for it on both sides rather than assuming open source means free.

The core is free, the add-ons aren't always

The community edition of XWiki is licensed under the LGPL. It's free, for unlimited users, forever, with no seat count that triggers a bill.

Confluence has nothing comparable. There's a free tier, but it stops at 10 users, and above that you're paying per person every month with no unpaid path back.

That advantage is the foundation of most of the cost arguments you'll read about XWiki. It also needs testing, because the version most organizations end up buying isn't the free one.

What XWiki costs once you add support

Running an enterprise wiki with no vendor support behind it works for some teams and not for others. If your documentation is business critical, somebody will want to know who's accountable when something goes wrong, and "our own team" isn't always an acceptable answer. That's where XWiki's commercial subscriptions come in, and that's where the free version stops being the one you're comparing.

The commercial tiers are priced by user count

XWiki SAS sells paid subscriptions in user bands, which is the same basic model Confluence uses. You're buying support and tooling rather than the software itself, but you still pay more as your team grows.

Unusually, the largest tier costs the most per person.

• Basic: about €4.69 per user per month at 100 users
• Business: €3.63 per user per month at 250 users
• Enterprise: €5.50 per user per month at 500 users

A team growing from 250 to 500 moves from Business up to Enterprise, and its cost per user climbs by about half.

Annual cost at 100, 250, and 500 users

From the table, two things stand out.

• At 250 users, XWiki costs about a third less than Confluence Standard.
• At 500 users, that saving is gone. XWiki Enterprise and Confluence Standard cost roughly the same.

But the two columns aren't measuring quite the same thing:

• The XWiki prices are in euros and the Confluence prices are in dollars. Convert at whatever rate applies to you.
• XWiki publishes its prices as annual totals, while the Confluence figures are calculated from the monthly rate over twelve months, so if you're billed annually, check your own rate against these.
• XWiki Enterprise and Confluence Standard aren't the same product. The table shows what each one costs, not what you get for the money.
• The Confluence figures leave out Marketplace apps, which many teams depend on and which carry their own per-user fees.
• The XWiki figures leave out servers and the staff hours to run them, which we come to further down.

The large savings people associate with XWiki come from running the self-hosted community edition. Once you buy commercial support at enterprise scale, you're choosing XWiki for control and openness, not to save money. Both are fine reasons, but you need to know which one is driving your decision.

The editor is your adoption risk

XWiki uses CKEditor, which handles everything an enterprise editor should handle. But if your team has spent years inside Confluence, the writing experience is an adjustment. The interface is denser, formatting behaves differently, and you can also write pages in plain text markup instead of using the visual editor, the way Markdown works. Some people much prefer that, though most will never open it.

The risk is that this doesn't show up at launch. The migration completes, everybody says it went well, and then six months later half the team has quietly drifted back to email attachments and shared drives, because writing in the new tool feels like a whole new job.

You can't fix that after the fact. You can only catch it early.

So before you commit, put XWiki in front of the people who write least often. Not your infrastructure team. They'll be fine, and their opinion won't predict anything.

Test it with:

• The HR manager who updates the policy pages a few times a quarter
• The support lead who maintains the runbooks your team depends on
• Anyone who edits once a month and forgets the interface in between

These are the people who never build up muscle memory. Every visit is their first visit, so if anything is confusing they'll stop using it.

If they push back, that's your migration risk showing up early, and finding out during evaluation costs far less than finding out a year after migration.

What running XWiki looks like

The stack underneath

XWiki is a Java application. It runs on an application server like Tomcat or Jetty, stores content in a relational database, and runs Solr to power search. Docker images exist and they smooth out the setup, but they don't change the shape of what you're running.

Who maintains it day to day

Somebody on your team needs to own JVM tuning, keeping the search index healthy, upgrade testing, and backup verification.

If you already run Java applications in production, none of this is new, and you'll be fine. But if your team works mostly with containers and managed databases, you're picking up a stack you don't currently support, and that cost needs to be calculated too.

What self-hosting means either way

Whichever platform you land on, self-hosting comes with the same basic structure:

1. Your data never leaves infrastructure you control.
2. You define your own compliance posture, including access controls, encryption, and retention, instead of inheriting a vendor's.
3. Hosting, backups, upgrades, and security patching become your IT team's responsibility.

What happens to your Confluence macros

Your Confluence pages are full of macros: code blocks, panels, status badges, tables of contents, page trees, plus whatever extra ones the Marketplace apps you installed have added over the years.

XWiki's migration toolkit includes bridge macros that reproduce how the most common Confluence macros behave, so a good portion of your content will render correctly without anyone touching it.

What it doesn't cover:

• Macros from third-party Marketplace apps
• Custom macros your team wrote and forgot about
• Anything unusual or heavily customized

Each of those has to be rebuilt or removed. How big that job is depends entirely on what's in your wiki, so nobody can tell you from the outside.

Audit before you commit

Two steps:

• Export a list of every macro in use across all your spaces
• Count how many fall outside the standard Confluence set

If it's a handful, migration is a weekend of cleanup. But if your team built workflows on top of Marketplace apps, it's a whole separate project.

Do you need an application platform?

XWiki has a structured data model, a scripting API, and a form builder that lets people who don't write code assemble small applications inside the wiki itself.

Some organizations choose XWiki for exactly this. If you want your asset register, onboarding checklists, and documentation living in one system, XWiki can do that and most wikis can't.

For everyone else, it's extra product you inherit and never touch, so there's more to configure and secure, and a heavier upgrade path because there's simply more of it.

So if all your team needs is somewhere to write things down and find them again later, ask whether the application platform is a feature you'll use or a cost you'll carry.

If neither XWiki nor Confluence fits

You need self-hosting, but you don't want to run a Java stack, and you don't want to hand your team an application platform to operate when what you asked for was a wiki.

That's where Docmost fits. It's open source under AGPL-3.0, it self-hosts on infrastructure you control, and it deploys with Docker Compose rather than an application server. The editor is modern and collaboration happens in real time. Email and password login is built in, which means nobody has to stand up an identity provider before your team can sign in for the first time.

For teams coming off Confluence specifically, Docmost includes a Confluence importer.

If you want the detailed feature-by-feature view, we keep those on dedicated pages: Docmost vs XWiki and Docmost vs Confluence.

Which one fits your team

Choose XWiki if

• Your permission structure is complicated and can't reasonably be simplified
• You need several isolated wikis running from one installation
• You have people who are comfortable operating Java applications in production
• You'll use the structured application features rather than just carrying them
• You're planning to run the community edition and support it yourself, where the cost advantage is largest

Stay on Confluence Cloud if

• Self-hosting was never a hard requirement, just a preference
• Your team lives inside Jira and Bitbucket, and losing that connection would break how you work
• You can afford the per-user cost at your team size

If that's you, we compare the two deployment options in Confluence Cloud vs. Data Center.

Look at something lighter if

• You need self-hosting for compliance reasons, yet your team is small
• Your documentation needs are ordinary and always have been
• Nobody is volunteering to take on another Java application

Frequently asked questions

1. Is XWiki hard for non-technical people to use?

It depends on the person and what they've grown used to. XWiki's editor is capable, but teams moving over from Confluence usually report an adjustment period, and it lands harder on occasional contributors than on daily users. Test it with the people who write least often, before you commit to anything.

2. How much work is it to run XWiki?

More than a container you start and forget about. XWiki is a Java application with a search index and a database behind it, so somebody on your team needs to own upgrades, keeping the search index healthy, and backup testing as a standing responsibility. If you already operate Java applications, that's routine work. If you don't, budget for the learning curve.

3. Is Confluence being discontinued?

No. Confluence Cloud continues and Atlassian is still developing it. What's ending is the ability to run Confluence yourself. Server support ended in February 2024, and Data Center goes read only on March 28, 2029.

4. Can you run XWiki in an air-gapped environment?

Yes. XWiki self-hosts on infrastructure you control, including networks with no internet connection at all. You'll need to plan for installing extensions offline and handling upgrades manually, since the Extension Manager normally pulls from an online repository.

5. What happens to my Marketplace apps after 2029?

Data Center Marketplace apps expire alongside the Data Center license, so they stop working on the same date. There's no gradual wind-down and no grace period. Any workflow your team built on top of a Marketplace app needs a replacement plan, and that's true whether you move to Atlassian Cloud or somewhere else entirely.

Keep self-hosting without the Java stack

You can keep your documentation on infrastructure you control without adding a Java application to your team's workload. Try Docmost or talk to our team about what moving off Confluence would involve for your setup.