Webinar overview | XWiki vs. Confluence: open-source knowledge management and migration demo

Yes, XWiki can support ISMS documentation patterns, especially when you need versioning, controlled publication, and approvals. If your process is closer to “changes must be approved before they become visible”, Change Request is designed for review and approval before applying changes. If you need periodic review dates and reminders, add Publication Workflow Review.

For Comala-style publishing, the closest XWiki options are Publication Workflow and Change Request. For Scroll Viewport, the functional behaviour can be recreated by creating internal and external sections or wikis. Note that Scroll Versions has an equivalent in XWiki, called Book Versions, and data can be migrated from the Confluence plugin to the XWiki extension.

Yes, permissions do map and can be migrated from Confluence to XWiki using the Confluence Migrator (Pro) integrated in the Confluence Migration Toolkit.

XWiki rights are hierarchical and more granular compared to Confluence.

The official reference for how Confluence permissions are converted is the Confluence permission handling page. It explains what maps, what is ignored, and why.

To understand the target model, start with Access Rights and permission precedence.

If continuity matters on day one, migrating permissions is often the right call. Many teams then simplify and modernize rights once the new structure is stable and governance is agreed.

XWiki’s default UI is based on Flamingo, and it is designed to be customized.

You can start with the Flamingo Skin and the Flamingo Theme Application.

For deeper changes, you can extend and customize the UI using skin extensions, or contact the XWiki SAS team for custom solutions.

Practical note: Most adoption wins come from improving navigation and page templates. We advise you to study well the workflows that exist in Confluence and make sure they are recreated properly.

XWiki supports granular rights management and applying rights at different levels. The most important starting point is understanding how Confluence concepts map to XWiki concepts. A Confluence space is not the same thing as an XWiki space, and the Confluence importer documentation explains that mapping.

From there, you design your segregation model using Access Rights and, when needed, subwiki rights.

If you have hundreds of Confluence spaces, one subwiki per space is rarely practical. Most teams group content into a manageable number of subwikis aligned with real security boundaries and handle the rest through rights inside those wikis.

For delegated administration, you can design around space rights, page subtree boundaries, and group-based governance. For fully isolated silos, multi-wiki can be a better match than trying to reproduce “one Confluence space equals one silo” at high counts.

XWiki supports clustering for high availability. 

If you want a practical setup reference, the clustering tutorial is useful for understanding how events and caching behave in cluster mode.

A common approach is to use Diagram Application (Pro), which integrates draw.io and supports diagrams embedded inside pages. draw.io includes wireframe libraries, so wireframes can be created and displayed within XWiki. 

If you have existing Balsamiq content, it will be displayed in XWiki through the dedicated bridge macro present in the Confluence Migration Toolkit. In many migrations, teams either keep exported images for legacy wireframes or rebuild critical ones in draw.io for long-term maintenance.

Treat it as change management, not as a documentation problem. The fastest path is hands on training with real content and real workflows, especially for power users who manage structure, templates, macros, and permissions. Your key takeaways are exactly right here: XWiki is not Confluence, and the gap needs active management.

A good structure is: Pilot with power users, role-based live sessions, clear internal procedures about XWiki usage, and a tight feedback loop during the first weeks after go-live.

Yes. XWiki has an extensions repository and a commercial store for Pro Apps and supported extensions.

In migration terms, this usually means macro compatibility and macro bridging. Start with the macro mapping page, which lists common Confluence macros and their alternatives or strategies in XWiki.

XWiki provides Confluence bridge macros to preserve common macro behavior after import.

If you are planning a migration project, the Confluence Migration Toolkit bundles the relevant migration tooling and components.

Yes, links will be properly migrated and we have implemented post migration fixes for Link Mapping, part of the Migrator included in the Confluence Migration Toolkit. Confluence reference handling documentation describes how Confluence style references and URLs are converted into XWiki references.

Templates and code blocks are also migrated by default using the Confluence Migration Toolkit.

We don't support storing XWiki attachments in Nextcloud out of the box, but we will soon work on a full integration with NextCloud. 

It's possible to use XWiki as the wiki for OpenProject. OpenProject GmbH and XWiki SAS are actually both working on integrations as we speak. Actually, you can already test the Beta version of the OpenProject Integration (Pro).

We would need to know more about the issues faced to answer, but generally layout issues can appear when migrating nested tables and macro-heavy layouts. The usual method to fix this is to identify the exact patterns (is there a layout migrated wrong, is there a macro missing?), then handle them via macro mapping and bridge macros, and rerun the migration.

Most teams group multiple Confluence spaces into one XWiki wiki. Subwikis are “buckets” when you need stronger separation.

In practice, we usually collect multiple Confluence spaces in a single XWiki wiki. When we do use subwikis, it is typically to create a small number of “buckets” that match real boundaries, like a department, business unit, region, or security domain. Creating one subwiki per Confluence space rarely makes sense at scale.

It is also completely possible to migrate all Confluence spaces into XWiki’s main wiki. The choice between "only a main wiki" versus **"a few subwikis as buckets"**depends on the kind of content you are migrating and how much separation you actually need in day-to-day operations.

If you are considering subwikis, read how multi-wiki is designed and operated.

You can migrate your Confluence content into XWiki, but handling the Jira Service Management depends on your needs and context. You can choose to keep Jira Service Management and replace only Confluence, in which case you will have to create or sponsor the development of an integration between XWiki and JSM.

If your goal is to move off Atlassian and keep a service management and knowledge base setup, there is an already more established path: You can pair XWiki with a dedicated work or service management tool.

We are working closely with OpenProject GmbH, and service management is on their roadmap.

If you would like to test the two products, you can also try out the Beta version of our integration: OpenProject Integration (Pro).

In practice, we usually recommend staying under roughly 15 to 20 subwikis per instance. It is not a hard technical limit, it is an operations and governance limit. Every subwiki adds overhead: configuration, permissions, upgrades, monitoring, and support.

If you need more, it can be done. It should be a deliberate architecture choice for a very specific multi-tenant or isolation use case, not a default “one Confluence space equals one subwiki” strategy.

Yes. It is usually not a product limitation, it is a modeling choice. You can redesign the structure and rights strategy so it behaves the way your teams expect.

In XWiki, you have a few valid options:

#1 Keep one wiki, but change how you partition content. Instead of relying on a deep subtree structure, you can organize by pages and children and apply rights and ownership where it actually helps.

#2 Use subwikis when the structure needs a stronger separation or different administration per group.

#3 Simplify the rights strategy so it stays manageable as you restructure. When teams say “not useful”, it often means the rules and exceptions got too hard to maintain. This checklist of common rights misconfigurations is a good reference when refactoring.

Yes, but we highly advise to use it as part of the Confluence Migration Toolkit, which bundles all the apps (including macros) and services that you need to quickly transfer data but also benefit from long-term technical support.

What you'll find in the Confluence Migration Toolkit:

• Confluence Migrator (Pro) for a seamless migration

• Confluence-specific bridge macros for data migration to XWiki

• Task Manager (Pro) that will ensure you and your team keep up your daily productivity immediately after the migration

• Long-term technical support on the core product, Pro Apps, recommended extensions, and community extensions

We can't update CKEditor to version 5 because of a license incompatibility (CKEditor 5 is GPL, while XWiki is LGPL).

However, we are planning to replace CKEditor with BlockNoteJS to improve the editing experience later this year. Delivery will likely happen around Q1 2027, as we want to avoid breaking the current editing experience.

For further details, you can check the forum thread where BlockNote has been discussed publicly as a future rich editor direction.

Also, you can test the experimental BlockNote Integration extension.

There is no need to do that as permissions can be migrated independently from users. After you have migrated your pages, you can run a separate migration for users and/or permissions (this is achieved through editing the Advanced parameters of the migration) and access rights will be correctly applied. You can even migrate permissions without having the users present on the wiki yet, and they will apply as soon as the users get created on XWiki.

Scroll Ignore macro is converted into the Export Ignore macro if the Export tools macro application is installed.

XWiki exposes content through its REST API, so you can fetch pages, metadata, and other resources over HTTP.

We have also recently developed a Beta MCP server and you can learn more about our LLM app here.

We are exploring multiple directions for AI in general, so we would be glad to learn more about your usecase. Please write us an email and we'll be happy to continue the conversation.

The links to content that has not yet been imported will not work until the target page gets created into XWiki, but the issue will not persist after all data has been migrated. If you do see issues with links after migrating all content, you can fix them using the dedicated "Post migration fixes" included in the Migration tool.

Collectives is great for lightweight, Nextcloud-native handbooks.

XWiki is the better fit when you need structured knowledge at scale, stronger governance, and a platform you can extend.

The Nextcloud Application in XWiki allows a Nextcloud instance to search content in XWiki as a logged in user and access to XWiki from Nextcloud as a connected user.

You can always write us an email with your specific use case and our team will be able to provide you more details.

For our team to be able to tailor the answer to your use case, please include users, spaces, export size, macro inventory, permission complexity, and hosting constraints, if any.

You can also always request a demo with one of our Account Manager for a more personalized approach on your migration path.

We have developed tools to avoid manual editing of pages post-migration. The most common post-migration fix that would need to be done is handling macros that do not exist on the XWiki side. This can be achieved via batch rename scripts, or the creation of the specific macro on the XWiki side.

Yes, definitely! You can export a single page, a set of pages or the whole wiki. You can choose to export in ODT, PDF, RTF, HTML or XAR format (for migration usually).

For more information, you can read the relevant documentation on exports.

All the migrations we do are based on Confluence XML exports, so it is not a database to database migration. The source database engine (Oracle in your case) does not matter much as long as you can produce a clean Confluence export. The import happens from the XML plus attachments into XWiki running on your target stack, including PostgreSQL.

What does matter is the quality and completeness of the export and what is inside it: macros, permissions, links, templates, and any app-specific content. That is why the safest path is still a representative pilot export, import, and validation on your most complex spaces before you commit to the full plan.

Yes, but the approach is different. XWiki is frequently used to build intranets as a configurable platform.

Linchpin is a packaged intranet on top of Confluence, while XWiki is a platform you shape with applications, structure, governance, and UI customization.

In the case of BMC, it was a specific migration project, because BMC already had a dedicated development team that was doing customization on top of Confluence. What we did is that we trained this development team to do customization on top of XWiki. Therefore, the end result is a customization. So it's definitely not something you can do out-of-the-box in XWiki. There are things that you can do that are relatively easy, such as the navigation bar. You can set it up so that it's visible in the middle of a page, but then the specific UI that you can see in the above example is something that has been done as a custom work.

For publicly shareable material, the XWiki reference page is a great starting point. You'll be able to browse and read more details about solutions implemented for other companies with similar use cases.