A wiki that is also an application platform
XWiki is a Java wiki for documentation, team spaces and knowledge bases, licensed under the LGPL 2.1. Pages can hold structured data, scripts and macros, and the extension manager adds applications such as blogs, diagrams, authenticators and structured apps built with App Within Minutes. That flexibility is why teams choose it, and it is also why a deployment needs rules about who may install extensions and write scripts.
Projects often start from one of two places. One is Atlassian's Data Center end of life, which includes Confluence Data Center. The other is a sovereign workplace program such as openDesk, where XWiki is the knowledge management component. Both lead to the same questions: where content lives, who can see it, and what happens to pages that relied on Confluence macros.
Atlassian dates that affect Confluence Data Center
Dates from Atlassian's Data Center end-of-life page. The same schedule applies to Jira Software, Jira Service Management and Crowd Data Center.
| Date | Change | What it means for a migration plan |
|---|---|---|
| March 30, 2026 | New customers can no longer buy Data Center subscriptions or new Marketplace Data Center apps. | Already in effect. Existing customers can still buy subscriptions and expansions until the next date. |
| March 30, 2028 | Existing customers can no longer buy new subscriptions, expansions or Marketplace Data Center apps. | Adding users to Confluence Data Center stops being possible. Finish the macro inventory and pilot well before this point. |
| March 28, 2029 | End of life for the affected Data Center products. | Have content moved, old links redirected and the previous instance archived before this date. |
Components to plan
A standard XWiki installation is one Java web application with a database, a search index and a permanent directory.
Servlet container
XWiki runs as a web application in a servlet container such as Tomcat. Recent releases target current Java and Tomcat versions, so check the installation guide for your release. Official Docker images pair XWiki and Tomcat with a database variant.
Database
PostgreSQL, MySQL and MariaDB each have official Docker image variants. The database holds pages, page history, users and rights, so it sits at the center of every backup and restore test.
Search
XWiki uses Solr for search and for internal indexes such as events. Solr runs embedded by default. A standalone Solr helps under heavy search load and is required for a cluster.
Permanent directory
Holds installed extensions, caches, embedded Solr data and, with file-based storage, attachments. Put it on persistent storage and include it in backups with the database.
Govern extensions and scripting
XWiki pages can run Velocity and Groovy scripts. Script and programming rights decide who may author them, and programming rights give code broad access to the wiki and the server process. Keep programming rights to a small administrator group, review the pages that use them, and audit rights after every import.
The extension manager installs from extensions.xwiki.org by default. Decide who may install extensions, keep an approved list with versions and owners, and test each one against your LTS release. On an isolated network, plan how approved extensions and their dependencies reach the instance, because the extension manager cannot reach the public repository.
XWiki publishes security advisories. Subscribe to them, keep the instance on a current LTS patch release, and record which advisories you have reviewed.
Move from Confluence in stages
List spaces, owners, page counts, attachment volume, permission schemes and every macro in use, including Marketplace macros. Mark each space as active, archive or retire. Spaces with no owner and no recent edits are candidates for an archive export.
XWiki provides a free, open source Confluence XML importer. XWiki SAS also sells a Confluence Migration Toolkit with a dedicated migrator and a license for Confluence-compatible macros, which adds imports of several spaces in one run, permissions and an import report. Compare both against your own export during the pilot.
Confluence macros without an XWiki equivalent arrive as placeholders or unrendered markup. For each one, replace it with an XWiki macro, use a compatibility macro, write a bridge macro or convert the content. Marketplace macros need their own decision, since their data may not be in the export.
Import a few representative spaces and ask owners to check layout, attachments, links and permissions. Fix mappings and rerun. XWiki's Confluence URL mapping extension can redirect old page links. Freeze edits for the final import, then set Confluence read-only and archive it.
Connect identity and rights
Rights in XWiki inherit from wiki to space to page. Keep the model shallow so it can be reviewed.
| Area | Approach | Check |
|---|---|---|
| Authentication | Use the OpenID Connect authenticator extension with your identity provider, or the LDAP authenticator for directory login. | A test user signs in through SSO and arrives with the expected groups. |
| Groups | Map identity provider or directory groups to XWiki groups that hold rights. | Removing someone from a directory group removes their access at the next login or sync. |
| Rights model | Grant rights at wiki and space level and keep page-level exceptions rare. Review imported Confluence permissions after each import. | A non-member cannot reach a restricted space through search, links or the REST API. |
| Guest access | Decide whether any space is public. For an internal wiki, deny guest view by default. | A browser without a session sees only the login page or the intended public spaces. |
Availability, backup and upgrades
A single application node with a tested restore suits many teams. XWiki also documents a cluster mode: nodes share one database and one standalone Solr, exchange events over JGroups, and need shared storage for file-based attachments. It adds moving parts, so choose it for an availability or load requirement you can name.
Back up the database, the permanent directory and configuration files (xwiki.cfg, xwiki.properties and the servlet container settings) at a consistent point. A restore test should open pages with attachments, find recent content through search and confirm that restricted spaces stay restricted.
XWiki recommends its cycle LTS release for production, with newer stable releases for teams that want features sooner. Plan upgrades from LTS to LTS, read the release notes for each step, and test extensions on a copy of production first.
XWiki operating ownership
The platform team runs XWiki. Space owners keep content current and decide who can see it.
Platform
- Monitor JVM memory, database health, Solr indexing and response time.
- Apply LTS patch releases and security fixes.
- Keep the permanent directory on persistent storage.
Space owners
- Review space membership on a fixed schedule.
- Archive spaces that no longer have an owner.
- Report pages with broken macros left from the migration.
Security
- Limit programming rights to named administrators.
- Approve extensions before installation.
- Review XWiki security advisories as they are published.
Change record
- Record extensions, versions and configuration changes.
- Keep the macro mapping decisions from the migration.
- Note the date and result of the last restore test.
XWiki questions
Will Confluence pages look the same after import?
Text, headings, tables and attachments are the parts the importers handle directly. Pages built on Marketplace macros or custom layouts need mapping, and the pilot shows which spaces need rework.
Is the free importer enough?
It can be for estates with few custom macros. The commercial toolkit from XWiki SAS adds multi-space imports, permissions and compatibility macros. Test both on your own export before deciding.
Can XWiki edit office attachments in the browser?
XWiki can integrate with Collabora Online, as it does in openDesk. Size and operate Collabora as its own service.
Can it run without internet access?
Yes, with planning. Install from mirrored packages or images and bring approved extensions in through an internal repository or offline packages.
Scope and handover
DeployOpen plans the topology, deploys XWiki in your infrastructure, integrates SSO, sets up search, backup and monitoring, and runs the Confluence migration pilot with your space owners. The work changes with the number of spaces, attachment volume, macro inventory, rights complexity, extension set and availability target.
Handover records versions and the LTS upgrade path, database and Solr setup, the permanent directory location, SSO and group mapping, approved extensions, macro mapping decisions, backup and restore results, URL redirects from Confluence and the support route.
