Which open-source alternative to Confluence fits your team
Choose XWiki if you need a structured, enterprise-grade wiki with a documented Confluence import path, Docmost if your users expect a Notion-like editor and can use a paid edition for the Confluence importer, and BookStack if your documentation is book-style and you want something simple to run. Most Confluence estates are not uniform, so the right answer usually depends on how many spaces you migrate, how much permission structure they rely on, and how much your users will tolerate a new editor. Teams start looking at alternatives for reasons that are often tied to dates. Atlassian ended support for all server products, including Confluence Server, on February 15, 2024. For Data Center, Atlassian stopped accepting new subscriptions for new customers on March 30, 2026, and Data Center licenses, Confluence Data Center included, expire and become read-only on March 28, 2029. For Confluence Cloud, XML site and space export reaches end of life on December 1, 2026, after which Atlassian will no longer fix bugs or accept support tickets for it and recommends CSV export instead. If your export plan depends on XML, that date should move to the top of your project plan. Before you pick a tool, confirm three things with your own environment: which Confluence deployment you run, which export format your content can actually leave in, and whether your compliance team needs the migration to keep attachment history or page version history. Ask each candidate vendor or implementer to demonstrate an import of one representative space, including its permissions, before you commit to a platform.
Three self-hosted Confluence replacements compared
Each of these three platforms can run in your own infrastructure and replaces part of what teams use Confluence for. They differ in depth of features, setup effort, import paths and license obligations, so the right choice depends on the content you are moving and the controls you must keep.
XWiki for structured knowledge
XWiki is a mature, LGPL-2.1 licensed wiki platform with structured data, application development and fine-grained rights, which suits organizations whose Confluence use has grown into a document system. Its Confluence Migrator Pro is a paid extension from XWiki SAS that imports XML and CSV backups from Confluence Server, Data Center and Cloud, including permissions and users and groups. It does not preserve attachment history, so decide early whether that history is needed. The main trade-off is setup effort: expect more planning for spaces, rights and extensions than a lighter wiki requires. Confirm the extension licensing and supported Confluence versions with XWiki before you scope the migration.
Docmost for Notion-style teams
Docmost is an AGPL-3.0 licensed wiki with a clean editing experience that suits engineering and operations teams writing many interlinked pages. Its import dialog accepts Markdown, HTML, Word, Notion and Confluence exports, but its documentation lists the Confluence, DOCX and PDF importers as paid-edition features. Budget for that edition if you need a Confluence import, and ask Docmost how the paid edition is licensed and supported. AGPL-3.0 requires that modifications to the software you run and make available to users are published under the same license, so have legal review any custom changes before you deploy them.
BookStack for simple hierarchies
BookStack is an MIT licensed wiki organized as shelves, books, chapters and pages, which maps cleanly onto many Confluence space trees. Its permissive license places few obligations on how you modify or redistribute it, and its footprint is small, which keeps operations simple. The trade-off is depth: it offers fewer structured data and workflow features than XWiki, so teams that rely on Confluence macros or custom page types should test those cases first. Review how your Confluence content converts, especially tables, macros and embedded diagrams, on a sample space before you commit to a full move.
Confluence XML export deadline
Confluence Cloud's XML site and space export reaches end of life on December 1, 2026. After that date the feature still works, but Atlassian will no longer fix bugs or accept support tickets for it and recommends CSV export instead. If your migration depends on XML, such as XWiki's import path, start the export and test it well before that date. Plan for a fallback: CSV or HTML exports carry less structure, so confirm with your target platform which elements each format preserves before you choose.
How each Confluence capability maps to open-source options
This table maps the main Confluence capabilities to XWiki, Docmost and BookStack, with a coverage note for each. Read the notes as a starting point for a feature check, since partial coverage and plugin-dependent features need confirmation in each project's documentation.
| Capability | Open-source options | Coverage note |
|---|---|---|
| Pages and spaces | XWiki (spaces and nested pages), BookStack (shelves, books, chapters, pages), Docmost (spaces and pages) | All three organize content hierarchically, but the containers differ. BookStack's shelf and book model maps to Confluence spaces only with some restructuring. Confirm the mapping before migrating. |
| Rich-text editing | XWiki (WYSIWYG and wiki syntax), Docmost (block editor), BookStack (WYSIWYG and Markdown) | Basic formatting, tables and links transfer broadly. Complex Confluence macros and custom layouts often need manual rework. Test representative pages. |
| Macros and embedded content | XWiki (macros and applications), Docmost (limited embeds), BookStack (limited embeds) | Partial. Confluence macros rarely map one-to-one. Confirm each macro you rely on against the target project's documentation rather than assuming parity. |
| Attachments | XWiki, Docmost and BookStack all store page attachments; XWiki Confluence Migrator Pro imports attachments | Imports carry attachments, but the Migrator Pro does not preserve attachment history. Plan to keep an archived export if version history matters. |
| Permissions and spaces | XWiki (rights at wiki, space and page levels), Docmost (space-level roles), BookStack (role-based book and page permissions) | XWiki offers the most granular model. Confirm how Confluence space permissions and groups translate, especially for restricted pages. |
| Blog posts | XWiki (blog application, via extension), Docmost and BookStack (standard pages) | Partial. Dedicated blog features depend on XWiki applications or manual structuring elsewhere. Confirm before promising parity to users. |
| Templates | XWiki (templates and page templates), BookStack (page templates), Docmost (templates in paid or current editions) | Varies by project. Confirm template creation and reuse for your teams, and do not assume Confluence blueprints convert automatically. |
| Search | XWiki (built-in search with extensions), Docmost (built-in full-text search), BookStack (built-in full-text search) | Built-in search covers core content. Confirm indexing of attachments and performance at your content volume. |
| Page history and versions | XWiki, Docmost and BookStack maintain page revisions | Confirm how much history imports from Confluence. Attachment history is not preserved by the XWiki migrator, so keep the source export. |
| Users and groups | XWiki (users, groups and directory options), Docmost and BookStack (local accounts and roles, directory integration varies) | Confirm your identity provider integration (SAML, OIDC or LDAP) against each project's documentation, as support varies by edition. |
| Jira and other Atlassian integrations | No direct equivalent in the three options | Gap. Jira macros and links need an alternative approach. Confirm integration needs before choosing a platform. |
| Export and exit path | Markdown and HTML (Docmost, BookStack), XWiki XML and standard formats | Keep an exit path. Confluence Cloud XML export reaches end of life on December 1, 2026 (Atlassian), so CSV, HTML or PDF exports may be needed for archival. |
What XWiki and Docmost import from Confluence exports
XWiki's import path for Confluence is the Confluence Migrator Pro, a paid extension sold by XWiki SAS. It imports XML and CSV backups from Confluence Server, Data Center and Cloud, and it covers pages, spaces, attachments, permissions, blog posts, and users and groups. The limit to plan for is that it does not preserve attachment history, so anyone who relies on earlier attachment versions needs to archive them separately before the move. The extension builds on XWiki's open-source Confluence XML filter stream, which is the underlying component that does the conversion. Before you budget, confirm with XWiki which Confluence export formats your site and version produce, and ask for a sample import of a representative space so you can check page structure, macros, permissions and attachment handling in your own environment.
Docmost's import dialog accepts Markdown, HTML, Word, Notion and Confluence exports, and its pages export as Markdown or HTML. Read the edition terms closely here, because Docmost's documentation lists its Confluence, DOCX and PDF importers as paid-edition features. That means a team that starts with the community build and expects a direct Confluence import may find that the import step itself requires a commercial license, while Markdown or HTML exports can still move content through the community edition with more manual cleanup. Either way, the practical decision is whether the migration effort justifies the paid tier, and that depends on how many pages, macros and attachments you have. Verify current edition terms and feature lists directly with each vendor before you commit, since packaging can change between releases.
What self-hosting Confluence alternatives costs over several years
This table breaks the total cost of a self-hosted Confluence replacement into its components, marking each as one-time or recurring and naming who gets paid. Use it to structure your own multi-year model and to write quote requests, since totals depend on your content volume, integrations and internal capacity. No figures are shown because they vary by environment.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Software license | No fee for XWiki, Docmost or BookStack core under their open-source licenses | Recurring only if you buy paid extensions or editions | Whether you need paid importers such as Migrator Pro or Docmost's paid-edition Confluence importer |
| Paid extensions or editions | Extension or edition vendor (for example, XWiki SAS or Docmost's paid edition) | Usually recurring, confirm term and renewal in writing | Number of Confluence sources, features needed, and whether the license covers your deployment model |
| Infrastructure and hosting | Your cloud provider, data center or hardware budget | Recurring | Number of users, attachment storage, high availability and environments such as staging |
| Backups and recovery testing | Your team or a services partner | Recurring, with a one-time setup | Backup frequency, retention rules and how often restores are tested |
| Migration and implementation | Implementation partner or internal engineers | One-time | Number of spaces, permission complexity, macro conversion and attachment volume |
| Content cleanup | Content owners and editors, sometimes a partner | One-time, with ongoing hygiene | Stale pages, duplicate spaces and content that must be archived rather than moved |
| Integrations and SSO | Internal identity team or partner | One-time build, recurring maintenance | Number of connected tools, SSO protocol and provisioning requirements |
| User training and change management | Internal enablement staff | One-time, plus onboarding for new staff | Team count, workflow changes and how much documentation you must rewrite |
| Administration, upgrades and patching | Internal platform team or retained support provider | Recurring | Release cadence you adopt, plugin count and how quickly you apply security updates |
What teams give up when they leave Confluence
Moving off Confluence rarely fails on page content. It fails on the things around the pages: integrations, macros, version history, review workflows, hosted guarantees and the editing habits people rely on. Each card below names one likely loss, the workaround teams usually use, and what to check before cutover.
Marketplace apps and Jira links
Many Confluence sites depend on Marketplace add-ons and on Jira issue macros that pull live ticket status into pages. Those add-ons do not run on XWiki, Docmost or BookStack, so each dependency has to be replaced, rebuilt as a small service, or dropped. Inventory every add-on and every Jira macro before choosing a target. Plan for webhooks or the target platform's API to keep ticket data current, and confirm that your Jira access model works with the new system.
Macros and page templates
Confluence macros such as table of contents, status labels, page properties and templated blueprints shape how many teams write pages. Equivalent macros differ across platforms, and some have no direct match. Treat templates as a rebuild task: list the templates in use, map each macro to a native feature or a plugin, and rewrite the most used templates before migration. Expect some pages to need manual cleanup after import, especially those with heavy layout markup.
Attachment version history
Confluence keeps earlier versions of attachments, which matters for contracts, specifications and signed scans. XWiki's Confluence Migrator Pro imports attachments and permissions but does not preserve attachment history, so only the current file version carries over. Decide which attachments need their history kept, archive the originals from the Confluence export or Cloud backup, and link to the archive from the migrated page. Confirm this with the extension's current documentation before you plan around it.
Inline comments and page workflows
Teams often use inline comments, page-level approvals and review states to run policy sign-off or release notes inside the wiki. These features differ widely between platforms, and some are only partly available. Map each workflow to a concrete mechanism, such as page restrictions, an approval form or a ticket in your work tracker. Run one live review cycle on a pilot space before retiring the Confluence process, so that reviewers know where comments now live.
Vendor-hosted SLAs and support
Atlassian's hosted service comes with vendor-run uptime commitments, backups and a support queue. When you self-host, those duties move to your team or to a partner. Write down who patches the platform, who restores backups, who answers at night and what recovery point you need. Confirm the backup scope in your Confluence export or site backup first, since XML export support has a fixed end date (December 1, 2026) and a later migration will rely on CSV exports.
Familiar editor behavior
Experienced Confluence authors have muscle memory for slash commands, keyboard shortcuts, macro insertion and page-tree navigation. Each target editor behaves differently, and unfamiliar behavior slows adoption more than most migration tasks. Run a short parallel period in which both systems stay available, publish a one-page cheat sheet for the new editor, and collect feedback from a few power users. Check that Markdown and HTML round-trips preserve tables, images and embedded files in your sample pages.
Which Confluence alternative fits your situation
When the main requirement is that documentation stays in infrastructure you control, every platform on this page can be deployed in your own cloud account, in a data center or on an air-gapped network. The decision then shifts to operations: who patches the platform, who restores backups and where attachments and search indexes live. Confluence Cloud exports can be a useful exit path, but they are a copy, not a residency solution on their own.
- Deployment scope: Confirm that the platform's database, file storage and search components can all sit inside the boundary you must control.
- Identity: Check how single sign-on and directory groups integrate with your existing identity provider.
- Backups: Plan backup and restore for attachments and the database together, and test a restore before migration.
- Upgrades: Assign an owner for security patches and version upgrades, since self-hosting moves that work to you.
- Egress: Verify that no telemetry, plugin or import step sends content to external services unless you allow it.
Before you commit, ask the vendor and your own security team to confirm each of these points against your environment rather than relying on this summary.
When the trigger is a renewal or pricing change, the comparison has to cover the full cost of ownership, not only the open-source license fee, which is usually zero. Atlassian's announcements set a timeline for Data Center, with new subscriptions for new customers ending on March 30, 2026 and Data Center licenses expiring on March 28, 2029, so existing Data Center customers should map those dates against their renewal calendar. Self-hosting shifts cost from subscription fees to infrastructure, staff time and external services.
- Recurring costs: Hosting, storage, backups, monitoring and staff time for upgrades recur every year.
- One-time costs: Migration, content cleanup, template conversion and user training usually happen once, though their size depends on the content.
- Paid extensions: Some migration tools and editions are commercial, such as XWiki's Confluence Migrator Pro and Docmost's paid-edition importers.
- Cost drivers: Page count, attachment volume, number of spaces and the level of customization change the effort more than the license model does.
- Quote request: Ask for a written scope covering migration, hardening, backup setup and support hours, so you can compare it with your current Atlassian bill.
When your organization needs a large, governed knowledge base with defined content types, permissions and cross-space structure, XWiki is the platform most often considered for that role. Its data model supports structured content and extensions, and XWiki's Confluence Migrator Pro can import Confluence XML and CSV backups, including pages, spaces, attachments, permissions, blog posts and users and groups. The migration effort grows with the complexity of your macros and permission model.
- Structured data: XWiki suits teams that need typed content and custom applications built on the wiki.
- Migration coverage: The Confluence Migrator Pro imports attachments and permissions, but it does not preserve attachment history.
- Open-source base: The underlying Confluence XML filter stream is open-source, while the Migrator Pro is a paid extension from XWiki SAS.
- Macro mapping: Inventory custom Confluence macros early, since each one may need a rebuild or an equivalent.
- Operating skill: Plan for administrators who understand the platform's configuration and extension model.
Before you commit, ask XWiki to confirm how your specific Confluence export, macros and permission scheme will map in a sample import.
When the goal is fast, simple documentation for engineering or operations teams, BookStack and Docmost are the lighter options on this page. BookStack organizes content into shelves, books and chapters, and Docmost offers a modern editor with a page tree and Markdown or HTML export. Both are simpler to run than an enterprise wiki, which suits teams that want to start small and expand over time.
- BookStack: Licensed MIT, with a familiar book and chapter structure that suits technical manuals and runbooks.
- Docmost: Licensed AGPL-3.0, with a Notion-style editor and an import dialog that accepts Confluence exports.
- Paid importers: Docmost documents its Confluence importer as a paid-edition feature, so confirm the edition you need before planning.
- Permissions: Test space-level access carefully, since simpler models can be less granular than Confluence's.
- Export discipline: Keep a Markdown or HTML export as a fallback, so content is never locked in a single tool.
Before you decide, confirm current license terms and edition features with each vendor, since release cycles are frequent.
When your organization operates under banking, healthcare, public sector or critical infrastructure requirements, the platform choice matters less than the controls and evidence around it. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. An independent auditor or certification body makes that determination, so you should engage one early in scoping.
- Access control: Document role-based access, single sign-on, and how administrator rights are granted and reviewed.
- Logging and retention: Define which audit logs are kept, where they are stored and how long they are retained.
- Change management: Record upgrade, patch and configuration changes as evidence for the assessor.
- Backup and recovery: Show tested restore procedures, not only backup schedules.
- Assessor engagement: Agree the control scope with your assessor before migration, so the evidence you collect matches what they will test.
Before you start, ask your assessor which control frameworks apply and which evidence formats they accept.
How to migrate off Confluence in seven phases
The sequence turns an undocumented Confluence estate into a scoped, tested and retired one, with each phase producing a signed-off artifact. Internal owners decide what moves, what is archived and what is deleted, so the migration tool is the easiest part of the work.
Inventory spaces, pages, attachments and integrations
Start by listing every space, its owner, page count, attachment volume and last-edited date, and record which pages are live, stale or duplicated. Also catalog macros, page templates, apps, macro-driven reports, webhooks and any system that reads or writes Confluence through the API, because these break silently at cutover. Space owners confirm which spaces are active, and the platform or IT team owns the integration list. The step is done when every space has a named owner and an agreed keep, archive or delete decision.
Export content in a supported format
Choose the export path that matches the target tool and the content type. 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. Note that XML site and space export reaches end of life on December 1, 2026, after which Atlassian will no longer fix bugs or accept support tickets for it and recommends CSV export instead. If you plan to use XML-based importers, run exports well before that date and keep a copy of the raw export. The step is done when each space has an export archive, checksums are recorded, and the export log shows no failed items.
Map spaces, permissions and page hierarchy
Translate Confluence spaces, groups and page restrictions into the target model. Each target has its own structure, so decide whether a Confluence space becomes a wiki, a book, a space or a collection, and confirm how the target handles page-level restrictions, inherited permissions and external guests. The identity team confirms how groups will be sourced in the new platform, usually through the existing directory. The step is done when a written mapping document has been reviewed by the security owner and every permission rule has a target equivalent or a documented exception.
Run a pilot with a representative space
Choose one space that has typical content, such as a mix of long pages, attachments, tables, embedded diagrams and restricted pages, and import it into a non-production instance. Compare page counts, attachment integrity, internal links, permissions and rendering against the source. Ask the space owner to review fifteen to twenty pages they know well. Tool-specific gaps often appear here, for example in attachment history or in macros that have no direct equivalent. The step is done when the pilot report lists each defect, its owner and its fix or accepted workaround.
Run a parallel period with cutover rules
Import the remaining spaces in waves and keep Confluence read-write while users validate content in the new platform. Write the rules before the period starts: which space is authoritative for each topic, how edits made during the overlap are reconciled, and who can approve a late change. The communications owner announces the date that new content goes to the new platform. The step is done when each wave passes a content count and link check, and the reconciliation log is empty for the last agreed window.
Cut over users and redirect links
Switch the authoritative source space by space, set Confluence to read-only where the platform allows it, and publish a notice that points users to the new location. Identify inbound links from Jira, Slack, email signatures, runbooks and customer-facing documents, and either update them or place redirects where the target supports them. The service desk owner handles access requests and questions during the first weeks. The step is done when the top linked pages resolve correctly, and the open-issues list for access and missing content is below the threshold the owners agreed.
Archive, check retention and decommission Confluence
Before any Confluence instance or subscription ends, store a final full export and verify it can be opened outside the vendor tool. Confirm retention obligations with legal, records and compliance owners, including how long archived content must be kept, who can access it and how it is deleted at the end of the retention period. Revoke integrations and service accounts, then cancel or let the subscription lapse according to your contract terms. The step is done when the archive has been tested for restore, the retention record is signed by the data owner, and access to Confluence has been removed.
Questions buyers ask before moving off Confluence
How much effort does a Confluence migration take, and what drives it?
Effort depends mainly on how much content you carry over, how messy it is, and how many permission models must be rebuilt. A small wiki with a few spaces and clean page trees is a different job from an estate with years of spaces, custom macros, orphaned pages and group-based restrictions. Attachment volume, the number of users and groups, and whether you migrate blog posts and archived spaces all add work. Ask any partner to inventory spaces, page counts, attachment sizes, macros and permission schemes before quoting, because those numbers, not the tool choice, usually set the effort.
Can our team migrate from Confluence without outside help?
Often yes for a small, low-risk wiki, and the import tools reduce the hand work. XWiki's Confluence Migrator Pro imports XML and CSV backups from Confluence Server, Data Center and Cloud, covering pages, spaces, attachments, permissions, blog posts and users and groups. Docmost's import dialog accepts Confluence exports, although its documentation lists the Confluence importer as a paid-edition feature. Outside help becomes more useful when you need permission mapping reviewed, integrations rebuilt, hardening, backups and runbooks, or a fixed timeline with written deliverables. DeployOpen works on fixed scopes agreed in writing before work starts.
What does the migration need from our internal admins, content owners and security team?
Each group has a distinct job. Platform admins own hosting, identity integration, backups, upgrades and the target configuration. Content owners decide which spaces are current, which are archived and which should be deleted, because a migration is a good moment to remove stale material. Security staff should review the permission model, single sign-on, audit logging, encryption and access to the export files, which often contain sensitive content. Agree these responsibilities at the start, since unowned decisions about content and permissions are the most common cause of delay.
How long should a pilot and parallel run take, and what sets that length?
The length depends on the number of spaces in scope, the number of teams that depend on them, and how many integrations or external links point into Confluence. A pilot should move one representative space with its real permissions and attachments, so the team can test search, links and access before the full import. A parallel run keeps both systems available while users confirm content and workflows. Ask for a written schedule with entry and exit criteria for each phase, and treat any duration you are given as a plan to verify in your own environment rather than a fixed promise.
Do attachment history and page permissions survive the move?
Permissions can usually be carried over, but attachment history often cannot. XWiki's Confluence Migrator Pro imports attachments and permissions, but its documentation states that it does not preserve attachment history. Confirm the specific behavior with each tool and version you plan to use, and test it on a pilot space. Check how users and groups map to the target's identity model, and whether restrictions that Confluence applies at space or page level have an equivalent in the target. Document what is lost so content owners can decide whether to keep older versions in an archive.
What changes after the December 1, 2026 end of life for XML export?
Atlassian's support knowledge base states that XML site and space export in Confluence Cloud reaches end of life 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. For a migration, this means your export path should be tested well before that date, and any scripted backup that depends on XML should be reviewed. Space admins can still export content as PDF, CSV, HTML or XML, and site admins can create full site backups, so confirm which format your import tool expects before choosing one.
What should a migration quote include?
A useful quote lists the written scope and the deliverables that follow from it, not just a total. Ask for the inventory assumptions, the spaces and content types in scope, the target platform and version, the import method and its known limits, permission mapping rules, testing and acceptance criteria, cutover and rollback steps, backup and hardening work, documentation and handover, and what happens to content that cannot be imported. Also ask which costs are one-time, such as migration and configuration, and which recur, such as hosting, licensing for a paid extension, and support. DeployOpen does not publish a price list, and a quote follows from the written scope.
Does the target platform's license affect the migration cost?
It can. XWiki's Confluence Migrator Pro is a paid extension sold by XWiki SAS, so that cost sits on top of the open-source platform. Docmost's Confluence importer is listed as a paid-edition feature, while its core is licensed AGPL-3.0. BookStack is MIT-licensed, and La Suite Docs is MIT-licensed as well. Check each tool's license file and edition list before you assume a feature is free, and ask any partner to separate license fees from implementation and support in the quote.
Official sources for Confluence migration and alternatives
Start with Atlassian's own timeline before you commit to a replacement. The Atlassian journey to cloud announcement explains why server products lost support on February 15, 2024, and the Atlassian Ascend announcement sets out the Data Center dates that matter for a renewal: new Data Center subscriptions for new customers end on March 30, 2026, purchases and expansions for existing customers end after March 30, 2028, and Data Center licenses, Confluence Data Center included, expire and become read-only on March 28, 2029. Confirm these dates against the contract and order forms your procurement team holds, since your own terms may differ from the general announcement.
Next, check the export path your content depends on. Atlassian's support article on XML site and space export end of life states that the XML export reaches end of life on December 1, 2026, after which Atlassian will not fix bugs or accept tickets for it and recommends CSV instead. Your team should decide which export format to use for a pilot, test a full site backup from the backup manager, and record which formats each space owner relies on. The Atlassian support guide to exporting a space covers the PDF, CSV, HTML and XML options available to space admins.
For the target platforms, read the source and import documentation directly. The XWiki platform repository and the XWiki Store page for Confluence Migrator Pro describe the paid importer, its supported backup types and its limit on attachment history. The Docmost import and export documentation lists which importers belong to the paid edition, so confirm the edition you plan to run before you design the migration. Check the BookStack repository, the La Suite Docs repository and the Plane importers overview for current licensing and import support, and test each one against a sample export from your own tenant.
How DeployOpen scopes, migrates and supports your replacement
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Confluence replacement, that means agreeing the scope in writing first, building the chosen platform in your environment, and handing over documentation your team can run without us.
How we scope
- Inventory which Confluence spaces, page trees, attachments, blog posts and user groups are in scope for migration.
- Agree in writing which platform (XWiki, Docmost or BookStack) fits your permission model, identity setup and data residency needs.
- Confirm the Confluence export route you will use, including Cloud XML or CSV export before the December 1, 2026 end of life date.
How we build
- Deploy the chosen wiki inside your own infrastructure, with hardening applied to hosting, authentication and backups.
- Run a test migration on a sample of spaces, then check pages, attachments, permissions and links against the source.
- Document known gaps, such as attachment history not being preserved by XWiki's Confluence Migrator Pro, and agree how each is handled.
How we hand over
- Deliver runbooks covering installation, upgrades, backup and restore, and user and group administration in your environment.
- Provide evidence of tested backups and access controls that your compliance team can review with its own auditors.
- Walk your administrators through day-to-day operations so your team can maintain the platform after the engagement closes.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer once the platform is live in production.
- Track open-source release updates, such as new XWiki, Docmost or BookStack versions, and plan upgrades within agreed scope.
- Confirm with your vendor and your own environment any feature you depend on, such as paid importer editions, before committing to a plan.
