Migrate from Confluence to Docmost

Migrate from Confluence to Docmost: what moves and what needs hands-on checks

Docmost is a reasonable target for a team that wants an AGPL-3.0 wiki on its own servers, but the import is not a single button press that leaves a finished wiki behind. Docmost's import dialog accepts Confluence exports, and its documentation lists the Confluence importer as a paid-edition feature. Confirm that edition requirement with Docmost before you plan the work, because it decides whether the import is part of the free build you intend to run or a licensed add-on. The practical answer is this: spaces can be brought over from a Confluence HTML space export, while the page tree, internal links, attachments and draw.io diagrams each need verification after the import. Do not accept a migrated space until someone has checked those four things in the target.

Usually a platform or IT team runs the migration, with a named content owner for each space who decides what is current, what is archived and what is deleted. The platform team handles the export files, the Docmost installation, storage for attachments and the import itself. The content owner signs off on the result. Effort depends mainly on the number of spaces, the page volume and how heavily the spaces use Confluence macros, since macros such as tables of contents, page includes and Jira embeds usually render as plain content or disappear after an HTML import. Ask for a sample import of one representative space before estimating the rest, and count the macros in that sample.

Build a checklist for each space: compare the page count and nesting in Confluence with Docmost, click through a sample of internal links to confirm they resolve to the right pages, open attachments and confirm their file names and sizes, and check every draw.io diagram in both systems. Confirm which Confluence export format your Cloud or Data Center site can produce, because the export options and their limits change over time, and the XML site export is scheduled to reach end of life on December 1, 2026. Plan for a second pass after the first import, and keep the Confluence source readable until each space has been signed off.

Which Confluence capabilities map to Docmost, and which need rework

This table compares the main Confluence capabilities with their Docmost equivalents after an import from a Confluence HTML space export. Each row carries a status of clean, needs rework or gap, based on what Docmost documents and which features it lists as paid-edition. Treat each status as a starting point: import a representative space from your own export, then check every page, link, attachment and diagram before you plan the cutover.

Confluence capability	Docmost equivalent	Status and what to check
Page tree and spaces	Nested pages inside spaces	Clean: confirm parent and child nesting matches the source on a sample space.
Internal links	Links between pages in the workspace	Needs rework: click through links after import and fix any that still point to Confluence.
Attachments	Files uploaded to pages	Needs rework: confirm each file imports, opens and sits on the correct page.
Draw.io diagrams	Draw.io, Excalidraw and Mermaid diagrams	Needs rework: confirm embedded Draw.io diagrams render and can still be edited.
Page history	Page version history	Clean for new edits: confirm whether imported pages keep earlier Confluence versions.
Page comments	Comments on pages	Needs rework: confirm which comment types survive the export format you choose.
SSO, LDAP and MFA	Sign-in options listed as paid-edition features	Gap in the free edition: confirm licensing before you plan user sign-in.
Page-level permissions	Groups and spaces, with page-level permissions in the paid edition	Gap in the free edition: map each restricted page to a space or group.
Macros and Marketplace apps	No direct equivalent confirmed for Confluence macros or apps	Gap: list macros in use, rebuild them by hand and test each app's output.

What the Confluence export gives you to import

Confluence offers several export paths, and each one carries a different amount of structure into Docmost. Choosing the right path early avoids rework, because the export format decides what the import can read and what you must rebuild by hand.

Space export as HTML

HTML is the input Docmost's Confluence import uses, so this is the path that matters most for a space-by-space move. A space admin in Confluence Cloud can export a space in HTML, and the result is what you feed into Docmost's import dialog. Before importing, export a small test space and check page hierarchy, tables, code blocks and images. Confirm with Docmost's import documentation which Confluence importer version your edition includes, since Docmost lists the Confluence importer as a paid-edition feature.

Site backup from the backup manager

A full site backup is created by a site admin from the backup manager and gives you a complete copy of content, attachments and metadata. It is the safest archive to keep for audit and rollback, even if you do not import it directly into Docmost. Ask your team whether they need the full archive or only selected spaces, because a site backup covers everything on the site and can be large. Store it in a location that meets your retention and access rules before any transformation work begins.

XML export end of life

XML site and space export in Confluence Cloud reaches end of life on December 1, 2026. Features still work after that date, but Atlassian stops fixing bugs and accepting support tickets for them, and it recommends CSV export instead. Treat December 1, 2026 as the cutoff for any XML-based archive you rely on. If your plan depends on XML, run and verify exports well before that date and keep the output in a format you control.

Identities and permissions are rebuilt

Exports do not carry user accounts, groups and space permissions into Docmost in a way you should rely on. Plan to recreate users, groups and page-level access in Docmost, and map each Confluence space role to a Docmost role before import. Page content may keep its authorship text, but the live accounts behind it must be provisioned again. Confirm with Docmost's documentation which access controls and SSO options are available in your edition, because several are listed as paid features.

Jira links and Marketplace macros

Jira issue links, Marketplace macros and Confluence apps are integrations to rebuild, not migrate. A macro that renders live Jira data has no direct equivalent in an HTML export, so the page may show static text or a broken block after import. Inventory every macro and app used in your spaces, then decide per item whether to replace it with a Docmost feature, an embedded link or a manual copy. Document each decision so reviewers can trace what changed.

Single sign-on settings

Single sign-on is configured in the destination, not carried over from Confluence. Your Atlassian sign-in setup, identity provider connection and MFA rules do not transfer into a self-hosted Docmost instance. Decide which identity provider will front Docmost, confirm whether SSO requires a paid Docmost edition, and test sign-in with a pilot group before any users move. Keep your existing Atlassian access in place until the new login path is proven.

How a Confluence HTML space import reaches Docmost

The import runs in three steps: export a Confluence space as HTML, open Docmost's import dialog and select that export, then review the result on a test space before any real content moves. Docmost's import dialog accepts Markdown, HTML, Word, Notion and Confluence exports, and its import and export documentation describes the supported paths. Confirm in that documentation, and in your own test, which Confluence export format the current Docmost build expects, because a space export in the wrong format fails or imports only partly. Do the first import into a scratch space, never into the space your teams already use.

Check internal links first. Open several pages that link to other pages in the same space, and confirm that each link lands on the right target, not a blank page or a broken address. Then check the page tree: parent and child relationships, page order and titles should match the Confluence original. Next, open a sample of attachments, including large files, PDFs and images, and confirm each one downloads and opens. Note any page where an attachment is missing or renamed, since you will need to fix those by hand or re-upload them.

Test draw.io diagrams separately, because they are the element most likely to arrive as a static image. Confirm whether each diagram can be opened and edited in Docmost, or whether it appears only as a picture. Also confirm which of the Docmost importers you need for your edition: its documentation lists the Confluence, DOCX and PDF importers as paid-edition features, so a Word or PDF route for some content depends on the license you hold. Record the result per content type, so the migration plan reflects what your edition can actually do.

Migration sequence from inventory to decommission

This sequence moves a Confluence estate into Docmost in controlled stages, so each space is proven on a pilot before teams depend on it. Each step ends with a written artifact that the next step relies on, and Confluence is only decommissioned after its read-only state has been confirmed.

Inventory spaces, pages, attachments and users
Before any export, list every space, its owner, page count, attachment volume, blog posts, and the Confluence macros in active use, such as Jira issue lists, include pages and draw.io diagrams. Pull the user and group list too, so you know which accounts need Docmost access and which are stale. The output is a page-count inventory per space and a macro list, which together set the size of the pilot and the list of features Docmost must cover. Confirm the export formats your Confluence edition allows, since Atlassian's support documentation describes HTML and CSV space exports as available options, and XML export reaches end of life on December 1, 2026.
Map macros and links that need manual rework
Review the inventory against the features Docmost documents as supported, then record every Confluence construct that will not carry over cleanly, such as dynamic macros, Marketplace app content and custom page layouts. Run a crawl of internal links in the export to find links that point to pages outside the exported set or to pages that will be renamed. The output is a broken-link list and a rework register that names an owner and a decision (rebuild, simplify or retire) for each item. Confirm each decision with the content owner before import.
Run a pilot import of one representative space
Choose one space that has a deep page tree, attachments, internal links and at least one draw.io diagram, then import its HTML space export into a test Docmost workspace. Docmost lists its Confluence importer as a paid-edition feature, so confirm your licensing before you start. Compare the imported page tree, attachment count, internal links and diagrams against the source, page by page for a sample set. The output is a pilot report of the differences found and the fixes applied, signed off by the space owner and a platform administrator before the full run is scheduled.
Build a redirect map from old to new URLs
Once the pilot passes, generate a table that pairs each Confluence page URL with its new Docmost address. Use it to rewrite internal links in the imported content where the importer did not, and to set up redirects or a published notice on the Confluence side for the cutover. Test a random set of old URLs against the new map. The output is a versioned redirect map stored with the migration records, along with a list of pages that still need manual link repair.
Import remaining spaces in waves
Import the rest of the spaces in batches ordered by business criticality, starting with low-change reference content. After each wave, repeat the pilot checks: page counts, attachment counts, link checks and a sample of diagrams. Record discrepancies in the same rework register so none are lost between waves. The output for each wave is a reconciliation sheet that the space owner signs before the next wave starts.
Run a parallel period with teams reading both wikis
Keep Confluence available and tell teams which wiki is authoritative for each space during this period. Ask content owners to report edits or gaps they find in Docmost, and log them against the rework register. Note that Docmost content does not sync back to Confluence, so any edit made during this period in one wiki must be repeated in the other if both remain active. The output is a closed issue log with no open items for the spaces that will move at cutover.
Cut over during a freeze window
Announce a freeze window in which Confluence editing is blocked for the spaces being moved. Run a final incremental import of the changes made since the wave was loaded, repeat the reconciliation checks, publish the redirect map, and then switch Confluence to read-only for those spaces. Confirm with users that the new links resolve and that the Docmost sign-in and permissions match the agreed model. The output is a signed cutover record with the export timestamp, the reconciliation results and the list of approvers.
Archive the export and decommission Confluence
After read-only access is confirmed for every space and the business has accepted Docmost as the system of record, store a final export of Confluence content, the redirect map, the reconciliation sheets and the rework register in an archive that your retention policy covers. Only then remove Confluence licenses or instances. The output is an archive index with checksums and a decommission record that names who approved the shutdown and the date it took effect.

How the move differs by size and starting point

A small team on Confluence Cloud usually has few spaces, modest attachment volume and a small group of editors. The main effort driver is manual review rather than tooling. A handful of spaces can be exported and imported in one pass, so the work concentrates on confirming that the page tree, links and permissions landed correctly. Start by reading the Docmost import and export documentation to confirm which import formats your edition accepts.

Export scope: Export each space from the space admin area and keep the original export set as a reference copy.
Edition check: Confirm that your Docmost edition includes the Confluence importer, because Docmost lists it as a paid-edition feature.
Page tree: Compare the top-level hierarchy with Confluence by hand. On a small site this takes little time and catches misplaced parents early.
Users and permissions: Recreate the few groups and space permissions manually and record who owns each space.

Before inviting the team, check internal links, attachments and one draw.io diagram in each space, since these are the items most likely to break in a single pass.

What drives migration cost and duration, and how to reduce it

This table lists the factors that change how much work a Confluence to Docmost migration takes, why each one matters, and how to keep it manageable. Read it before requesting a quote, because the drivers on the left determine most of the effort. The main takeaway is that inventory and the paid-edition decision shape the project more than the import itself.

Driver	Why it changes cost or effort	How to keep it down
Number of spaces and pages	Each space needs a separate HTML export, import and check. Page count drives review time more than import time.	Archive stale spaces before export. Migrate in batches by team so reviewers handle one set at a time.
Attachment volume	Large attachment sets increase export size, upload time and the number of broken or missing file links to verify.	Inventory attachments per space. Remove obsolete files in Confluence first and confirm the export includes them.
Macro and Marketplace app use	Confluence macros and app content often have no direct Docmost equivalent, so each affected page needs manual rebuilding.	Count macro types across the export. Replace common macros with native formatting and list which apps have no Docmost counterpart.
Permission model	Space permissions, page restrictions and group rules must be recreated in Docmost, and inherited rules are easy to misread.	Document the current permission matrix before migration. Simplify rules, and confirm which page-level permissions are paid-edition features.
Identity integration	Single sign-on, directory sync and MFA setup need configuration and testing. Some of these may be paid-edition features.	Confirm the identity provider requirements early. Test sign-in with a pilot group before cutover.
Diagram count	Draw.io, Excalidraw and Mermaid content must be checked after import, since diagrams with embedded text or links can render differently.	Inventory diagrams by page. Re-export critical diagrams to a format you can verify and review the highest-traffic pages first.
Number of content owners to review	Each page owner must confirm links, tables and layout. Owner availability often sets the schedule more than technical work does.	Assign owners per space before import. Agree on a sign-off rule, such as owner approval or a sample-based check.
Paid-edition decision	Docmost lists its Confluence importer, SSO, LDAP, MFA, page-level permissions and databases as paid-edition features. Licensing choices change which steps are available without extra work.	Decide the edition before scoping. Confirm current feature lists and license terms with Docmost, and ask any implementation partner to price each option separately.
Internal links and cross-space references	Links between pages and spaces must resolve after import, and broken links are common in large or long-lived wikis.	Run a link check on the imported site. Fix high-traffic links first and record the rest for owners.

What usually goes wrong when moving Confluence to Docmost

Most problems in a Confluence to Docmost move show up after the import finishes, not during it. The six risks below share one cause: the HTML space export carries page content, but the links, files, macros and permissions around that content depend on the source setup. Check each one on a staging copy before any space goes live.

Broken internal links after import

Links between pages in the same space, and links into other spaces, may point at Confluence paths or page IDs that no longer resolve once pages sit under new paths in Docmost. A link can look correct in the editor and still fail for readers. Sample internal links across every space, including navigation pages and older pages that others link to, and click each one on the staging workspace. Record the failures and relink them by hand before publishing.

Attachments missing or renamed

Files attached to pages may not arrive, may arrive under a different name, or may stop being linked from the page that used them. An HTML export does not give you a complete attachment inventory on its own. Before import, count attachments per space in Confluence and keep that list. After import, compare the counts, open a file from each space, and check that filenames with spaces or accented characters still match the references in the page body.

Draw.io diagrams losing editability

A diagram can arrive as a static picture, or open without its source, so the next editor cannot change individual shapes. A picture can look fine on the page and still be a loss for teams that revise architecture or network drawings. Open each diagram in the staging copy, confirm it opens in the editor with shapes intact, and keep the original .drawio source files in your document store as a fallback.

Macros with no equivalent

Confluence macros such as table of contents, status labels, Jira issue lists and page properties do not all map to a Docmost feature. Some may drop out during import or flatten into plain text. A missing macro can silently remove a status table or an index that readers depend on. Inventory the macros used in each space before import, decide per macro whether to rebuild it, replace it with plain content or accept its loss, and record that decision.

Permissions not matching the old model

Confluence space permissions, groups and page restrictions do not translate one to one into Docmost's space and group model. Restrictions set on individual pages may not carry over, which can expose restricted content to everyone in the space. Confirm which access controls your Docmost edition includes, since the Docmost documentation lists some as paid-edition features. Map each Confluence space to a Docmost space and group, then test with a sample account from each group.

Unreviewed content going live

A full import brings in every page, including drafts, duplicates, outdated runbooks and personal notes, and staff may read them the same day. Once pages are published and linked, teams start relying on them before anyone checks them. Import into a staging workspace first, assign an owner to each space to sign off on its pages, and agree on an archive list for stale content. Publish only after sign-off, and keep the Confluence source available until then.

Questions buyers ask before migrating Confluence to Docmost

How much does a Confluence to Docmost migration cost?

The cost is mostly labor, not software, because Docmost's core edition is AGPL-3.0 and carries no license fee. Costs fall into three groups: the internal time spent exporting, cleaning and checking content; hosting and administration of the Docmost server; and any outside help for scoping, import work or hardening. The main cost drivers are the number of spaces, the volume of attachments, how many macros and custom layouts need manual rework, and whether you need paid-edition features. Ask any implementation partner for a fixed-scope quote that lists these components separately, with deliverables and timelines agreed in writing before work starts.

How long does a Confluence to Docmost migration take?

The duration depends on the size and condition of the content, not on the tool alone. The biggest timeline factors are the number of spaces to migrate, how many pages need manual repair after import, how much of the content has to be approved by its owners, and whether the target instance is ready with users, groups and permissions. Export timing matters too: Confluence Cloud XML site and space export reaches end of life on December 1, 2026, and Atlassian recommends CSV export after that date, so plan around the export format you will actually use. Pilot one space first to measure your own rework rate before committing to a schedule.

What does our team have to provide during the migration?

Your team needs to decide what content is still current, name a business owner for each space, and provide administrator access to Confluence (for the export) and to the Docmost server (for hosting and import). Engineering staff should be ready to review how internal links, attachments and diagrams render after import, and to run acceptance checks with page owners. Your team also owns decisions about permissions mapping, retention of archived spaces and how users will sign in. Confirm these responsibilities in the written scope so that each group knows what it signs off.

Can our internal team migrate Confluence to Docmost without outside help?

Yes, a team with Linux, container and database experience can run a small migration in-house, and the Docmost documentation describes the import dialog and export options. The work becomes harder with many spaces, large attachment sets, heavy use of Confluence macros, or strict security and compliance requirements, because those need repeatable checks and documented evidence. Be realistic about capacity: someone must own the server, backups, upgrades and user support after go-live. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your environment, and most engagements are fixed-scope, so you can compare an internal plan with an outside quote.

Does the Confluence importer require a paid Docmost edition?

Docmost's documentation lists its Confluence importer as a paid-edition feature, alongside the DOCX and PDF importers. The Docmost import dialog accepts Markdown, HTML, Word, Notion and Confluence exports, but you should confirm with Docmost which importers and other features are included in the edition you plan to run before you design the migration around them. Check the current feature list for SSO, LDAP, MFA and page-level permissions as well, since those are also listed as paid-edition features. Get the license terms in writing so the import plan does not depend on an assumption.

What happens to attachment history and comments when we move to Docmost?

Confirm this with Docmost and with a test import before you rely on it, because the import documentation does not give a full guarantee of what carries over. Current attachments and page content are the first things to verify in a pilot space. Attachment version history and page comments are often lost or flattened in migrations, so decide in advance whether you will archive the original Confluence export as the record of history. Compare the HTML export and the CSV export in your pilot to see which fields arrive intact. If audit trails matter, keep the source export under your retention policy.

How should we handle draw.io and other diagrams after import?

Docmost lists draw.io, Excalidraw and Mermaid diagrams among its features, but you should test how Confluence diagrams and draw.io attachments appear after import in your own instance. Check each diagram type in a pilot: embedded diagrams, linked draw.io files, images exported from diagrams, and Confluence-specific macros. Where a diagram does not render, plan a repair path such as re-exporting the source file, re-drawing the diagram in Docmost or keeping a static image with its source. Record which diagrams need manual work, because that list usually drives most of the post-import effort.

How DeployOpen scopes and runs a Confluence to Docmost migration

A Confluence to Docmost migration starts with a written, fixed-scope agreement that names the Confluence spaces in scope, the deliverables and the timeline before any work begins. DeployOpen uses that document to separate what is imported from what is rebuilt by hand, such as macros, Marketplace apps and permission models that Docmost does not reproduce. Because Docmost lists its Confluence importer as a paid-edition feature, the scope also has to state which Docmost edition the client will run, since that choice decides whether the import tooling, SSO, LDAP, MFA and page-level permissions are available. The quote follows from that written scope, and the client should ask for each space to be listed with its page count, attachment volume and any draw.io diagrams so the effort is visible before signing.

Delivery happens inside the client's own infrastructure, whether that is their cloud account, data center or an air-gapped network. DeployOpen plans the target Docmost deployment, runs the import into a staging instance first, and then compares the result against the source export. The checks cover the page tree, internal links, attachments and draw.io diagrams, which are the items the client should confirm against the importer's own documentation rather than assume. Hardening and backup of the Docmost deployment are part of the same scope, including the database and attachment storage, so that a restore has been tested before go-live. Client-side owners should confirm who will approve the reconciliation report and who signs off on the cutover date.

After go-live, ongoing support, upgrades and continuous testing are available as optional retainers, which is useful because Docmost releases continue after the migration and the client will need a defined owner for patching. Clients should ask a retainer proposal to state the response expectations, upgrade process and what happens to the staging environment, and should not treat a retainer as included in the fixed-scope migration unless the written scope says so. The most useful next step is a scoping conversation that inventories the Confluence estate, confirms the export format the client can still produce, and records the decisions that change the work.

Migrate from Confluence to Docmost