Why a self-hosted Confluence alternative needs a timeline now
A self-hosted wiki such as XWiki or Docmost can replace Confluence Data Center for an organization that must keep documentation on its own servers, but the export and migration work has to start well before the dates that force the move. The first date is December 1, 2026, when Atlassian ends support for XML site and space export in Confluence Cloud. Export features keep working after that, but Atlassian will no longer fix bugs or accept tickets for them and recommends CSV instead. The second date is March 28, 2029, when Data Center licenses, Confluence Data Center included, expire and become read-only. Work backward from both dates, because the first one arrives sooner and affects anyone whose export pipeline depends on XML.
Start with the decisions that set the rest of the schedule. Decide which backup format you will migrate from, since the XWiki route reads XML and CSV backups and the Docmost route imports HTML space exports. Decide which wiki fits your data model: XWiki is the closest match for spaces, page trees and structured data, while Docmost and BookStack are simpler to run. Decide whether you need paid support or the paid migrator, and whether a licensed edition of the target product is required for SSO, LDAP, MFA or page-level permissions. Each choice changes what you must test and who must approve the result.
Confirm the facts that vary by environment before you commit. Inventory your spaces, attachments, permission schemes and Marketplace apps, and check how much of each your target wiki can represent. Ask the target vendor or implementation partner what is lost, such as attachment history in the XWiki migrator, and record that as an accepted risk. Ask your procurement team for a written, fixed scope and deliverables before any migration test starts, because a quote depends on the scope you define.
What the Data Center end of life requires from your replacement
Atlassian's Data Center timeline sets the deadlines, but the requirements that matter are practical: where the wiki runs, how content leaves Confluence, and whether history, attachments, permissions and users survive the move. Each card below is a check to run before you pick a target and set a cutover date.
Keep the wiki on your infrastructure
Confluence Data Center licenses expire and become read-only on March 28, 2029, so a replacement has to run in your own cloud account, data center or air-gapped network from day one. Check that the target is licensed for self-hosting without a hosted-only restriction, and that you can run its database, file storage and backups yourself. Ask who holds administrator access to the underlying servers.
Watch the purchase cutoffs
New Data Center subscriptions for new customers ended on March 30, 2026, and expansions for existing customers end after March 30, 2028. If you plan to add seats or users in the meantime, confirm the exact cutoff with your Atlassian account team, because a late expansion extends your dependency on Data Center rather than a migration plan. Use the gap to run a pilot instead.
Plan around XML export end of life
Atlassian ends support for Confluence Cloud XML site and space export on December 1, 2026, and recommends CSV instead. If your migration tool reads XML, start your full export and test imports before that date, since bugs will no longer be fixed after it. Confirm which export format your target importer accepts and whether it reads Data Center backups directly.
Keep page history and attachments
Page history is usually kept by migration tools, but attachment history is not in every case. XWiki's Confluence Migrator Pro keeps page history but does not preserve attachment history, so decide whether you need old attachment versions for audit or legal reasons. Test a sample space with large attachments and confirm how the target stores them and what it does with broken links.
Carry over permissions and users
Spaces, page restrictions, groups and user accounts define who can read and edit regulated content, so they must match after cutover. XWiki's migrator carries permissions, users and groups from Confluence exports, but you should verify restrictions on sample pages and confirm how identities map to your directory. Document any permission that the target models differently, and record the reviewer who signed off on it.
Working back from the 2026 and 2029 dates
The first step is to put Atlassian's dates on one timeline, because they apply to different things. Atlassian ends new Data Center subscriptions for new customers on March 30, 2026, and ends purchases and expansions for existing customers after March 30, 2028. On March 28, 2029, Data Center licenses, Confluence Data Center included, expire and become read-only. Read-only means the wiki stays available for reading but cannot be edited, so the 2029 date is the hard stop for any plan that keeps the same instance. Ask your Atlassian account team for the exact expiry date on your own contract, since renewal terms, co-terming and any negotiated extensions can shift the date that applies to you. Record that date, the number of users covered and the latest date you can still expand the license, and treat the earliest of these as the deadline for your plan.
The XML export deadline is separate and much closer. Atlassian ends support for XML site and space export in Confluence Cloud on December 1, 2026. After that date the features still work, but Atlassian will no longer fix bugs or accept support tickets for them, and it recommends CSV export instead. Any migration that depends on XML therefore carries a vendor support gap from that date. Where possible, plan to export in CSV or HTML, which Atlassian's Cloud export options also offer, and confirm with your migration partner which formats their importer reads. Run a test export of one large space early, check attachments, page trees and permissions in the output, and keep a full site backup from the backup manager as a fallback. Your own environment, including whether you run Cloud, Data Center or both, determines which of these exports you can actually take.
Which self-hosted options meet the constraint, and where each falls short
This table compares the self-hosted wikis most often shortlisted after Confluence Data Center goes read-only, covering license, migration path, editions and gaps. Read each row against your own page tree, permission model and attachment needs, since no option is a drop-in match for every Confluence feature.
| Criterion | XWiki | Docmost | BookStack |
|---|---|---|---|
| License | LGPL-2.1 open-source core, latest supplied release xwiki-platform 18.4.7 | AGPL-3.0, latest supplied release v0.96.0 | MIT, latest supplied release v26.09.1 |
| Confluence migration path | Confluence Migrator Pro from XWiki SAS is a paid extension that reads XML and CSV backups; the open-source XML filter stream sits underneath it | Imports an HTML space export from Confluence; the Confluence importer is listed as a paid-edition feature | No documented Confluence importer; plan a manual or scripted export and rebuild of pages |
| Editions and support | Free XWiki Standard; XWiki Pro and support subscriptions from XWiki SAS are optional | Free core with a paid edition for SSO, LDAP, MFA, page-level permissions and importers | Single open-source edition; no paid tier is needed for OIDC, SAML2 or LDAP sign-in or enforced MFA |
| Hierarchy and structure | Spaces and page trees close to Confluence, with structured data and macros | Spaces and page tree, with databases in the paid edition | Shelves, books, chapters and pages; a fixed hierarchy that may not map one-to-one to Confluence spaces |
| Main gap to verify | Marketplace apps and some Confluence macros need XWiki equivalents or custom work | Paid-edition features must be budgeted if you need them in production | Migration effort is higher and no official Docker images are assumed; confirm your deployment method |
| Attachment history | Migrator does not preserve attachment history; plan an archive of old versions | Confirm with the vendor how attachment versions are imported | Confirm how attachments and revisions move during any manual migration |
Choosing a target by team situation
Large Confluence estates with many spaces, deep page trees, heavy macro use and granular space permissions are the closest match for XWiki. It is the most complete open-source option for structured content, and its Confluence Migrator Pro and open-source XML filter read Confluence backups, which is why it fits teams that cannot rebuild everything by hand.
- Permissions: Confirm that space-level and page-level restrictions, groups and inherited rights map correctly in a pilot space before you move the full estate.
- Macros: List every macro in use, then test each one on XWiki. Some Confluence macros have no direct equivalent and need rebuilding as XWiki macros or pages.
- Attachments: Check whether attachment history matters to your auditors, because the migrator does not preserve it.
- Marketplace apps: Identify which Confluence apps your teams depend on and whether XWiki offers an extension or a replacement workflow.
- Support model: Decide whether a self-supported install or a paid XWiki SAS support plan fits your team, and ask for the costs in writing.
Before committing, run a pilot on your most macro-heavy space and confirm that permissions and page links survive the import.
Teams that value a fast, modern editing experience and real-time collaboration often look at Docmost. Its licensing is AGPL-3.0, but its documentation lists the Confluence importer, SSO, LDAP, MFA, page-level permissions and databases as paid-edition features. That split changes the cost and the compliance picture, so the pilot must be run on the edition you intend to operate.
- Edition check: Confirm which features your controls require, such as SSO, MFA and page-level permissions, and whether they sit in the free or paid edition.
- Import path: Test the HTML space export route, then review the page tree, internal links, attachments and draw.io diagrams by hand.
- Permissions model: Verify that space and group access matches your current Confluence model, since page-level rules may depend on the paid edition.
- Export and exit: Confirm that pages export as Markdown or HTML so you keep a route out of the platform.
- Custom macros: Expect Confluence macros and Marketplace apps to need manual rebuilding or removal.
A pilot should use the exact edition and authentication setup you plan to run in production, and the result should be recorded in writing for your security reviewers.
Teams whose content fits a plain shelf, book and chapter structure, such as runbooks, onboarding guides and policy libraries, can use BookStack. It is MIT-licensed, organizes content into fixed levels and offers OIDC, SAML2 and LDAP sign-in with enforced MFA, without a paid edition. The trade-off is that its fixed hierarchy fits less well with Confluence's free-form page trees and macros.
- Hierarchy fit: Map your spaces to shelves and books, then check whether deeper page trees flatten in a way readers will accept.
- Sign-in and MFA: Test OIDC, SAML2 or LDAP against your identity provider and confirm that MFA enforcement works for every account type.
- Macro gaps: Identify Confluence macros, such as dynamic content or reports, that need a manual rewrite or a different layout.
- Install method: Confirm your deployment approach, since BookStack is run without official Docker images, so the team must own the container build and update process.
- Content volume: Check page counts and attachment sizes during the pilot, and plan the import in batches.
Confirm the installation method, supported PHP and database versions and your update routine with the BookStack project before you plan production.
How to deploy XWiki or Docmost under the constraint
This sequence moves Confluence content into a wiki your organization runs in its own network, with each step ending in a check so the cutover happens only after the content, permissions and backups have been verified.
Inventory spaces, attachments and users
Start by listing every Confluence space, its owner, page count, attachment volume, blog posts, and the groups and permissions attached to each space. Mark spaces that are archived, personal or duplicated, because these are candidates to leave behind. Confirm which Confluence edition and version the content lives on, since that determines which export and import paths are available. Done means you have a signed-off inventory that business owners have reviewed, and a list of spaces to migrate, archive or retire.
Choose a supported export format
Select the export format before any export runs. Atlassian ends support for Confluence Cloud XML site and space export on December 1, 2026 and recommends CSV instead, so plan around CSV or other formats that the target importer reads. For XWiki, its Confluence migrator reads XML and CSV backups, so confirm with XWiki which format the chosen tooling expects for your edition. For Docmost, confirm the HTML space export path and whether its Confluence importer is available in your edition. Done means a written decision record names the format, the importer and the reason.
Stand up XWiki in your own network
Deploy XWiki on infrastructure you control using the official Docker images, which come in MySQL, PostgreSQL and MariaDB variants running on Tomcat for amd64 and arm64v8. Choose the release line deliberately. At the time of research the official tags were 18.8.0 for stable, 17.10.14 for the long term support line and 18.4.7 for the intermediate long term support line. A long term support line suits teams that prefer fewer major upgrades, while the stable line receives new features sooner. Pin the exact tag in your deployment manifest. Done means the instance starts, serves its login page behind your reverse proxy, and the database and file storage sit on backed-up volumes inside your network.
Run a pilot migration on one space
Import one representative space into a non-production XWiki instance, choosing a space with nested pages, internal links, images and several attachments. Record what arrived, including page history, links, macros and attachment handling. Compare counts of pages and attachments against the inventory. Known limits matter here: XWiki's paid Confluence Migrator Pro keeps page history but not attachment history, so decide in advance whether that loss is acceptable. Done means a written pilot report lists each defect and whether it is fixed, accepted or blocking.
Verify permissions and attachments
Test access with real accounts from each group in the inventory. Confirm that space-level and page-level restrictions match the Confluence source, that users in directory groups see the right spaces, and that a sample of attachments opens with the correct file size and content. Check internal links and macros on pages with complex layouts by hand, because automated imports seldom catch every one. Done means each permission test case is signed off by the space owner, and the attachment sample check passes without open defects.
Cut over and freeze the source
Schedule the production migration after the pilot defects are closed. Put the Confluence space into read-only or announce a freeze window, run a final export and import, and repeat the page and attachment counts from the inventory. Redirect users to the new wiki and keep Confluence available read-only for a defined period so staff can check content. Done means counts match within the tolerances the business agreed, owners have confirmed their spaces, and the old Confluence link points users to the new location.
Set backup and upgrade routines
Define a recurring backup of the database and attachment storage, and test a restore into a separate environment before relying on it. Set a routine for applying XWiki patch releases from your chosen line, and track the end of life of that line so you move before support lapses. Record who approves upgrades and where the runbook lives. Done means a successful restore test is documented, the upgrade calendar is published to the platform team, and the runbook names an owner for each task.
Questions buyers ask before hiring help
What drives the cost of moving from Confluence Data Center to a self-hosted wiki?
Cost depends on four components: the wiki software, the servers or cloud accounts that run it, the migration tooling, and the administrator time to operate it. The XWiki core is LGPL-2.1, so the software license itself carries no fee. Recurring costs are hosting, backups, patching and staff time. One-time costs are the migration, the identity integration, and any paid extensions or consulting. Ask any provider to split a quote into these components so you can see which ones your own team can absorb and which need outside hands.
Are the Confluence Migrator Pro price and XWiki consulting rate the only costs?
No. XWiki SAS lists Confluence Migrator Pro from 2000 EUR and consulting at 1200 EUR per day, which requires a Business or Enterprise support plan, according to XWiki's pricing pages. Those are vendor list figures, and they cover only the tooling and XWiki's own services. Other costs include infrastructure, the database and reverse proxy, the identity provider, testing, user communication, cleanup of pages that break during import, and ongoing upgrades. A free migration path using the open-source Confluence XML filter is possible, but it needs more internal engineering time.
How long does a Confluence migration take for a large instance?
Duration depends mainly on the number of spaces, the number of pages, the volume and size of attachments, and how much macro and permission cleanup the content needs. The trial of Confluence Migrator Pro is limited to 30 pages per migration, so a full instance requires a paid license. Attachment history is not preserved by the migrator. Ask a provider for a written schedule based on a test import of a representative sample space, because no published figure applies to your content.
What does our team need to provide before an engagement starts?
You need to provide four things. First, administrator access to the Confluence instance, including site and space export rights. Second, a target environment in your own data center or cloud account, with the network access and sizing agreed in advance. Third, a working identity provider for single sign-on, with group and role definitions. Fourth, named business owners who can decide which spaces, users and permissions to migrate. Export access matters because Confluence Cloud XML export reaches end of life on December 1, 2026, so exports should be scheduled early.
Can our own team migrate and run XWiki with the free LGPL core?
Yes, a capable team can deploy and run XWiki with the free LGPL-2.1 core, and XWiki publishes official Docker images for MySQL, PostgreSQL and MariaDB on Tomcat. The harder parts are the content migration, macro and permission mapping, and Marketplace apps that have no XWiki equivalent. Your team also takes on patching, backups and upgrades between stable and LTS lines. Many organizations split the work: internal staff own operations, while an outside provider handles the import, testing and hardening under a written scope.
Which parts of the engagement does DeployOpen cover, and how is scope fixed?
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications.
Does moving to XWiki reduce our compliance workload?
Moving the wiki changes where evidence lives, but it does not remove the obligation to show controls. Access control, logging, backup testing, change management and retention still need to be documented for whichever auditor or regulator applies to you. DeployOpen can prepare systems, controls and evidence for a compliance assessment, while independent auditors and certification bodies issue any report. Ask a provider which controls the new wiki will support directly and which still depend on your processes.
Evidence to keep for the migration and the new wiki
A migration to a self-hosted wiki creates records that an auditor or internal reviewer will ask for later: what was exported, what was lost, who can see what, and whether backups restore. DeployOpen can prepare this evidence as part of a fixed-scope engagement, but independent auditors or certification bodies assess it and decide whether it is sufficient.
Export files and checksums
Keep every Confluence export exactly as received, including the XML site backup or CSV and HTML space exports, and record a SHA-256 checksum for each file at the moment it is created. Store the checksums separately from the files so that a later copy can be verified against the original. Confirm with Atlassian which export format your site supports before the XML export end of life, since the export you rely on for evidence should still be vendor-supported when you take it.
Migration log of dropped content
Write a migration log that lists everything the import did not carry over, not only errors. For XWiki's Confluence Migrator Pro, attachment history is a known gap, so the log should state how many attachments were imported without their earlier versions. Ask the migrator's vendor for the complete list of unsupported elements before you start, and record each one with the decision taken, such as rebuilding a macro by hand or retiring the content.
Permissions comparison
Compare effective access in Confluence with access in the new wiki for a sample of spaces and pages, covering users, groups, space permissions and page restrictions. Record each mismatch and its fix, because permissions are the most likely source of an access finding after cutover. Include who can export or delete content in the new wiki, and confirm which of these controls require a paid edition in the product you choose.
Deployment configuration and version record
Keep a versioned record of the wiki's deployment: the exact image tag or package version, the database and its version, the reverse proxy and TLS settings, the SSO configuration, and every extension installed. Store configuration in version control with secrets kept out of the repository. Pin the release you tested, and note the upgrade path for the line you chose, such as XWiki's stable, LTS or intermediate LTS release lines.
Backup and restore test results
A backup that has never been restored is not evidence of recoverability. Restore the wiki database and attachment store to a separate environment, then record the date, the restore steps, the elapsed time, and the checks that passed, such as page counts, attachment integrity and login. Repeat the test after each upgrade and keep the results with the deployment record so that the restore can be traced to a specific version.
Ownership and review sign-off
Name an owner for each record, a reviewer who is not the person who created it, and the date of each review. Record who approved cutover and who accepted the migration log's list of dropped content. Keep the sign-offs with the evidence rather than in a chat thread, so that a reviewer can follow the decisions from the export to the live wiki without interviewing the team.
What changes for users, admins and integrations
The biggest practical change is that links, macros and Marketplace apps do not carry over unchanged, so plan a break inventory before any content moves. Confluence macros, page links and space keys will not resolve the same way in XWiki, and the migration tooling will not rewrite every reference for you. Ask the vendor or the migrator documentation which macros and link forms are converted, then sample pages from your largest spaces and record what breaks. Anything embedded from Marketplace apps needs an owner who decides whether to rebuild it, replace it or retire it.
Marketplace apps are the area where you should expect the most gaps. XWiki has its own extension catalog and does not offer a one-to-one copy of every Confluence add-on, so list every app your spaces depend on and confirm each one against the sibling comparison Confluence vs XWiki before committing to a target. Do not assume an equivalent exists because a similar name appears in a catalog. Where no match exists, decide whether the content can live as plain pages, whether a custom extension is worth funding, or whether the workflow should end.
For users, the change is mostly in sign-in and editing habits. Confirm how your identity provider will connect to the new wiki, whether users must enroll again, and how group membership maps to XWiki rights, since permissions do not always translate one for one. Admins need training on extension management, backups, upgrades and the XWiki administration model, and writers need guidance on the new editor and macro syntax. Budget for that training as a recurring part of onboarding, and ask any services partner to include it in a written scope.
How DeployOpen plans and deploys a self-hosted wiki
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks. For a wiki replacing Confluence, that means agreeing on the target platform, the content to move and the controls your organization needs before any migration work begins.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- The written scope lists which Confluence spaces, users, permissions and attachments are in and out of the move
- Scope also records where the wiki will run, whether in your cloud, your data center or an air-gapped network
How we build
- We install the chosen wiki in your environment, with database, search, storage and single sign-on configured to your standards
- Migration is tested on a sample of spaces first, so you can see what carries over and what needs manual rework
- Security testing of the deployed wiki can be scoped separately, covering applications, APIs and the hosting infrastructure
How we hand over
- Handover includes configuration documentation, backup and restore procedures, and an agreed list of known gaps against Confluence
- Compliance readiness material, such as access reviews and configuration evidence, is prepared for your own auditors to assess
- Your administrators are walked through daily operation, upgrades and extension management before the project closes
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Retainers cover patching and version upgrades of the wiki, so updates follow a planned process rather than ad hoc changes
- Ask any provider to confirm in writing which support, response and backup tasks sit inside the retainer and which are billed separately
