Export your data from Confluence before the contract ends
A renewal, a licensing change or a data residency requirement can force a Confluence move on a short timetable, so the first task is to find out what you can take out. 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, but no single export is a complete copy of everything your organization stored in Confluence. Each format keeps a different slice of the content. Review Atlassian's export documentation and plan to use more than one format, checking what each one leaves out well before the contract ends.
The formats differ mainly in what they keep. CSV exports include attachments and comments by default, which makes it the most complete space-level option for most teams. HTML exports leave out blog posts and page comments, and PDF exports never include comments, so both suit reading and archiving pages better than moving a working wiki. XML has been the format migration tools relied on, but Atlassian ends support for Confluence Cloud XML site and space export on December 1, 2026 and recommends CSV instead. Space exports run by a space admin contain only content that person can view, while CSV and XML exports run by a site admin receive all content, so run the exports that matter under a site admin account where your policy allows it.
Some content stays out of every export. Team Calendars are not included in any export, so record those events separately before access is cut. Confirm with your Atlassian account team whether any Marketplace apps store data outside the standard export, because those gaps will not show up in a space export. Server and Data Center exports follow a separate path with their own formats and deadlines, which this page covers later, so do not assume a Cloud export will cover an on-premises instance. Before the contract ends, run a test export of one representative space, open it in the destination tool, and compare page counts, attachments and permissions against the source.
Which Confluence Cloud export formats keep attachments, comments and blog posts
This table compares the Confluence Cloud export methods by what each keeps, who can run them and where they stop. Read each row against the content you must preserve, because space exports only include what the exporter can view, with CSV and XML as the exceptions for site admins. The main takeaway is that no single export covers everything, so plan a separate pass for blog posts, comments, attachments and Team Calendars.
| Data type or export | Method and who runs it | What it keeps and limits |
|---|---|---|
| Space CSV export | Space admins export visible content; site admins receive all content | Includes attachments and comments by default, covering everything the user can view. Confirm the output against a sample space before relying on it. |
| Space HTML export | Space admins export a space as HTML | Omits blog posts and page comments. Use this format for page content and attachments, then export blog posts and comments separately. |
| Space PDF export | Space admins export a space as PDF | Never includes comments. Suitable for read-only records, not for a migration that must keep discussion threads. |
| Space XML export | Site admins receive all content; space admins see only visible content | End of life on December 1, 2026. Atlassian recommends CSV export instead, so plan new migrations around CSV. |
| Full site backup | Site admins create it from the backup manager | Covers the whole site as a single backup. Confirm with Atlassian what it contains and how to restore it outside Confluence. |
| Team Calendars | Not available through any space export | No export includes Team Calendars. Record calendar events manually or with a separate tool before cutover. |
What no Confluence export includes and how to cover the gap
No single Confluence export captures everything a team relies on. Team Calendars are excluded from every format, and each format drops a different slice of comments, blog posts or content the exporter cannot see. Plan a separate capture for each gap before you sign off a migration, and confirm any gap you find with Atlassian support.
Team Calendars are excluded
No Confluence Cloud export format includes Team Calendars, so events, calendar definitions and their attendee lists will not reach a new wiki from any export. Record each calendar's owner, purpose and recurring events in a spreadsheet, or export the events through the calendar's own iCal feed where Atlassian makes one available. Check that each calendar exists on the destination platform in some form before retiring the source.
Page comments missing from HTML
HTML space exports omit page comments, so review threads and questions attached to pages will not appear in the imported wiki. If those discussions hold decisions, export the affected spaces as CSV, which includes comments by default, and check that the comment text is present in the file. Keep the CSV as a reference copy even when the HTML export is the one you import.
Blog posts missing from HTML
HTML exports also leave out blog posts, so announcements, release notes and team updates stored as blogs need a separate path. Run a CSV export of the space or ask a site admin to export the content, then confirm the blog entries appear with their dates. Decide whether blog posts become pages, dated articles or read-only archive in the destination before the cutover.
Comments absent from PDF
PDF exports never include comments, so a PDF is a record of page content only and is not a full copy of a space. Use PDF for sign-off copies or legal holds of specific pages, and pair each PDF with a CSV export of the same space if discussions matter. Label the PDF set with the export date so reviewers know what it does and does not show.
Content beyond the exporter's permissions
Standard space exports include only content the person running them can view, so restricted pages and spaces they cannot access will be missing. A site admin running a CSV or XML export receives all content, which makes the site admin account the right one for a complete inventory. Compare page counts per space between the source and the export, and document any space you could not reach.
Confirm further gaps with Atlassian
The four gaps above are the ones documented for space exports, but your instance may hold other content, such as Marketplace app data or custom macro output. Ask Atlassian support in writing which content types each export keeps for your edition and version, and record the answer with the export date. Treat anything not confirmed as missing until you have verified it in the destination.
Run a complete Confluence export in the right order
This sequence produces a verified copy of every Confluence Cloud space, attachment and calendar you need, checked against the source before anything in Confluence changes. It gives your target platform the right input for each kind of content.
Inventory spaces and their visibility
A site admin lists every space on the site, including personal spaces and archived spaces, and records the page count, attachment count and owner for each one. Note which spaces hold restricted content, because a space admin export only includes content that the exporter can see, while site admin CSV and XML exports receive all content. Keep this inventory as the baseline for every check that follows. It is done when each space has a row with a page count and the site admin has confirmed the list against the space directory.
Run a full site backup as the master copy
A site admin creates a full site backup from the backup manager in Confluence Cloud. This archive is your master copy of content, permissions and attachments, and it is the copy you keep if any later export is incomplete. Store it in a location your security team controls and record the date, size and the admin who ran it. It is done when the backup finishes and you have downloaded it and confirmed the file opens or that its size matches the expected range for the site.
Export each space as CSV with attachments
Run a CSV export for each space from a site admin account, since CSV exports by site admins receive all content. Confirm that the export includes attachments and comments, which are included by default. Compare the page count and attachment total in each export against your inventory from the first step. It is done when every space matches its baseline numbers, and any mismatch is investigated before you move on.
Add HTML exports where the importer needs them
Run HTML exports only for spaces whose target importer reads HTML, such as Docmost's Confluence import path. Remember that HTML exports omit blog posts and page comments, so export those separately if you need them. Open a sample of pages in the HTML output and check headings, tables, internal links and embedded images. It is done when the sampled pages render correctly and you have a written list of which content types the HTML export omits.
Export PDFs only for fixed-layout records
Create PDF exports only for records that must be preserved as fixed copies, such as signed policies or contract-related documents. PDF exports never include comments, so record that gap for any page where comments carry decisions. Open each PDF and check page breaks, images and the first and last page of the document against the live page. It is done when every PDF in the set has been opened and you have noted what it does not contain.
Capture Team Calendars separately
Team Calendars are not included in any Confluence export, so collect them through another route, such as the calendar's own export or a list of events kept by the calendar owners. Record the calendar names, owners and event counts before you start the migration. Confirm with each owner that the saved list matches what they see in Confluence. It is done when every calendar has a recorded owner, a saved event list and a sign-off from that owner.
Verify every export before changing the source
Before any space is archived, restricted or deleted, compare the full set of exports against the inventory, the page counts and the attachment totals. Open a random sample of pages from each space in the export and compare them with the live Confluence pages, including page history where you need it. Keep the source unchanged until this check is signed off in writing by the content owner. It is done when all counts match, the sample review finds no unexplained differences and the source is still in its original state.
What the December 1, 2026 XML end of life means for your export plan
XML site and space export in Confluence Cloud reaches end of life on December 1, 2026. After that date the export features keep working, but Atlassian will no longer fix bugs in them or accept support tickets for them, and it recommends CSV export instead. For a migration, the practical risk is not that the export stops, but that a problem you hit in January has no vendor fix path. Decide early which format your target needs, because that choice sets the export you run and the test you must complete before the cutoff. The Atlassian support article on XML export end of life is the authoritative statement of the change and should be read against your own timeline.
The decision depends on the target. XWiki's Confluence Migrator Pro reads both XML and CSV backups from Confluence, so an XML export is not automatically required if you plan to move to XWiki. Confirm with XWiki which backup formats the migrator version you intend to use accepts, and whether it keeps the data you need from each one, such as page history, permissions, users and groups, and attachments. Confirm the same for any other target. If the target reads only one format, that format sets the export plan, and an XML export taken now is the artifact that will be hardest to reproduce later.
Run a trial export and migration before the deadline rather than after it. Export a representative space in each format you are considering, load it into a non-production instance of the target, and compare page counts, attachment counts, page hierarchy, internal links and user and group mappings against the source. Record any gap and ask the target's maintainer or vendor how to close it. Keep the full site backup from the backup manager as a separate fallback, since site admins control it and it does not replace a tested space export. Plan the final export as a dated, repeatable step so that content created after the trial is captured.
Match the export format to the target wiki
XWiki has the most direct path from Confluence because its migration tooling reads Confluence backups. The paid Confluence Migrator Pro from XWiki SAS imports XML and CSV backups from Confluence Server, Data Center and Cloud, and it moves pages, spaces, attachments, permissions, blog posts, users and groups. The open-source Confluence XML filter stream is the component the paid migrator builds on, so teams with engineering capacity can evaluate that route before buying anything. Attachment history is not preserved by the migrator, so plan for that gap.
- Input formats: XML and CSV backups, which map to the Confluence Cloud exports covered on this page.
- Kept: pages, spaces, attachments, permissions, blog posts, users and groups.
- Not kept: attachment history.
- Commercial cost: the Confluence Migrator Pro is priced from 2000 EUR, according to the XWiki Store, and its trial is limited to 30 pages per migration, so a full space set needs a paid license to migrate in one pass.
- Export timing: XML site and space export reaches end of life on December 1, 2026, so XML-based runs planned after that date should be checked against the current Atlassian guidance.
Before you commit, run the trial on a representative space and confirm with XWiki SAS which input versions and Confluence editions the current release accepts.
Docmost takes a different route. Its import dialog accepts Markdown, HTML, Word, Notion and Confluence exports, and the documentation describes the Confluence importer as a paid-edition feature. For a Confluence space, the input most relevant to this page is the HTML space export, which Docmost's sibling migration guidance covers in detail. HTML exports omit blog posts and page comments, so content in those categories needs a separate plan.
- Input formats: HTML space exports for Confluence content, plus Markdown and Word for other material.
- Licensing: the Confluence, DOCX and PDF importers are listed as paid-edition features in the Docmost documentation.
- Omitted from HTML: blog posts and page comments, so export those separately if they matter.
- Output formats: pages export as Markdown or HTML, which gives you a second exit path.
- Checks: confirm whether the current Docmost edition includes the importer you need before planning around it.
HTML exports do not carry the same metadata as CSV or XML, so review permissions, links and attachments by hand after import.
Several other wikis and knowledge bases accept Confluence content through their own importers or through generic formats. BookStack, Outline and Plane are examples, but their supported inputs change between releases and between editions, so the export format you pick must match what each product currently reads. Plane lists Confluence and Notion importers on Plane Cloud and its self-hosted Commercial Edition, which is a different offering from a community self-hosted install. Outline and BookStack should be checked against their current import documentation before any export is run.
- Plane: Confluence importer listed for Plane Cloud and the self-hosted Commercial Edition.
- Outline: confirm the Confluence and generic import paths in the current release, because its license terms also affect hosting decisions.
- BookStack: confirm which export formats its import tooling reads, since its fixed shelf, book and chapter model maps differently from Confluence spaces.
- Fallback path: HTML or Markdown exports are often the most portable inputs, but test them on a sample space first.
- Vendor check: ask each vendor in writing which Confluence export formats and editions its importer supports today.
If no importer matches your export, you may need a scripted conversion, which adds engineering time that should be scoped before the target is chosen.
What to plan before the Confluence contract ends
The first planning item is the size of the export itself, because a full export is the step most likely to set the schedule. Atlassian's documentation describes how space admins export individual spaces and how site admins create a full site backup from the backup manager, but no duration for a full export is published in the sources this page relies on. Ask Atlassian support to confirm how long an export of your site will take at your number of spaces, pages, attachments and blog posts, and run a test export of your largest space before you commit to a date. Record who holds site admin rights, since only site admins can produce the all-content CSV and XML exports, and confirm that at least two named people can run them if one is unavailable.
The second item is the read-only window and the parallel run. Confirm with Atlassian exactly when your product stops accepting edits relative to the contract end date, and whether that date is the same for your edition. Plan a parallel period in which the new wiki receives the migrated content and the team checks links, permissions and attachments against the export, so that writing continues in Confluence until the cutover is agreed. Keep the XML export end of life on December 1, 2026 in view, since a migration that depends on XML backups should not start its final export after that date without a fallback to CSV.
The third item is what happens to exported copies after the export is complete. Once content leaves Atlassian, the export files become a new data store with their own retention period, encryption, storage location and access list, and those rules must match your existing policies for confidential and personal data. Decide where the files will sit, who may open them, how long they are kept and how they are deleted after the migration is verified. Confirm your obligations with your privacy and records teams, since page content and user details in an export may include personal data.
What to plan before renewal or termination
Each card is a decision or check that determines whether the export is complete, usable and lawful to keep. Most of them depend on the Confluence edition you run and the date you plan to stop paying for it, so settle those first.
Confirm admin roles and access
Space admins can export only the content visible to them, while CSV and XML exports run by site admins receive all content. Confirm which people hold site admin rights before the export window opens, and make sure a named owner can run it. Ask whether any Team Calendars need a separate manual copy, because no export includes them.
Schedule the XML export before December 1, 2026
Atlassian ends support for Confluence Cloud XML site and space export on December 1, 2026. The features keep working after that date, but Atlassian will no longer fix bugs or accept support tickets for them and recommends CSV instead. If your target is XWiki, which reads XML and CSV backups, put the XML run on the calendar early so a failed export has time to be retried.
Record the attachment history gap
Confluence Migrator Pro keeps page history but does not preserve attachment history. If you plan to migrate to XWiki with that tool, record which attachments have multiple versions and decide whether the latest version is enough. Keep the original Confluence export as an archive so earlier attachment versions remain available for audit or legal review.
Decide retention for PDF and HTML copies
PDF exports never include comments, and HTML exports omit blog posts and page comments. Either format can serve as a readable record, but neither is a full copy of the space. Decide which content needs a complete CSV or XML copy, which can live as PDF, and how long each copy must be kept under your records policy. Confirm that retention rules also cover the copies of exports stored on laptops and shared drives.
Confirm the Data Center timeline
If your organization runs Confluence Data Center, check the dates in Atlassian's Ascend announcement before you set a deadline. New Data Center subscriptions for new customers end on March 30, 2026, and Data Center licenses expire and become read-only on March 28, 2029. Confirm which dates apply to your contract with your Atlassian account team, since renewal terms can differ from the public schedule.
Verify exports in a test instance
Run a trial export and import into a non-production XWiki or Docmost instance before the renewal date. Compare page counts, attachments, permissions and internal links against the source space. Record any gaps in writing, because a gap found after termination leaves no Confluence instance to re-run the export from. Ask your implementation partner to document the results as part of the migration evidence.
How much effort does a Confluence export take and what do you need to do it yourself?
Can an internal admin run a Confluence export without outside help?
Yes, for a single space or a small set of spaces, an internal admin can usually run the export from the Confluence Cloud interface. 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. The harder part is not clicking export but deciding what the export must keep, checking the result and planning where it lands. If the content has to feed a wiki that reads a specific format, confirm the format requirement before you start, because an export that is complete but in the wrong format still needs rework.
What makes a Confluence export take longer?
Effort rises with the number of spaces, the volume of attachments, the complexity of the permissions model and the amount of content that does not export cleanly. The main drivers are:
- Space count and page depth, since each space is exported and checked separately.
- Attachment volume, because large files increase export size and the time to download and verify them.
- Permissions, since space exports include only content visible to the exporter unless a site admin runs a CSV or XML export.
- Team Calendars and macros, which need manual review because no export includes Team Calendars and macro output may not carry over to another wiki.
Ask your implementation partner to inventory these four items in writing before agreeing on a timeline.
Which permissions and roles does a Confluence export require?
Space exports require space admin rights, and a full site backup requires site admin access through the backup manager. Site admins also receive all content in CSV and XML exports, while space admins see only what their own account can view. Plan for a named site admin who can create the export and for a second person who can confirm that the export reflects the full content. Check the vendor documentation for the current role requirements in your edition, since they can change between releases.
How much storage and backup space should we plan for an export?
Storage needs depend mainly on attachment volume and on how many exports you keep. Plan for the original export, a working copy for test imports and a retained archive that you can restore from if the target wiki rejects content. Ask your team to measure the total size of attachments per space before sizing storage, and confirm the export file limits and any size restrictions in the Atlassian support documentation for your site. Storage costs recur only if the archive is kept on paid infrastructure, so decide the retention period up front.
How do we verify that a Confluence export is complete?
Verify each export against a written checklist rather than trusting the file size. Compare page counts, attachment counts and the list of spaces with what the Confluence interface shows for the same account. Open a sample of pages with macros, internal links, images and attachments, and confirm they render. Record which content types were excluded by design, such as page comments in PDF or blog posts in HTML, and make sure the verification owner signs off on those gaps. A named verification owner should hold the checklist, the results and the decision to accept or re-run an export.
Who should own the export and verification inside our organization?
Assign one owner for the export plan, one site admin to run exports and one verification owner who signs off on the result. The verification owner should be someone who knows the content, such as a documentation lead or knowledge manager, not only an administrator. Give the owner a deadline tied to the Confluence Cloud XML export end of life on December 1, 2026, and record the decision in your project log so that auditors or compliance staff can see who accepted the export and when.
When is it worth requesting outside help with a Confluence export?
Request outside help when the content is large, when permissions or Team Calendars must be carried across, when macros or Marketplace apps need replacement, or when the team lacks time to verify the output. DeployOpen plans, implements, customizes, integrates and documents self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. A quote follows from that written scope, so ask for a scope that lists the spaces, attachment volumes, permission models and verification steps included. DeployOpen does not publish a price list, and it does not issue audit reports or certifications.
How DeployOpen scopes and delivers a Confluence export and migration
DeployOpen treats a Confluence export as the first stage of a migration, not a file download. We plan, implement and document the export against your actual spaces, permissions and retention needs, inside your own infrastructure. The result is a verified, documented set of exports ready for the target wiki you choose.
How we scope
- Inventory spaces, attachments, comments and blog posts to see which export format keeps each content type.
- Confirm which Confluence Cloud export roles your team holds, since site admins receive all content in CSV and XML exports.
- Agree the written, fixed scope, deliverables and timeline before any export work starts, with ongoing support available as a retainer.
How we build
- Run space exports in CSV, HTML, PDF or XML as the target platform requires, and record exactly what each export omits.
- Store exports and site backups in your own storage, checking that attachments and page history arrive intact.
- Test sample spaces end to end, including Team Calendars and other content no export includes, and document the gaps.
How we hand over
- Deliver a written export runbook with the format chosen for each space and the reasoning behind it.
- Provide a gap register listing content that must be recreated by hand, such as Team Calendars and Marketplace app data.
- Hand over evidence of each export run so your security, compliance and records teams can review it.
How we support
- Support your team through the export window, including the change in XML export support after December 1, 2026.
- Re-run exports as content changes, if your scope includes a retainer for ongoing support.
- Confirm with your own environment and the vendor any export capability that changes after this page was published.
