Confluence vs MediaWiki: which to choose

Which wiki fits your documentation model

Most readers arriving here face one of three triggers: a Confluence renewal, the approaching end of Confluence Data Center support, or a requirement to keep wiki content on servers the organization controls. The first question is not which product has more features. It is what kind of documentation you run. MediaWiki, the GPL wiki behind Wikipedia, suits long-lived, article-style knowledge: reference material that is edited carefully, linked densely and read for years. It uses wikitext as its native markup, and a visual editor is available for users who do not want to learn it. Its release model is built for stability: according to the MediaWiki version lifecycle page, the project publishes an LTS release every two years, and MediaWiki 1.43 is the current LTS release, supported until December 2027. Confluence fits a different pattern: team spaces, collaborative page workflows, comments and an app ecosystem from the Atlassian Marketplace that many teams rely on day to day.

The gap between those models shows up in four decisions. First, the editing style: will authors write wikitext, use the visual editor, or need Confluence-style macros and page layouts that a MediaWiki team would have to rebuild with templates and extensions? Second, the permission model: MediaWiki controls access through user groups and namespace rules, so check whether your current Confluence space permissions map cleanly onto it before you commit. Third, identity integration: MediaWiki reaches external identity providers through the PluggableAuth extension, which supports OpenID Connect, SAML through SimpleSAMLphp and LDAP, among others. Confirm that your identity provider and the PluggableAuth version you plan to run work together on the MediaWiki release you choose. Fourth, the admin effort your team can carry: MediaWiki requires PHP, a supported database, web server configuration and regular extension upgrades, and that workload recurs for as long as the wiki runs.

Which scenarios favor MediaWiki and which favor Confluence

This table compares common documentation scenarios by editing style, extension ecosystem and admin model, and names the better fit for each. Read it against your own content types: if most of your pages are structured, public-style articles, MediaWiki is a strong candidate, while team spaces that depend on Marketplace apps and visual editing point toward Confluence.

Scenario	Better fit	Reason
Public-style knowledge base with many linked articles	MediaWiki	Wikitext, categories, templates and a mature link model suit a large, interlinked article set that many editors maintain.
Engineering runbooks written in wikitext	MediaWiki	Engineers comfortable with wikitext get precise control over templates, code blocks and revision history without a visual editor layer.
Team project spaces with Marketplace apps	Confluence	Confluence has a large Marketplace app ecosystem, and MediaWiki extensions do not map one-to-one onto those apps.
Non-technical teams that expect a visual editor	Confluence	Confluence's editing model is built around rich, visual pages, which lowers the learning curve for occasional editors.
Regulated internal policy library with formal approvals	Confluence	Confluence's space-level permissions and approval workflows are often easier to administer for policy owners; confirm any approval feature against your edition.
Organization with a central wiki admin team and strict extension control	MediaWiki	Extensions are installed and vetted centrally under GPL-compatible licensing, which suits teams that prefer tight control over the code they run.
Single sign-on for a wiki with an existing identity provider	Either, with checks	MediaWiki reaches SAML, OpenID Connect and LDAP through PluggableAuth, while Confluence relies on Atlassian's identity configuration; confirm each option in your environment.

What the GPL license means for extensions and customization

MediaWiki is licensed under the GNU General Public License version 2 or later, and the project's COPYING file states that extensions using MediaWiki functions must be under the same or a compatible license. For an organization, this means any custom extension, skin or patch that calls MediaWiki code is part of a GPL work, and the obligations attach when you distribute it. Internal use alone does not usually trigger source disclosure, but the moment you share a modified build with a partner, a subsidiary outside your legal entity, or a vendor, you need to know what you owe. Ask your legal team to review the MediaWiki COPYING file before your first custom build goes beyond your own network.

Plan the customization model before the first line of code is written. Keep site-specific logic in your own extension, document which MediaWiki hooks and functions it calls, and choose a license deliberately, since a GPL-compatible choice is required for anything linked into MediaWiki. Store internal forks in version control with a clear record of upstream commits you have merged, because each upgrade to a new LTS line will mean rebasing those changes. Third-party extensions such as PluggableAuth carry their own license headers, so check each one individually rather than assuming they match the core.

Compare this with a commercial subscription. A Confluence customer typically licenses the product and may build apps through Atlassian's developer platform under that vendor's terms, which govern what you can modify, redistribute and keep after the subscription ends. The practical difference is that MediaWiki gives you the code and the freedom to change it, while the GPL imposes conditions on sharing that work. Confirm with Atlassian which edition, app licensing and developer terms apply to your Confluence environment, and list any custom Marketplace apps you rely on, since their licenses do not map one to one onto GPL obligations.

Where your wiki data lives and who operates it

A MediaWiki deployment is only as controlled as the servers, identity provider and operating routine behind it. The cards below cover the decisions that carry the most weight when Confluence content moves to a self-hosted wiki, and the dates that set the planning window.

Data location and residency

MediaWiki stores page text, revisions, users and uploads in your database and file store, so the location is whatever you choose: your own data center, a private cloud region or an EU provider. Confluence Cloud keeps page content in a chosen region but leaves user account data out of that scope, so ask your legal team which records count as personal data before you map them. Confirm where backups, search indexes and log files land, because each one is a separate copy.

Hosting models and operator

Decide whether your own staff run the wiki on your servers, a private cloud account you control, or an implementation partner's managed environment inside your accounts. Each model moves a different share of patching, PHP and database upgrades, backups and restore tests. Ask any partner in writing who holds administrator credentials, where support staff connect from, and how changes are logged.

Identity through PluggableAuth

The PluggableAuth extension lets MediaWiki sign users in through OpenID Connect, SAML via SimpleSAMLphp, LDAP via LDAPAuthentication2, OAuth or REMOTE_USER. Confirm that the plugin you need supports your identity provider's current protocol settings and that your PluggableAuth version matches your MediaWiki release, since PluggableAuth 7.x requires MediaWiki 1.40 or later. Test group mapping and deprovisioning, because a disabled employee should lose wiki access without a manual step.

Audit and compliance evidence

DeployOpen can prepare the wiki's configuration, access reviews, backup and restore records, change logs and hardening documentation that an assessor will ask for. Independent auditors and certification bodies issue any report or attestation, and DeployOpen does not. Agree in writing which evidence will be produced, how often, and where it is stored, and check that MediaWiki's own logs and any extension logs are retained for the period your framework requires.

Planning around Data Center end of life

Atlassian ends new Data Center subscriptions for new customers on March 30, 2026, and Data Center licenses, Confluence Data Center included, expire and become read-only on March 28, 2029. Organizations still on Data Center should set their migration window before that date and decide early whether MediaWiki's LTS cycle fits their upgrade rhythm. Confirm your own contract dates with Atlassian, since they determine when your team must move.

Who runs the wiki day to day

Platform engineering takes on the stack that Atlassian operates for you in Confluence Cloud. MediaWiki is a PHP application, so the team needs to own the PHP runtime, the web server (Apache HTTPD or Nginx are commonly used), and a supported database. The installation requirements call for at least PHP 8.3.0 for the latest stable release, and MariaDB or MySQL is recommended because Wikimedia uses MariaDB.

PHP and extensions: Pin a PHP version that the chosen MediaWiki release supports, and track it through the lifecycle.
Database: Plan backups, replication, and restore tests for MariaDB or MySQL, or confirm the support status of PostgreSQL or SQLite for your use.
Upgrades: Schedule them against the version lifecycle, which lists 1.45 as a legacy release and 1.44 as obsolete.
Media and caching: Size file storage for uploads and configure caching for page rendering.
Monitoring: Own uptime, certificates, and job queue health.

Ask your provider or implementation partner which of these tasks are covered in their quote and which stay with your internal team after handover.

Cost components on each side and what drives them

Confluence costs follow a vendor license, while MediaWiki costs follow the people who run it, the extensions you add and how often you upgrade. Both sides carry recurring labor, so the comparison depends on which components your organization already pays for and which it would take on.

Confluence subscription or Data Center licensing

On the Atlassian side, the recurring charge is the Cloud subscription or the Data Center license, typically priced by user tier or count. Ask the vendor or reseller to state in writing whether the quote is per user, per tier or per instance, what happens at renewal, and which Data Center dates apply to your contract. Data Center purchasing for new customers ends on March 30, 2026, so confirm your eligibility before budgeting for it.

MediaWiki hosting and infrastructure

MediaWiki itself is free under GPL, so the recurring cost is the server, storage and network you run it on, whether in your own data center or a cloud account. Ask what sizing your user count and attachment volume require, and whether hosting is a line item in your existing infrastructure budget. Costs rise with concurrent editors, media uploads and the number of environments you keep for staging and testing.

Database and PHP stack administration

MediaWiki runs on PHP with MariaDB or MySQL recommended, along with PostgreSQL or SQLite as alternatives. The latest stable release requires PHP 8.3.0 or later, so someone must patch the PHP runtime, the database engine and the web server, which is usually Apache HTTPD or Nginx. This is recurring admin time, and it is often the most underestimated cost. Confirm which team owns each layer and how many hours per month that ownership implies.

Custom extension development and maintenance

Confluence apps from the Marketplace have a cost of their own, but on MediaWiki, a missing feature usually means either finding a compatible extension or writing one. Extensions must match the MediaWiki version you run, so each core upgrade can require rework. Ask a consultant to inventory every extension you need, to state which are maintained upstream, and to price the maintenance of anything custom. The count of custom extensions is the largest driver of recurring development cost.

SSO integration through PluggableAuth

On MediaWiki, single sign-on is configured through the PluggableAuth framework with a plugin for OpenID Connect, SAML through SimpleSAMLphp, LDAP or other methods. The one-time work is building and testing the connection to your identity provider, and the recurring work is keeping it working when the identity provider or MediaWiki changes. Check whether PluggableAuth 7.x matches your MediaWiki version, and ask who will test sign-in after each upgrade.

Backup, restore testing and upgrades

Backups for MediaWiki cover both the database and the uploaded files, and a backup has no value until a restore has been tested. Upgrades are recurring work: MediaWiki publishes an LTS release every two years and supports upgrades from up to two LTS releases back, so a lagging instance may need a multi-step path. Ask who runs restore drills, how often upgrades happen, and whether the quote includes staging environments for upgrade testing.

Consultant fees and what to request

Implementation and migration work is usually a one-time cost, while support, upgrades and testing are often recurring retainers. Fixed-scope quotes state deliverables and timelines in writing before work starts. Ask any provider, including DeployOpen, for a written scope that lists installation, SSO setup, extension selection, data migration, backup design, upgrade plan, documentation and handover, along with the recurring support terms and what is excluded.

How a move from Confluence to MediaWiki usually runs

The sequence turns an inventory of spaces, permissions and attachments into a MediaWiki instance that a pilot group has checked before the cutover. Each phase closes with a written output the project team can review.

Inventory spaces, pages and permissions
Someone who administers Confluence lists every space, its owners, page counts, attachment volumes, blog posts, and the groups and page-level restrictions in use. Confluence apps and macros are listed separately, because each one needs a decision: rebuild with a MediaWiki extension, replace with plain wikitext, or retire. The output is a space register that records which content is current, which is archived, and which can be deleted. Confirm the inventory with the space owners before moving on, since stale spaces are the easiest content to leave behind.
Choose the export format before the Cloud XML cutoff
Decide how content leaves Confluence. Confluence Cloud space admins can export a space as PDF, CSV, HTML or XML, and site admins can create a full site backup from the backup manager. XML site and space export reaches end of life on December 1, 2026, and Atlassian recommends CSV after that date, so teams that rely on XML should plan their export window with that date in mind. Record which format is used for each space, whether attachments and comments are included, and where the files are stored. The output is an export log with checksums or file counts that the migration team can compare later.
Confirm the import path into MediaWiki
No researched source names a conversion tool that moves Confluence content into MediaWiki, so the import method must be confirmed in your environment before any build work starts. The realistic options are a scripted conversion from HTML or CSV into wikitext, an import of cleaned HTML through the standard import tools, or manual rebuilding of high-value pages. Ask the implementation partner and your own developers which method they will test, how they will handle Confluence macros, and how internal links and attachments will map to MediaWiki namespaces and file uploads. The output is a written import design with a sample space converted end to end.
Convert markup and rebuild the content structure
Convert Confluence page bodies into wikitext or cleaned HTML and map the Confluence hierarchy onto MediaWiki pages, categories and namespaces. MediaWiki has no built-in space concept, so teams usually agree a naming convention for each former space and decide which parts become categories. Confluence macros such as table of contents or status labels need an explicit replacement or a plain-text fallback. Internal links are rewritten to MediaWiki link syntax and checked. The output is a converted sample set where page titles, links and attachments resolve correctly on a staging wiki.
Rebuild permissions and configure sign-in
Translate Confluence space permissions into MediaWiki user groups and page protection settings, and document where the two models differ. MediaWiki manages access through groups and rights, so per-space permissions usually become group rights combined with namespace or page protection. For sign-in, the PluggableAuth extension provides 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 the MediaWiki release and the identity provider configuration together. The output is a permissions matrix signed off by the space owners and a test login through the chosen identity provider.
Run a pilot with a small group of users
Choose two or three spaces that represent different content types, such as a process handbook, a technical runbook and a project space with attachments. Pilot users check that pages render correctly, that search and categories work, that group access matches the permissions matrix, and that the editing workflow suits them. Track defects in a single list with owners and status. The output is a pilot report that states which defects were fixed, which were accepted, and which block cutover.
Cut over and freeze the Confluence source
Schedule the final export and import, announce a write freeze on the source spaces, run the last delta conversion, and point links and bookmarks at the new wiki. Keep the Confluence export files and the converted MediaWiki dump as a recoverable archive for the period your records policy requires. Confirm the backup and restore procedure on the MediaWiki side, because MediaWiki depends on a database and uploaded files that must be backed up together. The output is a cutover record listing the final export identifier, the import completion check and the source freeze date.
Review content and retire the old spaces
After cutover, space owners review their converted pages for broken tables, lost formatting, unresolved macros and missing attachments, and correct them in MediaWiki. Pages that are no longer needed are archived or deleted according to the retention decision made in the inventory. Ask the implementation partner to document the upgrade path as well, because MediaWiki publishes an LTS release every two years and supports upgrades from up to two LTS releases back, so a team can plan its next upgrade against the version lifecycle page. The output is a signed content review per space and a closed defect list.

Questions buyers ask before choosing MediaWiki

How much effort does a move from Confluence to MediaWiki take?

The effort depends mostly on how much of your Confluence content relies on macros, Marketplace apps and custom templates, because MediaWiki has no direct equivalent for most of them. A move from plain pages and attachments is usually simpler than one built on dynamic reports, page properties or app data. Plan the work in four parts: inventory the spaces and macros, decide how pages will be converted to wikitext or a visual editor format, migrate permissions and accounts, and test the result with real users. Ask any implementation partner for a written scope that lists each of these parts before agreeing on timing.

Can our team run MediaWiki without outside help?

A small team with Linux, PHP and database experience can usually run MediaWiki on its own, since it is a long-established PHP application with a documented installation process. The harder parts are ongoing: applying major and minor upgrades, keeping extensions compatible with the core version, managing backups, and watching security advisories. Your team should decide whether it can own those tasks every year. If not, a retainer for upgrades and support is a common way to cover them, and the quote should state which upgrade paths and extensions it includes.

How long is MediaWiki 1.43 supported, and which versions are obsolete?

MediaWiki 1.43 is the current LTS release, released on December 21, 2024 and supported until December 2027. MediaWiki 1.46 is the current stable release, released on June 30, 2026 with end of life in July 2027. MediaWiki 1.45 is a legacy release with end of life in December 2026, and 1.44 became obsolete on July 31, 2026, so installations on those versions should be upgraded soon. The MediaWiki lifecycle page sets out the upgrade paths, which allow upgrades from up to two LTS releases back since version 1.36. Confirm the dates on that page before planning your upgrade calendar.

Do Confluence macros and Marketplace apps carry over to MediaWiki?

Most Confluence macros and Marketplace apps do not carry over directly. MediaWiki has its own template and extension model, so features such as Jira issue embeds, Confluence-style page properties or app-specific reports need an equivalent extension, a template or custom development. Some functions have a close match in MediaWiki extensions, while others will be dropped or rebuilt. Make a list of every macro and app in use, then mark each one as replaced, rebuilt or retired. Ask the implementer to confirm the mapping for each item before the migration begins.

How is SSO set up in MediaWiki through PluggableAuth?

You install the PluggableAuth extension, then add a plugin for the protocol your identity provider uses, such as OpenID Connect, SAML through SimpleSAMLphp, LDAP through LDAPAuthentication2, OAuth or REMOTE_USER. The extension page lists these plugins, and PluggableAuth 7.x requires MediaWiki 1.40 or later, so check that version pairing first. Configuration is held in LocalSettings.php, and you must test login, account linking and group mapping separately. Confirm with your identity team which protocol they support and how user groups will map to MediaWiki permissions before configuring anything.

What skills and staff time does a MediaWiki deployment need?

You will need someone who can administer a Linux web server, a PHP runtime and a MariaDB or MySQL database, along with someone who understands wiki content and permissions. MediaWiki's installation requirements call for PHP 8.3.0 or later for the latest stable release, and MariaDB or MySQL is recommended. Staff time is needed for initial setup, content migration, user training and a recurring upgrade cycle. The amount of time depends on your content volume and integrations, so ask for it to be stated as a line item in any written scope rather than as an assumption.

When should we bring in a partner instead of doing it in-house?

Bring in a partner when the migration includes many macros or apps, when your identity, audit or compliance requirements are strict, or when no one on staff can own upgrades every year. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope with agreed deliverables and timelines in writing before work starts. DeployOpen also prepares controls and evidence for compliance assessments but does not issue audit reports or certifications. Ask for a written scope that names the deliverables, the handover and the support options.

When a wiki migration needs an implementation partner

An outside team earns its place when the content has to be reshaped, not just copied. Confluence spaces, page trees and labels rarely map one to one onto MediaWiki, which organizes pages by namespace and category rather than by team space. Someone must decide which spaces become namespaces, which become categories, and how child pages flatten or stay nested under a parent. The page tree and internal links are the hardest part: MediaWiki links by page title, so renamed or moved pages break references unless the title scheme is settled before import. Confirm with the MediaWiki project which import and export tools fit your Confluence export format, and test a few representative spaces, including templates and pages that rely on Confluence macros, before committing to a mapping. Any Marketplace app with no MediaWiki extension equivalent needs a written decision: rebuild it, drop it or keep the content as static text.

Permissions and sign-in are where a MediaWiki project most often needs design work. Core MediaWiki uses user groups and per-namespace or per-page restrictions, which is a different model from Confluence space permissions, so the group structure must be designed rather than inherited. For sign-in, the PluggableAuth extension is the usual route to OpenID Connect, SAML through SimpleSAMLphp, or LDAP through LDAPAuthentication2, and it requires MediaWiki 1.40 or later for PluggableAuth 7.x. Test how new accounts are created, how group membership syncs from the identity provider and how sessions end when a user leaves. Confirm the exact extension versions against your MediaWiki release, because the extension ecosystem is maintained by many separate teams.

Audit evidence and upgrade planning are the two items that recur after go-live. For compliance readiness, the implementation team can prepare access reviews, change records, backup and restore tests and configuration baselines, but an independent auditor or certification body must assess them. Upgrades also need a plan: the MediaWiki version lifecycle page lists an LTS release every two years, with 1.43 as the current LTS and 1.45 and 1.44 already in legacy or obsolete status. Extensions must be checked against each core upgrade, and upgrades are supported from up to two LTS releases back. Ask any partner for a written upgrade runbook, a named test environment and a retainer scope for patching, because the main ongoing cost is maintaining the stack, not installing it.

How DeployOpen helps evaluate, implement or migrate

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure. For a Confluence vs MediaWiki decision, we help you test whether MediaWiki fits your editing, permissions and sign-in needs before any content moves.

How we scope

We agree a written scope that lists the spaces, page types, macros and permission rules to be assessed.
Scope covers which SSO identity provider, login plugins and MediaWiki release line your team will run.
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we build

We install MediaWiki in your cloud account, data center or air-gapped network with the PHP and database versions it requires.
We configure PluggableAuth with your chosen sign-in plugin and test group mapping and access rules.
We test editing workflows, extension choices and page permissions against a sample of your real Confluence content.

How we hand over

You receive documentation covering installation, configuration, extension inventory and the upgrade path between LTS releases.
We document backup and restore procedures and the controls and evidence your compliance team may need for assessment.
We run a handover session so your administrators can operate the wiki, and we confirm all deliverables in writing.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
A retainer can cover planned upgrades to the next LTS release and checks after extension updates.
Ask any provider to confirm in writing which MediaWiki versions, extensions and sign-in options they support.

Confluence vs MediaWiki