Confluence Cloud XML export end of life: what it means for your migration plan
If your Confluence Cloud team is planning a move to self-hosted infrastructure, the XML export you may have scripted is losing vendor support on December 1, 2026. After that date, Confluence Cloud XML site and space export still works, but Atlassian will no longer fix bugs or accept support tickets for it, and it recommends CSV export instead. For a migration, the practical question is which format your target can read: XWiki's Confluence migrator reads both XML and CSV backups, while Docmost imports HTML space exports. Treat the date as a planning constraint rather than an emergency, but do not leave the export inventory until the last quarter of 2026.
Your short answer depends on the target. XWiki is the most complete open-source match for Confluence structures, and its paid Confluence Migrator Pro reads XML and CSV backups, so an XML export remains a valid input for now. Docmost is a lighter wiki that imports HTML space exports, and its Confluence importer is a paid-edition feature, so confirm the edition and licence terms with the vendor before you rely on it. Either way, run a trial import of one representative space early. Confirm which attachment, page history and permission data survive the import in your own environment, because the export format alone does not settle that.
Start the inventory now. List every space, its export format, its attachments and its owners, and note any spaces that depend on Marketplace apps or macros. Ask each space owner which content must survive intact and which can be archived. Plan one test export per format, keep the exports in a location your security team approves, and record who signs off on each export. The inventory gives you a defensible scope for a fixed-scope migration quote and shows where a CSV or HTML fallback is needed. Check the current export options in Atlassian's support documentation before you commit to a format, since the supported options are the ones the vendor maintains.
What the XML export deadline requires from your migration
The December 1, 2026 end of life for Confluence Cloud XML export turns a general wish to leave Atlassian into a set of dated obligations. Each card below is a decision or check that your team should close before the export path changes under you. Together they decide whether your content arrives intact in XWiki or Docmost.
Set a dated migration decision
Choose a target wiki and an owner before December 1, 2026, when Atlassian stops fixing bugs and accepting support tickets for XML site and space export. The features keep working after that date, but a bug found in a migration run will have no vendor fix path. Also note the separate timeline for Data Center, which becomes read-only on March 28, 2029, so the XML decision and the longer-term hosting decision should be made as two linked items on one plan.
Pick a format the target reads
Match the export format to the import path before you run anything. XWiki's Confluence Migrator Pro reads XML and CSV backups, so a space exported as XML or CSV from Confluence Cloud is the input to test first. Docmost's import dialog accepts a Confluence export, so confirm with its documentation which Confluence export it expects and whether the Confluence importer is available in your edition, since Docmost lists that importer as a paid-edition feature.
Export attachments and permissions
A migration that moves page text but drops attachments or access rules creates a second cleanup project. Check that your chosen export carries attachments, users, groups and space permissions into the target, and record what each export format leaves out. XWiki's migrator keeps page history but not attachment history, so decide whether attachment versions must be archived separately before the source space is retired.
Run a test restore
Restore a representative set of spaces into a staging instance of the target wiki before any production cutover. Choose spaces that contain large attachments, deep page trees, diagrams, user mentions and restricted pages, then compare page counts, links and permissions against the source. Keep the restore log and the comparison results, because they become the evidence that the migration worked as planned.
Confirm the target's install path
Plan the hosting before the import, not after it. XWiki publishes official Docker images in MySQL, PostgreSQL and MariaDB variants, while Docmost recommends a Docker installation that runs PostgreSQL and Redis and requires an APP_SECRET of at least 32 characters. Confirm with each vendor which version line you will run, where the database and file storage live, and how backups of the target itself will be taken and tested.
How XWiki and Docmost read a Confluence export
XWiki reads Confluence backups through the Confluence Migrator Pro, a paid extension sold by XWiki SAS. The extension imports XML and CSV backups from Confluence Server, Data Center and Cloud, so a team that exports its Cloud spaces as XML before the December 1, 2026 end of life can still feed that file to the migrator. The migrator brings across pages, spaces, attachments, permissions, blog posts, and users and groups. It keeps page history but does not preserve attachment history, so older versions of files will not appear in XWiki.
- Pages and spaces: Page content, the space structure and blog posts move into XWiki spaces and pages.
- Permissions and identities: Users, groups and permission assignments are carried over, which matters for access reviews after the move.
- Attachment history: Only the current attachment versions arrive, so keep the original export archived if past file versions must be retained.
- Pricing basis: The migrator is a paid extension, and XWiki SAS lists it from 2000 EUR with a trial limited to 30 pages per migration. Confirm the current scope and terms with XWiki SAS.
- Open-source filter: The XML filter stream underneath the migrator is open source, so teams with in-house Java skills can evaluate it as a no-license route, with more engineering effort.
Before committing, run a trial import of a representative space and compare page counts, permissions and attachments against the source.
Docmost's import dialog accepts Markdown, HTML, Word, Notion and Confluence exports. Its Confluence importer is a paid-edition feature, so a team that plans to use it needs a Business or Enterprise license, while the Community edition is free to self-host but does not include that importer. Docmost's own documentation describes the import as working from a Confluence export, and the Confluence-specific details of what survives should be checked against the importer in your edition.
- Paid importer: The Confluence importer sits behind the paid editions, alongside the DOCX and PDF importers, so budget for the license before the migration starts.
- Free fallback: Pages and whole spaces can be exported as Markdown or HTML, and the free Community edition can import Markdown and HTML files, which is a workable route for content without Confluence-only features.
- SSO and MFA: SAML 2.0 or OIDC single sign-on, LDAP, SCIM provisioning and MFA are paid-edition features, so the Community edition relies on email and password sign-in only for the free tier. Note that the Docmost README lists TOTP and LDAP among the authentication methods, so confirm which ones your edition enables.
- Page-level permissions: These are also a paid-edition feature, so plan how space-level access maps to the Community edition.
- Pricing reference: The Docmost pricing page lists a Business plan at $6 per seat per month billed annually with a 10-seat minimum. Confirm current terms on the pricing page before budgeting.
Ask for a sample import of one space and check the permissions and SSO setup in the edition you intend to run.
The two routes differ mainly in who is paid and for which features. XWiki's core is LGPL-2.1, so the platform itself carries no license fee, but the migrator is a separately priced extension and support is optional. Docmost's core is AGPL-3.0, but code in its enterprise directories is under the Docmost Enterprise license, and the features that matter most for a migration live in that code. Both routes have recurring costs for hosting, administration and upgrades, and one-time costs for the migration and validation work.
- One-time costs: Migration tooling or license, a trial import, content cleanup, and validation of permissions and links.
- Recurring costs: Hosting, database and storage operations, patching and upgrades, and any per-seat subscription.
- Cost drivers: The number of spaces and attachments, how much Confluence-only macro content exists, the user count for per-seat plans, and whether SSO must work on day one.
- Services: XWiki SAS lists consulting at 1200 EUR per day for Business or Enterprise support plans and training at 1500 EUR per day. Those are list rates for that vendor, not estimates for your project.
- Quote request: Ask each vendor which edition, extension or license covers the importer, SSO, MFA and permissions you need, and whether the quote includes trial imports.
Compare the total of licensing, hosting and labor over the period you plan to run the wiki, not the license line alone.
Neither importer should be treated as a finished migration. Both produce content that needs checks for links, macros, diagrams, attachments and access rules. The XWiki migrator retains page history but not attachment history, and the Docmost importer depends on the edition in use and on what the Confluence export contains. Plan a verification pass for each space, with a named owner who signs off on the results.
- Links and page tree: Check that internal links resolve and that the hierarchy matches the source.
- Attachments: Compare file counts and sizes, and confirm which versions of each file arrived.
- Macros and diagrams: Confluence macros, Marketplace app content and diagrams often need manual rebuilding, so list them before the import.
- Permissions: Compare space and page access against the source for each group, and test sign-in with a sample of real accounts in a staging environment.
- Archive the source: Keep the original export, with its attachments and metadata, in a controlled location until the target has been accepted.
Ask the implementation partner for a written verification checklist that covers each space type before the production cutover.
Which open-source target fits your export format and deployment
This table compares XWiki, Docmost and three adjacent options by license, Confluence import path, sign-in and trade-offs. Read it against your export format and deployment model, since the import path decides which Confluence data you can carry over without manual rework.
| Option | License and edition | Confluence import path | Sign-in and trade-offs |
|---|---|---|---|
| XWiki | LGPL-2.1 core; Confluence Migrator Pro is a paid XWiki SAS extension | Open-source Confluence XML filter underlies the Migrator Pro, which reads XML and CSV backups from Server, Data Center and Cloud | Strongest Confluence-style match and LTS lines, but the migrator is paid and attachment history is not kept |
| Docmost | AGPL-3.0 core; SSO, LDAP, MFA and the Confluence importer are paid-edition features | Imports a Confluence export through the import dialog, which Docmost lists as a paid-edition importer | Confirm the importer on the community edition before planning around it; the Business plan is per seat |
| BookStack | MIT licensed, current release line published in 2026 | No Confluence importer is named in the supplied facts; plan a manual or scripted conversion to HTML or Markdown | Confirm OIDC, SAML2 and LDAP options for your identity provider; fixed shelf, book and page hierarchy |
| Docs from La Suite | MIT licensed, current release line published in 2026 | No Confluence importer is named in the supplied facts; confirm import options with the project | Suited to organizations that want a French public-sector project; confirm the feature fit for your spaces |
| Plane | Confluence importer on Plane Cloud and the self-hosted Commercial Edition | Confluence importer exists, but it is a work management tool, so page-tree fidelity should be tested | Choose only if the documentation must sit beside project work; confirm which edition you would run |
| Outline (not open source) | Business Source License 1.1; converts to Apache 2.0 on each release's change date | Not a target for this migration plan if open source is a requirement | Self-hosting is allowed, but hosting it as a service is restricted; confirm the license terms with counsel |
What a Confluence XML export does not carry into the new wiki
The first thing to plan for is that an export is a copy of content, not of behavior. According to the supplied XWiki Store information, XWiki's Confluence Migrator Pro keeps page history but does not preserve attachment history, so the current version of each file moves across while earlier versions do not. If your compliance or legal process relies on prior attachment versions, decide before the pilot whether you will archive those versions separately from the Confluence site, or accept that they stay in Atlassian's system until the site is retired. Ask the migration provider to confirm in writing how each attachment version is handled, and test it on a file you have revised several times.
Macros, Marketplace apps and internal links need a separate review. A wiki that imports page bodies does not automatically reproduce every Confluence macro or app behavior, and the supplied facts do not establish a one-to-one XWiki equivalent for each Marketplace app. Build an inventory of the macros and apps your busiest spaces use, then check each one in the target wiki. For Docmost, the supplied documentation describes page tree, internal link and attachment handling in its Confluence import, but you should confirm links and draw.io diagrams in a pilot space instead of assuming they survive intact. Dead links to moved pages are a common source of user complaints after cutover.
Permissions need the most careful pilot. Space permissions, page restrictions, groups and users must map to the target model, and the two products do not structure access in identical ways. In XWiki, confirm how imported groups and page-level rights land after import. In Docmost, the supplied documentation lists page-level permissions, SCIM provisioning and SSO with SAML 2.0 or OIDC as paid-edition features, so verify the edition you plan to run covers the controls your policy requires before you promise parity. Test one restricted space with users from each group, check that inherited rights behave as expected, and record the results as evidence for your access review.
How to deploy your chosen wiki and run a test migration
This sequence takes you from a complete inventory of your Confluence content to a tested target wiki, so you can judge fidelity and effort on one space before committing the full estate to a cutover.
Inventory spaces, attachments and permissions
The Confluence site admin lists every space, its owner, page count, attachment volume, blog posts and who holds access, grouped by business owner. Mark which spaces hold regulated or legally held records. Note any Marketplace apps and macros in use, because these have no direct equivalent in either target. The step is done when you have a signed-off list of spaces to migrate, retire or archive, with an owner named for each.
Export a pilot space in a supported format
A space admin exports one representative space from Confluence Cloud, choosing a format that the target can read. Confluence Cloud space admins can export as PDF, CSV, HTML or XML, and site admins can create a full site backup from the backup manager. Because XML export reaches end of life on December 1, 2026, prefer CSV or HTML for new work and confirm with XWiki or Docmost which exports their current importers accept. The step is done when the export file is archived with a checksum and its contents are recorded.
Stand up the target wiki
Your platform team deploys the target in your own infrastructure. For XWiki, use the official Docker images, which come in MySQL, PostgreSQL and MariaDB variants running on Tomcat, and confirm which tag line (stable, LTS or intermediate LTS) suits your support needs. For Docmost, use its Docker Compose template, which runs PostgreSQL 18 and Redis 8 and requires an APP_SECRET of at least 32 characters, stored in your secrets manager. The step is done when the wiki starts, the database is backed up and an administrator can sign in.
Run the pilot import and review fidelity
Import the pilot export using the target's Confluence importer, then check the result page by page. Compare the page tree, internal links, macros, images, attachments, permissions and user or group mapping against the source. For XWiki, confirm whether your edition includes the Confluence Migrator Pro extension and note that attachment history is not preserved. For Docmost, confirm that the Confluence importer is available in your edition, since it is a paid feature. The step is done when a written defect list exists and each defect is assigned to a fix or accepted.
Put Docmost behind a reverse proxy
If you chose Docmost, place it behind your reverse proxy with TLS, and enable WebSockets on that proxy, because the real-time editor depends on them. Test editing from two browsers at once and confirm that file uploads and downloads work through the proxy. XWiki also runs behind a proxy in most deployments, so apply the same TLS and header checks to it. The step is done when two users can co-edit a test page without errors and the certificate chain validates from a client outside your network.
Validate with users and rehearse the cutover
Have a small group of real users from the pilot space confirm that their pages, links and permissions behave as expected, and record the issues they find. Rehearse the full cutover on a copy of the environment, including the final export, import, redirect plan for old links and a rollback path to Confluence. Confirm current import limits, supported export formats and any edition restrictions with the vendor in writing before you schedule production work. The step is done when the rehearsal completes and the cutover checklist is approved by the business owners.
Cut over and retain the source
Freeze edits in the source spaces, run the final export and import, then switch users to the new wiki and publish redirects or a notice for old links. Keep the Confluence export archives and the source instance readable for an agreed retention period set by your records policy. Monitor defect reports for the first weeks and route them to the platform team. The step is done when every migrated space has an owner sign-off and the archive is stored in a location your records team controls.
Questions teams ask before the XML export deadline
What does a Confluence to XWiki migration cost?
The cost has several parts: the XWiki software itself is free under LGPL 2.1, so the main lines are the paid Confluence Migrator Pro extension, optional XWiki SAS support subscriptions, hosting, and the admin time your staff spend. Migrator Pro is priced from 2000 EUR according to XWiki's store listing, and its trial is limited to 30 pages per migration, so test on a sample before buying. Consulting from XWiki SAS is listed at 1200 EUR per day and requires a Business or Enterprise support plan. Ask any provider for a written quote that separates one-time work (planning, export, migration, cleanup, training) from recurring items (hosting, support, upgrades, licence renewals).
How long does a Confluence XML export migration take?
No duration is published in the sources for this migration, so treat any timeline as something to confirm in writing. The main drivers are the number of spaces and pages, the volume and size of attachments, how much page history you need, how many users, groups and permission rules must be mapped, and how many macros or Marketplace apps need manual rework. Test imports on a representative space first, since problems found early shorten the main run. Ask the provider to state the phases, the assumptions behind the estimate and what work falls outside the agreed scope.
Can our team migrate Confluence to XWiki without outside help?
Yes, a capable internal team can run the migration, provided it has someone who administers XWiki and understands your Confluence permission model. The open-source Confluence XML filter is the component underneath the paid migrator, so the technical path exists either way, but you still need to plan the export, run test imports, verify permissions and users, and fix broken links and macros by hand. Outside help is most useful for mapping complex permissions, scripting bulk checks, and training staff. Weigh the time your engineers would spend against the cost of a fixed-scope engagement.
What should we provide before starting a migration?
Prepare an inventory of spaces, page counts, attachment sizes, blog posts, users, groups and space permissions, and identify the owners who can approve scope decisions. Confirm which Confluence edition and export format you have, since XML and CSV backups behave differently. Provide access to a non-production XWiki environment, the hosting target and its network rules, and your identity provider details if single sign-on is in scope. Decide in advance what happens to attachment history, which Migrator Pro does not preserve, and which content can be archived instead of migrated.
Will Confluence XML export still work after December 1, 2026?
Yes, the features keep working after that date, but Atlassian will no longer fix bugs or accept support tickets for XML site and space export. Atlassian recommends CSV export instead. If you plan to rely on an XML backup for a migration, create and verify it well before the deadline, store it in your own systems, and test that your target tool reads it. Confirm the current export options directly with Atlassian, because the export options in your edition may change.
Does Docmost import Confluence exports, and what does it cost?
Docmost's import dialog accepts a Confluence export, but its documentation lists the Confluence importer as a paid-edition feature, so confirm which edition you would run before planning. Its Community edition is free for self-hosting, and the pricing page lists a Business plan at $6 per seat per month billed annually with a 10-seat minimum, plus Enterprise at custom pricing. Recurring costs therefore depend on seat count and your hosting. Ask for the edition, licence terms and the import limits in writing before you commit.
What drives the ongoing cost of self-hosting a wiki?
After the migration, the recurring costs are infrastructure (servers or cloud resources, database, backups and storage), software support or licence fees if you buy them, upgrades and security patching, and the admin time to run them. XWiki publishes stable, LTS and intermediate LTS lines, so choose one that matches your upgrade cadence. Ask any provider to itemize these recurring costs separately from the one-time migration work, and to state who is responsible for backups, restore tests and upgrades after handover.
Evidence to keep from the export and the migration
A security or compliance reviewer will ask how data left Confluence Cloud, what arrived in the target wiki, and who could reach it. The cards below list the records that answer those questions, and they connect because each one supports the same chain of custody from export to cutover.
Export run logs and inputs
Keep the record of each export: which site or space was exported, the export format chosen (XML or CSV), the date and the admin account that ran it. Confirm in the Confluence admin backup manager and space export screens what the log retains, because Atlassian's retention for these logs is not part of the supplied facts. Store the exported files with a checksum taken at the moment of export, so every later copy can be matched to one source file.
Space and permission inventory
Produce a dated inventory of every space, its page count, attachment count, owners, and the groups and users with access. Compare it against the target after import, since XWiki's Confluence migrator carries permissions and users and groups, but the reviewer needs proof that the mapping held. Record any space that was excluded, archived or left behind, with the reason and the approver.
Count and hash reconciliation
Reconcile source and target by counts of pages, attachments, comments and users, and by checksums on exported attachment files where the target keeps the original bytes. Expect known differences to be documented rather than hidden: for example, XWiki's migrator keeps page history but not attachment history, so the reconciliation must state that gap in writing. Sign off each space with the person who checked it.
Pilot test results
Keep the results of a pilot import of representative spaces, including a space with deep page trees, many attachments, internal links, and restricted permissions. Record which pages rendered wrong, which macros or diagrams broke, and how each defect was fixed or accepted. Dated pilot results show the reviewer that the full migration was tested before the December 1, 2026 end of life.
Access control configuration
Export and retain the configuration for the target wiki: admin accounts, group-to-role mappings, space-level rights, single sign-on settings and MFA enforcement. Note which controls depend on paid editions or extensions, such as the Confluence importer in Docmost or the paid XWiki migrator. Keep configuration snapshots before and after cutover so a reviewer can see what changed and when.
Decision record against the deadline
Write down the date the migration path was chosen, the reasons, the alternatives considered, and the approver, and set it against the December 1, 2026 end of life for XML export. Atlassian will no longer fix bugs or accept tickets for XML export after that date, so the record should show whether the team exported before or after it. Keep the decision with the migration plan so an auditor can trace the timeline.
Setting a timeline that fits both deadlines
The December 1, 2026 end of life for XML site and space export comes long before the March 28, 2029 date when Data Center licenses, Confluence Data Center included, expire and become read-only. For Confluence Cloud customers, the XML deadline is the one that counts. After it, the export features still run, but Atlassian stops fixing bugs in them and stops accepting support tickets, and it recommends CSV export instead. A Cloud team that plans to move to XWiki should therefore decide early whether its backup path depends on XML, because the XWiki Confluence Migrator Pro reads both XML and CSV backups and the choice of format affects what arrives intact.
Data Center customers face a different calculation. Their hard stop is the read-only date in 2029, not the XML deadline, but the Data Center timeline is set by contract terms that Atlassian has described in its Ascend announcement: new Data Center subscriptions for new customers end on March 30, 2026, and purchases and expansions for existing customers end after March 30, 2028. A Data Center organization should not assume it has until 2029 without checking its own subscription end date, renewal terms and any notice Atlassian has issued to it. Confirm these terms directly with Atlassian or your reseller, because the dates in public announcements may not match the terms in your agreement.
A practical plan works backward from the earliest deadline that applies to your organization. Run a test export of one representative space in both XML and CSV formats, import it into a non-production XWiki instance, and record what arrives and what does not, including attachment history, which the migrator does not preserve. Schedule the production cutover with enough room for a second test pass and user acceptance, and keep the Confluence source read-only during the final import so that no edits are lost. If your Data Center contract runs past 2029, treat the Cloud XML date as a reason to start the work now rather than as the end of your options.
How DeployOpen plans and runs a Confluence to self-hosted migration
DeployOpen plans, implements and hands over self-hosted wiki platforms inside your own infrastructure, so a move off Confluence Cloud XML export is scoped against your real backups, spaces and permissions before any import runs. Engagements are fixed-scope, with deliverables and timelines agreed in writing first.
How we scope
- We inventory which spaces, attachments, permissions and blog posts your export must carry across.
- We confirm which export formats your Confluence edition offers before the December 1, 2026 date.
- We agree the target platform, XWiki or Docmost, and the written scope in advance, with no prices in this step.
How we build
- We deploy the target wiki in your cloud account, data center or air-gapped network, with the database, storage and reverse proxy settings your security team approves.
- We run test migrations on a copy of your export and compare page trees, internal links, attachments and permissions against the source.
- We document what each import keeps and loses, such as attachment history in XWiki, so you decide what to check by hand.
How we hand over
- We deliver the installed platform, configuration records, migration logs and a list of items that needed manual correction.
- We prepare backup and upgrade procedures and walk your administrators through them.
- We provide documentation for your team to repeat or audit the migration steps later.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We can plan follow-up imports for content that was not in the first export, under the same written scope.
- Compliance evidence about your deployment is prepared for your independent auditor, who issues any report or certification.
