XWiki vs MediaWiki: which to choose

Which wiki fits your internal documentation: XWiki or MediaWiki

If your team needs fine-grained rights, structured data inside pages and a paid path to SSO and enterprise apps, XWiki is usually the better fit for internal documentation. If your content is mostly free-form articles, your team already runs PHP well, and you are comfortable wiring identity through extensions, MediaWiki is the more natural choice. Both are self-hosted, both are open source, and both can run an internal knowledge base, but they reward different operating skills and different governance needs. Choose XWiki when permissions must be set at wiki, page or hierarchy level, when pages carry structured fields that other pages query, or when your Java operations team can keep a Tomcat-based application current. XWiki is licensed under the LGPL 2.1, and its release model runs several branches in parallel, including a long term support line, so you can match an upgrade cadence to your change calendar. Choose MediaWiki when the content is article-shaped, when you want the engine with the largest documentation community behind it, and when your PHP team can follow its lifecycle. MediaWiki's current stable line is 1.46, while 1.43 is the LTS release supported until December 2027, so confirm which line you will run before you commit. The decision turns on four questions. First, how granular must read and edit rights be, and will auditors ask for proof of them? Second, how much structured data does the content need to hold? Third, which SSO protocol your identity provider requires, and whether that support sits in a free extension, a paid edition or a plugin you will maintain yourself. Fourth, whether your team's strengths lie in PHP or Java. Write those four answers down before you request a quote, because they determine the extensions, hosting and support plan you will need.

Which scenario points to XWiki and which to MediaWiki

This table maps common internal documentation scenarios to the platform that usually fits better and the condition that makes it so. Read each row as a starting hypothesis, then confirm the capability named in the reason against current vendor documentation and a test instance before you commit.

Scenario	Better fit	Reason and condition
Per-page or hierarchy-level access restrictions	XWiki	XWiki documents view, comment, edit and delete rights at wiki, page or hierarchy level. MediaWiki can restrict access through extensions, so confirm the exact granularity you need in its documentation.
Structured records such as runbooks or application catalogs	XWiki	XWiki's structured data model suits records with consistent fields that people search and report on. MediaWiki works well for free-text pages, but structured records usually rely on templates and extensions that you must validate and maintain.
Public-style knowledge base with open contribution	MediaWiki	MediaWiki is the engine behind Wikipedia and is built for large, open editing communities. This holds if your readers and editors are broad; a small internal team gains little from that model.
Confluence-style spaces and page trees	XWiki	Spaces and hierarchies map well to Confluence habits, and XWiki SAS offers a Confluence migration path. Confirm which Confluence content types, history and permissions the migration tool carries over before planning.
Java-based estate with existing application servers and Tomcat operations	XWiki	XWiki's official Docker images run on Tomcat with MySQL, PostgreSQL or MariaDB variants, which fits teams already operating Java services. Teams standardized on PHP may find MediaWiki easier to operate.
PHP-based estate with existing LAMP or LEMP operations	MediaWiki	MediaWiki requires PHP 8.3.0 or later and supports MariaDB, MySQL, PostgreSQL and SQLite. This fits teams with PHP skills, but confirm your web server and database versions against the installation requirements.
Team already running MediaWiki with many extensions	MediaWiki	Migration costs and template knowledge usually outweigh the structural benefits of XWiki. Check each extension's compatibility with your target MediaWiki version before any move.
Single sign-on across the estate	Depends on configuration	MediaWiki supports external login through the PluggableAuth extension with OpenID Connect, SAML, LDAP and other plugins. XWiki SSO depends on extensions, and XWiki Pro lists Active Directory and Azure Active Directory SSO applications, so confirm the protocol and edition you need.

How XWiki and MediaWiki are built and what that means for operations

Both engines are mature, self-hosted wikis, but they sit on different runtimes, database families and release rhythms. The cards below cover the components you will patch, the version floors you must meet, and the hosting choices that follow from them.

XWiki runs on Java and Tomcat

XWiki ships as official Docker images that run on Tomcat, with MySQL, PostgreSQL or MariaDB variants for amd64 and arm64v8. Your team patches the image tag, the database and the Java layer together, so the image is the unit you test and roll back. Confirm which Java runtime each image tag bundles and how your change control treats a base image update.

Pick the XWiki release line deliberately

XWiki maintains a stable line, an intermediate LTS line and an LTS line in parallel, so an upgrade is a choice of track as well as a version. The stable tag at research time was 18.8.0, the intermediate LTS was 18.4.7 and the LTS was 17.10.14. Decide which line you will stay on before you build, because moving between tracks is a planned migration rather than a routine patch.

MediaWiki runs on PHP with a web server

MediaWiki is a PHP application that Apache HTTPD or Nginx serves through a compatible PHP version, so your web tier and PHP runtime are part of the platform you maintain. The latest stable release requires at least PHP 8.3.0. Check that your distribution's PHP packages reach that floor and that they receive security fixes, since a stale PHP package can block a MediaWiki upgrade.

Database families differ by engine

XWiki's images cover MySQL, PostgreSQL and MariaDB, so the database choice is largely set at image build time. MediaWiki supports MariaDB 10.3+, MySQL 5.7+, PostgreSQL 10+ and SQLite 3.31+, and recommends MariaDB or MySQL because Wikimedia runs MariaDB. Pick the engine your backup tooling and DBA team already support, then confirm the exact version floors with each vendor before you commit.

MediaWiki upgrades follow LTS windows

MediaWiki publishes an LTS release about every two years and supports upgrades from up to two LTS releases back. Version 1.43 is the LTS and is supported until December 2027, while 1.46 is the current stable line that ends in July 2027. Plan your upgrade path around the LTS calendar, and check the lifecycle page for the exact support dates before you schedule a window.

Hosting ownership shapes the patch cycle

In a self-hosted deployment, your team or your implementation partner owns OS patches, PHP or Java updates, database minor versions and backups for either engine. XWiki's container model lets you redeploy a pinned image quickly, while MediaWiki changes often touch PHP, extensions and the database together. Ask who signs off each layer, how extension compatibility is tested before an upgrade, and where rollback snapshots are kept.

How SSO and permissions work in each wiki

Access control is where XWiki and MediaWiki differ most, so the decision starts here: XWiki sets rights in the wiki itself, while MediaWiki hands identity to an extension and keeps its permission model deliberately simple. XWiki grants view, comment, edit and delete rights at wiki, page or hierarchy level, and it keeps every page change under version control, so a reviewer can trace who changed a page and restore an earlier version. MediaWiki's core permissions are assigned to user groups, and deeper control depends on extensions you choose and test. Map your existing spaces to these levels before you pick a platform, because a page tree that needs different editors per branch will shape the rest of the configuration.

For single sign-on, XWiki's paid Pro package lists Active Directory and Azure Active Directory SSO applications, and the xwiki-contrib project publishes open source OIDC work that you should review and test against your own identity provider before relying on it. MediaWiki uses PluggableAuth as a framework for external login, with plugins for OpenID Connect, SAML through SimpleSAMLphp, LDAP through LDAPAuthentication2, OAuth and REMOTE_USER. PluggableAuth 7.x requires MediaWiki 1.40 or later, so confirm that version in your upgrade plan. Each plugin handles login differently, so check how it creates accounts, where it reads groups, and whether group changes in the directory reach the wiki at sign-in or only when a user is created.

Group mapping and permission sync are the main risks in either platform. Ask each vendor or extension maintainer how group membership maps to wiki roles, whether removed users lose access immediately or at next login, and how the integration behaves when the directory is unreachable. Then run a test with a small set of accounts covering a leaver, a mover and a user in a nested group, and document the results. Treat this as a check to run in your own environment, not as a guarantee from either project.

Capability by capability: XWiki and MediaWiki side by side

This table compares XWiki and MediaWiki on license, release lines, permissions, structured data, editing, SSO, databases, runtime and extensions. Read each row as a question to answer for your own documentation needs, and treat cells marked as items to confirm as open points for a vendor or test install.

Capability	XWiki	MediaWiki
License	LGPL-2.1-or-later, with XWiki SAS selling support, hosting and paid Pro applications	GPL-2.0-or-later; extensions using MediaWiki functions must use the same or a compatible license
Release lines and support windows	Stable 18.8.0, intermediate LTS 18.4.7 and LTS 17.10.14, maintained in parallel	Stable 1.46 (end of life July 2027), LTS 1.43 supported until December 2027; LTS released every two years
Permission granularity	View, comment, edit and delete rights at wiki, page or hierarchy level	Confirm the group and namespace rights model you need with your own test install and the MediaWiki permissions documentation
Structured data and page types	Structured wiki with page-level structure and data; confirm which object types your content model needs	Wikitext pages, templates and categories; confirm whether Semantic MediaWiki or similar extensions meet your data needs
Editing experience	Confirm the editor modes and rich editing options in your target version with a pilot team	Wikitext-based editing; confirm the visual editor and extension options available on your chosen release
SSO route	Pro applications list Active Directory and Azure Active Directory SSO; confirm OIDC support via the xwiki-contrib OIDC extension for your version	PluggableAuth framework with OpenID Connect, SAML through SimpleSAMLphp, LDAP and REMOTE_USER plugins; PluggableAuth 7.x needs MediaWiki 1.40 or later
Database options	Official Docker images for MySQL, PostgreSQL and MariaDB, each on Tomcat	MariaDB 10.3+, MySQL 5.7+, PostgreSQL 10+ and SQLite 3.31+; MariaDB or MySQL recommended
Runtime requirement	Java application server (Tomcat in the official images); confirm the JDK version for your release	PHP 8.3.0 or later for the latest stable, with Apache HTTPD or Nginx commonly used
Extension ecosystem	Standard is free; Pro adds business applications, connectors and support in tiered plans	Large community extension base under GPL-compatible terms; confirm each extension's license and maintenance status before adopting it

What each license allows and what is paid for

XWiki is licensed under the LGPL 2.1, a weak copyleft license that lets you run, modify and deploy the platform inside your organization without releasing internal changes to the core. The free XWiki Standard edition is the open source version, so the software itself carries no license fee. Paid spending goes to XWiki SAS, which sells XWiki Pro, support subscriptions and services. XWiki Pro combines the platform with business applications, connectors and XWiki SAS support, and the Pro and support subscriptions come in these tiers:

Starter: up to 25 users, available for XWiki Cloud only.
Basic: up to 1,000 users.
Business: up to 10,000 users.
Enterprise: unlimited users.
Services rates: consulting is listed at 1200 EUR per day and requires a Business or Enterprise support plan, and training is listed at 1500 EUR per day, per the XWiki pricing page.

XWiki SAS states that cloud and on-premises Pro pricing is the same. Confirm with XWiki SAS in writing whether that parity covers your user count, support hours and any Pro applications you plan to use.

What drives the running cost of each wiki

Running either wiki is mostly a staffing and upkeep question rather than a license question, since both engines are open source. The cards below separate the components a quote should break out, who gets paid for each, and which ones recur every year.

Hosting and database footprint

Both platforms run on infrastructure you pay for in your own cloud or data center. XWiki's official images run on Tomcat with MySQL, PostgreSQL or MariaDB variants, while MediaWiki needs PHP 8.3.0 or later with MariaDB, MySQL, PostgreSQL or SQLite. The database choice and the number of application nodes drive the recurring compute and backup bill. Ask the implementer to price the database, backups and the staging copy separately, since a second environment for upgrade testing doubles much of this line.

Java or PHP operating skills

The cost of staff depends on which stack your team already runs. XWiki is a Java application served through Tomcat, so JVM tuning, servlet container patching and Java-literate troubleshooting are the skills to price. MediaWiki is a PHP application, so PHP version management and web server configuration are the everyday tasks. A team that already operates Java services may absorb XWiki at lower marginal cost, and a PHP shop the reverse. Ask who on your staff will own the platform and whether that work is covered in the quote.

Paid support and consulting

Both engines are free to download, but support is bought separately. XWiki SAS sells on-premises professional support and lists consulting at 1200 EUR per day, which requires a Business or Enterprise support plan, and training at 1500 EUR per day (xwiki.com pricing). MediaWiki has no vendor support contract to buy, so the equivalent spend goes to an outside implementer or your own staff. Request whether support hours are included, what response times apply, and whether consulting is billed per day or per fixed scope.

Pro subscriptions and tier fees

If you choose XWiki Pro, the subscription is a recurring cost tied to user count. Tiers run from Starter (up to 25 users, XWiki Cloud only) through Basic (up to 1,000 users), Business (up to 10,000 users) and Enterprise (unlimited users). XWiki SAS states cloud and on-premises pricing is the same, so the tier decision is about user count and support, not hosting location. Request the one-time setup fee, the annual renewal and any migration charges separately, because a Confluence migration is billed as its own item.

Extension maintenance and testing

Extensions carry the most recurring engineering effort in either wiki. For MediaWiki, SSO is typically added through PluggableAuth, and PluggableAuth 7.x requires MediaWiki 1.40 or later, so each core upgrade can force an extension version change and a regression test of login. XWiki's OIDC support comes from community contributions maintained in xwiki-contrib, and Pro applications add their own updates. Budget recurring time for testing each extension against every core release you plan to run, not only for the initial install.

Upgrade effort across release lines

Upgrade cost depends on how often you move and which release line you follow. MediaWiki publishes an LTS release every two years, with upgrades supported from up to two LTS releases back, and 1.43 is supported until December 2027. XWiki runs a stable line alongside an LTS and an intermediate LTS, with 18.8.0, 18.4.7 and 17.10.14 currently published. Choose the line that matches your change tolerance, then ask the implementer to quote a yearly upgrade cycle including test environments and rollback rehearsal.

How to move content between XWiki and MediaWiki

This sequence turns a move between XWiki and MediaWiki into a planned, tested cutover with a known set of migrated content, mapped permissions and an archived source. It applies in either direction, and no supplied fact confirms a direct import tool between the two platforms, so the export and import path must be confirmed before work starts.

Confirm the export and import path
Before any scoping, confirm with each vendor, or with a service provider you trust, which export formats and import paths exist between XWiki and MediaWiki. No supplied fact covers a direct import tool between these two platforms, so do not assume one. Ask whether page history, attachments, user accounts and permissions can leave the source in a usable form, and whether the destination can accept them. The step is done when you hold a written answer for each of those points and know whether the move will rely on custom scripts, an intermediate format or a paid service. Record the answers, because they set the effort for every later step.
Inventory spaces, pages and permissions
Working with the wiki owner and the people who manage access, list every space or namespace, the page count and size of each, attachments, and the permission rules that apply at wiki, space, page or hierarchy level in the source. In MediaWiki, record which groups hold read, edit and move rights and which pages are restricted. In XWiki, record the rights granted at each level. Flag content that is stale, duplicated or owned by a team that has left. The step is done when you have a signed-off inventory that states which content moves, which is archived and which is deleted.
Map namespaces and categories to spaces
Translate the source structure into the destination model. MediaWiki organizes content through namespaces, categories and templates, while XWiki organizes content into spaces, page hierarchies and page types. Decide which MediaWiki namespaces become XWiki spaces, which categories become labels, tags or page types, and which templates need a replacement design. Document the rule for each mapping. Illustrative example: a team might map a Procedures namespace to a Procedures space and a Category of Runbook to a page type with its own fields. The step is done when every namespace and category has a documented target and a named owner for that decision.
Decide what structured data is rebuilt
Decide which data is transferred as page content and which is rebuilt in the destination. Free text and attachments usually move with less rework than structured data such as template-driven fields, infoboxes or data driven by extensions. MediaWiki extensions and XWiki applications each have their own data models, so a field in one may have no direct equivalent in the other. List every structured element, state whether it is transferred, rebuilt or retired, and name who rebuilds it and how it will be checked. The step is done when the rebuild list is approved and the owners of each structured element have accepted their part.
Move users and groups through SSO
Plan identity before content moves so that users can sign in to the destination and their group memberships map to the rights decided in step two. On the MediaWiki side, check whether the current login uses an extension such as PluggableAuth with OpenID Connect, SAML or LDAP, and on the XWiki side, confirm which SSO option your edition supports, since the XWiki Pro page lists Active Directory and Azure Active Directory SSO applications and the community OIDC extension is hosted on GitHub. Map each source group to a destination group, and test one sign-in per group. The step is done when a test account from each group can sign in and sees exactly the spaces and pages its rights allow.
Test the migration with a sample of pages
Run the migration on a representative sample before the full set. Choose pages across every namespace or space, including pages with attachments, long histories, restricted rights, templates and any structured data. Check that the title, text, links, images, history and permissions match the source, and that broken internal links are listed for repair. Ask the migration owner to confirm what history and attachment metadata is kept. The step is done when the sample passes a written checklist and the defects found are fixed and retested, with a count of open issues agreed by the business owner.
Cut over and communicate the switch
Schedule the final migration, freeze edits in the source for the window needed, run the full move and repeat the checks from the test on the complete set. Redirect users to the destination, update links in onboarding material and any tools that point to the old wiki, and announce the new location and the sign-in method. Keep the source in read-only mode until the business owner accepts the cutover in writing. The step is done when the agreed checks pass on the full content, users can reach the new wiki, and the owner has signed the cutover record.
Archive the source and document the result
Once the cutover is accepted, export a read-only archive of the source with its configuration, user and group lists, permission rules and extension list, and store it under your records policy. Record the mapping decisions, rebuilt structured data, known gaps and the owner of each open item. Confirm the retention period for the archive with your compliance or legal team, and remove the source only after that period and the owner's sign-off. The step is done when the archive is verified, the decision record is filed and the source has a dated retirement plan.

What implementing each wiki involves and where projects run long

The biggest difference in implementation work is that XWiki is a Java application deployed from official images in three database variants, while MediaWiki is a PHP application whose database and extensions you assemble yourself. For XWiki, the official Docker images come in MySQL, PostgreSQL and MariaDB variants, each running on Tomcat, so the first decision is which database your DBA team already runs and which image line you pin. For MediaWiki, the latest stable release requires at least PHP 8.3.0, and MariaDB or MySQL is recommended, so the decision is your PHP runtime, web server and database version. In both cases, confirm the image tag or PHP baseline against the vendor pages before you commit to a build, since the supported lines change over time.

SSO and permissions are where scope tends to grow. For MediaWiki, external login runs through the PluggableAuth framework with plugins for OpenID Connect, SAML through SimpleSAMLphp, and LDAP through LDAPAuthentication2, and PluggableAuth 7.x requires MediaWiki 1.40 or later. XWiki's OIDC support is documented in the community xwiki-contrib/oidc extension, and Active Directory SSO is listed among XWiki Pro applications, so confirm which path your identity provider needs. Permission design should happen before content migration, not after. Map your groups to XWiki rights at wiki, space or page level, or to MediaWiki groups and namespace restrictions, and test the model with real user accounts. Projects usually run long when permission design is left until late, because every migrated space then needs rework.

Legacy content is the second common overrun. Pages exported from an older wiki or a shared drive often lack consistent structure, so plan a cleanup pass that decides which spaces, namespaces and templates survive. Budget for training separately, since editors in XWiki's structured model and MediaWiki's markup both need guidance. Ongoing patching is the recurring cost, and it depends on release lines. MediaWiki's LTS track runs on a two-year cycle with a one-year overlap, and upgrades are supported from up to two LTS releases back, so plan which LTS you run and when you move to the next one. XWiki runs parallel stable and LTS branches. Extension compatibility is the check most often skipped: before each upgrade, verify every extension against the target core version. Confirm support windows directly with each vendor, because they are the source of truth.

What buyers ask before choosing or hiring help for XWiki or MediaWiki

Is XWiki or MediaWiki cheaper to run for internal documentation?

Neither license charges a fee, so the difference comes from infrastructure, administration and the extensions you need. XWiki is LGPL-2.1-or-later and its official Docker images run on Tomcat with MySQL, PostgreSQL or MariaDB variants, which keeps the Java stack as the main operating burden. MediaWiki is GPL-2.0-or-later and requires PHP 8.3.0 or later, with MariaDB or MySQL recommended, per the MediaWiki installation requirements. Ask for the cost of the database, the application server, backups and the staff hours to patch each one. Paid XWiki SAS support or Pro subscriptions are optional and priced by user tier, so get those in writing only if you want them.

Does XWiki Pro need to be bought for Active Directory or Azure AD SSO?

XWiki Pro lists Active Directory and Azure Active Directory SSO applications among its Pro features, per the XWiki Pro page, so an AD or Azure AD requirement points toward a Pro subscription. Confirm the exact protocol support and the current app versions with XWiki SAS before you commit, because the list is a product page and not a compatibility guarantee. Open-source XWiki can also use the community OIDC extension at xwiki-contrib/oidc, which you should test against your identity provider and review for maintenance status. MediaWiki reaches external identity providers through the PluggableAuth framework, which covers OpenID Connect, SAML and LDAP, but each plugin has its own setup and support status.

Are MediaWiki's SSO extensions enough for a regulated environment?

They can be, if your identity provider and SAML or OIDC settings match one of the supported PluggableAuth plugins. PluggableAuth 7.x requires MediaWiki 1.40 or later, per its extension page, so check that your target release meets that floor. You must test session handling, group mapping, account deprovisioning and logging for the specific plugin, because the framework does not replace the testing. Ask whether your security team needs a supported vendor for the identity layer, which is a separate question from whether the extension works.

Which LTS line should we pick, and how long is it supported?

Pick the line that matches how often your team can perform major upgrades. XWiki publishes a stable line, an intermediate LTS and an LTS line, and at the time of research the Docker tags were 18.8.0 for stable, 18.4.7 for the intermediate LTS and 17.10.14 for LTS, per the official Docker library file for XWiki. MediaWiki 1.43 is the LTS release supported until December 2027, and 1.46 is the current stable release with end of life in July 2027, per the MediaWiki version lifecycle page. Confirm the support dates against each vendor's lifecycle page on the day you decide, because they move.

How long does a Confluence or wiki migration take?

The duration depends on page count, attachment volume, permission mapping and how much cleanup your content needs, so no general figure is reliable. For XWiki, the Confluence Migrator Pro extension from XWiki SAS migrates spaces, pages, users, groups, permissions, attachments and metadata, keeps page history but not attachment history, and is priced from 2000 EUR with a trial limited to 30 pages per migration, per the XWiki Store. MediaWiki has no comparable supplied migration tool in this research, so ask for a written migration plan that covers import method, permissions and link rewriting before you estimate effort.

Can our own team run either wiki without outside help?

A team with Linux, database and web server skills can run either wiki, but the work includes upgrades, backups, extension testing and access control design. Each product moves between release lines, so plan for upgrades on a fixed cadence, including testing extensions after each one. Outside help can cover installation, hardening, backup design, upgrade planning or training, and DeployOpen works on self-hosted platforms inside your own infrastructure under a written, fixed scope. Get the deliverables in writing before work begins, and ask whether ongoing support is needed as a retainer.

What does XWiki's permission model give us that MediaWiki does not?

XWiki is built around structured pages and fine-grained rights, and XWiki markets view, comment, edit and delete rights at wiki, page or hierarchy level, with every page change kept under version control, per xwiki.com. MediaWiki offers namespaces, groups and extension-based control, which many organizations find sufficient for documentation. Write down the permission rules you need, such as departmental restricted spaces or review workflows, and test each one on both platforms before choosing. Do not assume a feature exists until you have confirmed it in a test instance.

How DeployOpen helps choose, implement or migrate a documentation wiki

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure. For XWiki vs MediaWiki, we start from your permission model, content types and identity provider, then build and hand over a wiki that matches the choice your team makes.

How we scope

We map who needs view, edit and delete rights at wiki, space and page level before choosing an engine.
We confirm the SSO provider, directory groups and extensions your environment requires for either platform.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
We identify which content needs structured data and which only needs narrative pages, so the choice rests on evidence.

How we build

We deploy the chosen wiki in your cloud account, data center or air-gapped network, using your database and web server standards.
We configure authentication, including PluggableAuth or an XWiki OIDC extension, and test login and group mapping end to end.
We build templates, navigation and permission structures, and test them with a sample of real editors before go-live.
We run security testing on the deployed wiki and document the findings and fixes.

How we hand over

You receive written documentation covering the architecture, configuration, extension inventory and permission model.
We provide runbooks for backups, restores, version upgrades and extension updates for your operations team.
We document the migration approach and the content mapping, so your editors know where each space or page ends up.
Handover includes a review session so your administrators can run the wiki without us.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover tracking of the MediaWiki LTS and XWiki release lines so your upgrade windows stay planned.
We can re-test permissions and extensions after each upgrade, and document any changes to your configuration.
Confirm response expectations, upgrade scope and testing frequency in the retainer agreement before signing.

XWiki vs MediaWiki