Webinar overview | Take back control from Atlassian: The open-source alternative stack built by XWiki and OpenProject

OpenProject includes core project-management capabilities such as work packages, agile boards, backlogs, Gantt charts, meetings, team planning, workflows, custom fields, and integrations. Key capabilities are delivered as part of OpenProject rather than sold as separate plugins.

However, OpenProject does distinguish between Community and Enterprise editions, so the exact availability of individual features should be checked against its current pricing comparison. It should not be positioned as a one-to-one Jira clone: the best approach is to map the customer's actual Jira workflows and apps during an evaluation.

OpenProject already supports ticket-oriented workflows, including processing incoming emails into tickets or service requests.

A service portal is planned for Q3 2026 and SLA support for early 2027. Because roadmap dates can move, this should be published as a roadmap indication rather than a committed delivery date. You can check the current OpenProject roadmap.

No. OpenProject confirmed that its native wiki remains available, maintained, and developed. The XWiki integration is optional for organizations that need broader documentation and knowledge-management capabilities.

OpenProject is not positioning its built-in wiki to compete feature-for-feature with a dedicated knowledge platform such as XWiki. For current Confluence users, XWiki is the right choice. The bidirectional integration between OpenProject and XWiki leverages and combines the strengths of both systems.

Yes. OpenProject provides GitHub and GitLab integrations. Referencing work-package IDs in branches, commits, and pull or merge requests creates traceability between code changes and the related work package.

Additionally, it is possible to directly connect a Git repository and have an included web view of the repository within OpenProject.

OpenProject provides an MCP server, allowing MCP-compatible AI assistants to interact with OpenProject data under the permissions and authentication configured by administrators.

Support for additional AI capabilities is one of the core focus areas on OpenProject's roadmap.

There is almost no feature difference. With the cloud offering (with a dedicated EU shard and separate Global shard), OpenProject operates the infrastructure. With on-premises or self-hosted deployment, the organization operates its own environment and can use its own infrastructure, including air-gapped environments.

Unlike Atlassian's Jira DC vs Cloud, OpenProject's Cloud and on-premises version are fully interchangeable. It is easily possible to switch between the Cloud and on-premises version (and vice-versa).

OpenProject currently does not offer fully customizable email templates. It is possible to add a custom email header and footer (including language-specific versions) that are appended to all outgoing emails. Additionally, the sender email address can be configured as well as the notification aggregation.

Since OpenProject is open source, it would be possible to customize this functionality (e.g. by developing a custom plugin).

OpenProject can support ticketing and service-request workflows, including email-to-ticket handling. Whether it is suitable for a customer-facing helpdesk depends on requirements such as external-user access, portal needs, SLAs, branding, and reporting.

The planned service portal (scheduled for end of 2026), as well as the support for SLAs (scheduled for early 2027), is particularly relevant here.

OpenProject supports configurable workflows and custom fields. Workflows can currently be configured on an OpenProject instance level (based on the used type and role).

Project-specific workflows will be supported in Q3 2026, followed by support for workflow visualization in Q4 2026.

For automations, OpenProject provides a REST API as well as webhooks. Automations (e.g. update of certain fields based on updates such as status changes) will be supported in early 2027.

For an up-to-date overview, please refer to the OpenProject roadmap.

OpenProject provides many of the same capabilities as Smartsheet. In addition to support for agile capabilities, OpenProject includes a Gantt chart with freely configurable columns, along with support for dependencies and a baseline comparison.

For a full assessment if OpenProject fulfills all relevant use cases, please get in touch with the OpenProject team.

OpenProject allows organizations to configure work-package types, fields, workflows, and displayed columns. It should not be described as having Jira's exact "screen" concept.

Yes, backlog items can be ranked either via drag and drop or by changing the respective position via the context menu. Each entry in a backlog and sprint has a position assigned (which can be displayed in the work package list).

Yes, OpenProject work-package views can be configured with filters, including project-related filters. The XWiki integration can also retrieve work packages from the broader instance or from a specific project, then apply filtering and sorting.

Both the latest OpenProject version (currently 17.5.1) as well as the next upcoming release, OpenProject 17.6 (including the XWiki integration), were used during the live demo.

OpenProject 17.6 and XWiki's OpenProject Integration (Pro) version 2.0 will be released on July 8, 2026.

The latest OpenProject version is outlined in the OpenProject release notes.

OpenProject provides a Jira to OpenProject migrator which can be used directly from within the OpenProject administration. This migrator supports a migration from Jira Data Center (version 10.x and 11.x) and is regularly updated.

For more details, check our Jira to OpenProject migrator documentation.

OpenProject supports Scrum, Kanban, backlogs, sprint boards, work packages, epics, user stories, and hybrid planning alongside Gantt charts.

It is a viable Jira alternative for many agile teams, but exact parity depends on the Jira configuration and marketplace apps currently in use.

OpenProject exposes a REST API, including endpoints for work packages and project data. The API is being extended in parallel to feature development and you can check the OpenProject API documentation for more information. Reading or writing project data via API is supported.

OpenProject provides foundational support for test management (including test case and test execution). For a powerful alternative to test management plugins such as XRay or Zephyr, an integration with SquashTM is planned for Q4 2026.

OpenProject supports hierarchical work planning (e.g. Epic, Feature, User Story) across different projects. Aspects such as multiple hierarchy levels, parent-child relationships, progress roll-up from child work items, and Gantt charts for hierarchy visualization are supported.

For a more complete assessment based on the specific use cases within Jira Structure, please feel free to reach out to our team via email.

No, but you may face difficulties if you are using Confluence Cloud. Atlassian's announcement applies to Confluence Cloud only for now. XML site and space exports support will be discontinued on December 1, 2026, which means that a severe bug could prevent you from exporting your data. Atlassian states that the XML site and space export features will still be present, but they will no longer fix bugs, accept support tickets, or provide SLAs for them.

On the other side, CSV export remains supported. We are currently evaluating using the CSV export with our migration tools and we will publish the results of our evaluation soon. You can also reach out to us to discuss your needs and timeline.

In short, migration remains possible, but customers should plan early and assess the available export paths.

Yes. XWiki includes by default keyboard shortcuts for common page actions, navigation, editing, comments, history, and administration tasks.

For someone moving from Confluence, an equivalent example is the E shortcut: when hit in view mode, it opens the page in the default editing mode. XWiki also provides shortcuts to open the wiki or object editor, access page comments, attachments, history, page information, or rename a page.

While editing, users can save, preview, or cancel without returning to the mouse, for example with Alt + S to save and view the page or Alt + Shift + S to save and continue editing.

Some view-mode shortcuts are intended for advanced users and need advanced-user mode enabled, which helps prevent accidental actions while browsing. XWiki also supports standard editor shortcuts, plus shortcuts for mentions and links. Administrators can also add further shortcuts through the editor configuration.

XWiki can be used to create forms, but the best option depends on what should happen after someone submits one.

For simple template-based data collections, XWiki's built-in Templates feature lets you define a certain page as a template and create entries based on that consistent template. This is useful for things like requests, contact records, project briefs, issue logs, equipment registers, or internal directories. The submitted information is stored in XWiki as pages, so it can later be searched, filtered, displayed in lists using macros such as taglist, or reused in other pages using macros such as excerpt include.

For more complex forms or internal applications, XWiki also provides App Within Minutes. It allows administrators or power users to create a small collaborative application with forms, fields, and data-entry pages without writing code. Typical examples include request forms, inventories, onboarding records, event registrations, structured data procedures, or internal follow-up trackers.

Additionally, the Flash Messages Application (Pro) can be used to display the form, or a link to the form, when a user first logs into the wiki, or upon every visit.

In terms of notifications, you can choose the space where the forms will be created, set up a user with a group email address on your wiki (such as forms@company.com), and configure email notifications for that group in your XWiki instance, so that everyone in the group forms@company.com receives a notification when a new form is filled in. For more information on email notifications, please consult our documentation.

Finally, the right setup depends on whether the submission should also be stored in XWiki, whether several recipients or approval steps are needed, and whether the form is intended for internal users or external visitors.

The biggest factor in a migration is usually the amount of page history to migrate. An instance with relatively few pages can still take longer than expected when those pages have many historical versions, large attachments, complex permissions, custom macros, or extensive user and group mappings.

For example, an instance with 10 pages that each have 100 versions (resulting in 1000 versions) can take longer to migrate than an instance with 100 pages that only have two versions each (resulting in 200 versions). Attachments, macros, permissions, customizations, user and group mapping, and the level of testing required also affect the timeline, especially in terms of operations, not technical execution.

As an indication from our migration experience:

• A smaller instance of around 50 GB with a few thousand pages can often be migrated in about a week or less.
• Larger environments with hundreds of GB or several TB of data, many historical versions, complex permissions, or extensive macro use need more preparation and staged execution.
• One of the largest instances XWiki has migrated was around 3 TB with roughly 1 million versions. Including preparation, batch execution, testing, and validation, that project took around 6 months.

A migration is therefore not just an import step. It usually includes an initial assessment, source-data preparation, compatibility checks for macros and custom content, test migrations, validation with key users, and a final production migration.

The most accurate timeline comes after a gap analysis of the Confluence instance, so the best way to estimate a timeline is through an initial migration assessment. This looks at page and version counts, attachments, macros, permissions, users, integrations, and any content that needs special handling. That makes it possible to define a realistic migration plan rather than giving a guess based only on page numbers.

The OpenProject Integration (Pro) is not intended only for technical users, and everyday users should not need to understand macros, filters, or configuration parameters to use it.

The webinar demo showed the more advanced configuration layer because it was designed to demonstrate the full flexibility of the integration. That can make it look more technical than a normal day-to-day setup. In practice, an administrator or workspace owner configures the connection between an XWiki space and the relevant OpenProject project once. After that, users can work with preconfigured pages, templates, and views rather than rebuilding filters or macros every time.

For example, once a space is connected to an OpenProject project:

• New work packages created from that space will already include the relevant project and parent work package (Epic) context.
• Pages can contain ready-made lists and views of work packages, such as a project backlog, a list of open actions, or selected requirements.
• Teams can use templates so that recurring project pages follow the same structure.
• Users can focus on creating content, reviewing project information, and following links between documentation and work packages, rather than configuring the integration itself.

The point of macros and filters is to give organizations flexibility when they need it. They allow a team to decide which work packages should appear on a page, which fields matter, and how project information should be presented alongside documentation. But those options should mostly sit behind reusable setups, rather than becoming a requirement for every user.

The goal is not to ask project managers to "program" their documentation. It is to let teams create a setup that matches their workflow once, then make that setup easy to use every day.

The feedback is fair, though. Showing every available parameter from the start can make the experience feel more technical than it needs to be. We are working on making work-package insertion and macro configuration easier, including a simpler first interface that does not expose all advanced parameters immediately.

XWiki is not trying to reproduce Confluence screen by screen. It has a different foundation: It is built to let organizations structure information, adapt workflows, control permissions in detail, and keep ownership of their platform over time. That flexibility is valuable, but it can also mean that a fresh XWiki instance feels less immediately familiar to teams coming from Confluence.

For the easiest transition, we recommend that the people tasked with migrating from Confluence to XWiki study our software and contact us to obtain all the information on concept mapping before executing data transfers. Moreover, the organization's processes need to be well understood, and potentially challenged if there are better ways to achieve the desired results. Once these concepts are understood, the administrator can choose how operations should be done on XWiki once all data is migrated and configure the software accordingly. For example, it is common to use XWiki's native App Within Minutes to obtain the same functional result that Confluence's Page Properties and Page Properties Report provide. XWiki is actually much more powerful than Confluence in terms of creating structured data; Atlassian addresses this need via extensions and third-party plugins.

The practical approach is usually to avoid treating XWiki as a blank replacement for Confluence. A good rollout starts with a workspace that is configured by administrators in terms of structure, templates, navigation, permissions, and common page patterns that reflect how the organization already works. That way, users arrive in a space that is prepared for them instead of being asked to configure it themselves.

For everyday users, XWiki already provides a visual editor, real-time collaboration, comments, version history, templates, page-level permissions, and shortcuts for common actions. Contributors do not need to understand macros or configuration to create and update normal documentation pages.

The more complex layer appears when teams need structured content, advanced macros, integrations, or custom workflows. In demos, that configuration is often shown in full, which can make the product look harder to use than the typical day-to-day experience.

Improving that balance is an active focus. XWiki is working on simpler editing and configuration experiences, including improvements to Pro Macros such as View File, Team, and Status. The aim is to make common actions easier for regular users while keeping advanced options available for administrators and power users.

XWiki has historically offered a lot of power and flexibility, sometimes at the expense of immediate simplicity. We are actively improving that balance. The direction is to make everyday writing, finding, updating, and reusing knowledge feel more natural for contributors, while keeping advanced configuration available for teams or power users that need it.

Yes, XWiki can be used to bring a collection of Word, Excel, PowerPoint, PDF, and other Office files into a structured knowledge space.

One option is to simply store the files as attachments in XWiki pages, organized through spaces, pages, tags, metadata, and navigation rather than relying only on nested folders. This makes it easier to connect documents with related procedures, project information, ownership details, or update notes, and to search across the knowledge base.

Depending on the intended setup, Office documents can remain files that people download or open from XWiki, or they can be embedded and edited through an office integration such as Collabora or OnlyOffice.

A second option is to convert office files using the Office Import functionality into XWiki pages, which are easier to search, link, version, and maintain collaboratively.

A third option is batch migration, if your MS Office setup allows CSV export. The Batch Import Application can be used to migrate a full set of office documents into structured XWiki pages (with metadata), as demonstrated in this SharePoint migration guide.

The right migration approach depends on the file volume, folder depth, permissions, naming quality, and metadata requirements. The organization should decide whether it wants to preserve the current structure or redesign it into a more useful knowledge model.

A short assessment is usually required to define the import approach. This helps identify which documents should remain files, which should become XWiki pages, and how permissions and navigation should be set up.

XWiki does not currently provide a built-in "log in as this user" or full impersonation feature that lets an administrator browse the whole wiki exactly as another user would.

However, administrators can inspect and troubleshoot access rights. XWiki's permission model supports rights at wiki, space, and page level, for individual users or groups. This makes it possible to verify who has permission to view, comment on, edit, delete, or administer a specific area.

For a clearer overview, XWiki provides a couple of useful options:

• Page Rights Viewer shows the rights that apply to a specific page, using XWiki's Rights API.
• Admin Tools App (Pro) includes a Show Rights function that lists configured rights across the wiki, spaces, and pages.

These tools help administrators understand why a user can or cannot access a page, without needing to impersonate that person.

For cases where the goal is to reproduce a user-specific issue, the usual approach is to review the relevant user or group permissions, check inherited rights, and, when needed, test with a dedicated account that has the same group memberships and access model.

Yes, XWiki offers full migration services starting from evaluation, PoC, installation and configuration, training, post-migration fixes, and long-term support. We have extensive experience executing migration projects, from small (50 GB) to very large (3 TB) instances, and we are ready to provide all the services needed for a successful transition from Confluence to XWiki.

The level of support depends on your needs. Some teams use the Confluence Migration Toolkit themselves and ask for help with specific issues. Others work with XWiki on a broader migration project, covering the assessment, test migrations, configuration, validation, and production rollout.

A typical project can include:

• Reviewing the Confluence export and identifying content that needs special handling
• Checking macros, attachments, page history, users, permissions, and metadata
• Preparing the target XWiki structure and access model
• Running one or more test migrations
• Reviewing migration reports and resolving identified gaps
• Supporting the final migration and validation process

The exact scope is agreed after an initial review of your Confluence instance and what you want the future XWiki workspace to look like.

XWiki does not provide a standard, one-click migrator for OneNote in the same way it does for Confluence. The right approach depends on the available export options, how the notebooks are currently organized, and what needs to be kept: sections and pages, embedded files, images, tables, links, permissions, tags, and page history.

In many cases, the work is less about copying OneNote files as they are and more about deciding how that information should live in XWiki afterward. Some content may become native XWiki pages, while documents and files can remain attached to the relevant pages. This can make the content easier to search, link, update, and manage with clear permissions.

For a large number of files, we would need to know what data can be exported from OneNote and run a few sample migrations. That lets us check the available export format, review how well the structure can be preserved, identify content that needs special handling, and define a realistic migration approach before processing the full collection.

For a large OneNote migration, we recommend contacting us for an initial assessment. We can review a sample of notebooks, assess the available export format and content structure, identify anything that needs special handling, and recommend a practical approach for moving the content into XWiki.

The Confluence Migration Toolkit is designed to migrate core Confluence content such as pages, attachments, page history, users, groups, permissions, tags (labels), and metadata. It also generates a migration report so you can see all imported pages, which macros were found in the export, and how they were handled.

The main point to understand is that macro migration is not all-or-nothing. Many common Confluence macros already have an XWiki equivalent and can be migrated, including panels, table of contents, status, excerpts, attachments, task lists, diagrams, file viewers, page trees, and Jira macros. Some are supported with limitations, where the main content is migrated, but certain parameters or display options may differ. We currently support migration of 147 Confluence macros and have custom tools to perform partial handling of 140 more.

A smaller number of macros do not currently have a direct migration path. Examples listed in the macro comparison include the Confluence roadmap macro, popular labels, or change history. In most cases, XWiki offers a different way to achieve the same outcome, rather than reproducing the Confluence macro exactly, which would make reproducing an identical macro of limited use.

When a macro is not supported, the page content and parameters are still imported and stored in XWiki, just not displayed as they were in Confluence. In view mode, users may see an error message. In wiki edit mode, the original macro syntax and content remain visible. This means the information is not silently discarded, but it does need review and, in some cases, replacement or rework after migration.

Other areas that usually need attention are Marketplace apps, custom user macros, heavily customized themes, scripts, external integrations, and permission setups that rely on Confluence-specific behavior. These are not blockers, but they should be identified during the assessment rather than discovered during the final cutover.

There are also a few technical points to plan for:

• Page history can be migrated, but attachment history is not always handled in the same way and should be checked during the assessment.
• Large instances may need to be migrated in batches rather than through one full export and import.
• Space exports do not include users and groups, so identity and group mapping may need to be handled through a dedicated user, group, and permission migration (achievable through the Confluence Migration Toolkit) or through an identity provider.
• Rights can be migrated, but because XWiki and Confluence do not use identical permission models, restricted spaces and inherited permissions should be validated in a test migration.

The practical way to reduce risk is to run a migration assessment and test import first. This gives you a clear view of the macros in use, which ones are already supported, which need replacement or adjustment, and whether any custom work is needed before moving the full instance.

Yes, access rights can be managed at wiki, space, and page level, for individual users or groups. You can decide who is allowed to view, comment on, edit, delete, or administer a given area. This makes it possible, for example, to keep internal procedures and project discussions private while giving a customer group access to selected documentation pages or a dedicated customer space.

In practice, there are a few common approaches:

• Create a dedicated customer space or subwiki and give access only to the relevant customer group.
• Keep internal areas restricted and expose selected documentation to authenticated external users.
• Make selected documentation public by granting view rights to guest users, where anonymous access is appropriate.

For customer-specific documentation, a dedicated subwiki is often easier to manage than opening individual pages one by one. It makes permissions, navigation, and future maintenance clearer, especially when several customers need different access levels.

One important detail: access rules are inherited through the hierarchy. A child page can be made more restrictive than its parent, but it cannot be opened to people who do not already have access to the parent area. So the content structure and permissions model should be planned together from the start.

Yes, this is within the kind of scale XWiki has experience with. During the webinar, we mentioned a Confluence migration of around 2–3 TB of data, approximately 1 million-page versions, and around 100,000 users. That project included preparation, batch execution, testing, and validation, and took around 6 months.

That said, 15,000 registered users and 2 TB of attachments should still be treated as an enterprise deployment.

For an environment of this size, we would normally review:

• Expected concurrent usage and peak traffic
• Attachment storage and backup strategy
• Search and indexing requirements
• Permissions and access patterns
• Monitoring, failover, and disaster-recovery needs
• Whether clustering or separate search infrastructure is appropriate

XWiki can be deployed in clustered and highly available setups, but the right architecture should be based on expected usage rather than only total content volume.

So the short answer is: yes, XWiki can support this scale, and we have migration experience in the 2–3 TB range. For a reliable recommendation on whether to use one instance or a clustered setup, we would suggest a technical assessment of the current Confluence environment and expected usage.

XWiki supports rights at page level, so you can add specific access rules for one page without changing the rights model for the rest of the space or subwiki. This is useful when most content follows the same access pattern, but one page needs to be more restricted.

For example, a subwiki could be visible to a whole department, while one page containing sensitive information is limited to a smaller group. The page-level rule acts as an exception to the inherited setup.

There are a couple of important details:

• It is usually best to manage access through groups rather than assigning rights user by user.
• A page can be made more restrictive than its parent pages.
• For a large workspace, the cleanest approach is normally to keep broad rights inherited and only add page-level exceptions where they are genuinely needed.

XWiki provides an open-source Helm chart for Kubernetes deployments.

The chart is maintained in the XWiki Contrib ecosystem and is designed to support both local deployments and highly available setups. It can be installed from the XWiki Helm repository with Helm, and its configuration can be adapted to the infrastructure you use.

The chart is intended to help deploy XWiki in Kubernetes, but it should not be treated as a complete infrastructure design on its own. For a production deployment, you still need to plan the database, persistent storage for attachments and configuration, ingress, backups, monitoring, upgrades, and any high-availability requirements.

The default setup can use a bundled database dependency, while larger or production environments may use an external managed database and shared storage. The right architecture depends on expected traffic, storage volume, security requirements, and whether multiple XWiki nodes are needed.

XWiki maintains a Confluence macro alternatives page that compares commonly used Confluence macros with their XWiki equivalents and shows whether migration is supported. When a macro is not supported, the page content is still imported and stored in XWiki. The macro itself will not display identically in view mode, where an error message may appear, but its syntax and content remain visible in wiki edit mode. This means the content is not silently lost and can be reviewed, replaced, or supported later.

The list is updated as support evolves. For custom macros, Marketplace apps, or heavily customized Confluence content, we recommend reviewing a sample export during a migration assessment. That gives you a clear view of which macros can be migrated directly, which need adjustment, and whether any additional development would be useful.

Cristal is an XWiki project focused on providing a modern, modular user interface that can work with different content backends. Its goal is not to replace the XWiki platform overnight, but to progressively separate the user-experience layer from the underlying content and services layer.

The current roadmap is public, but Cristal is still evolving. The roadmap should be read as the current direction and active priorities, not as a fixed delivery commitment. For organizations planning an XWiki deployment today, the standard XWiki interface remains the production path, while Cristal is the project to follow for the longer-term evolution of the interface architecture.

XWiki is actively working on an MCP server that will allow AI agents to connect directly to XWiki. The goal is to make it possible to use XWiki as a controlled knowledge source for AI-assisted workflows, including local or private AI environments.

For organizations that do not want to send knowledge-base content to an external AI provider, XWiki is also exploring architectures based on self-hosted components. This can include a locally-hosted model service, a vector database for retrieval, and XWiki permissions to ensure that AI-assisted answers only use content the requesting user is allowed to access.

The broader direction is not only to connect AI tools to XWiki, but also to give teams more visibility and control over how AI is used in their knowledge environment. This includes ongoing work around observability, so teams can better monitor AI activity, usage patterns, and access to content.

That said, the MCP server and related AI capabilities are still under active development. The exact supported AI clients, available actions, deployment options, and production scope will depend on the version and configuration used.

We are currently gathering feedback on how AI should fit into knowledge-management workflows. For example, you may need AI to search internal documentation, answer questions over selected spaces, assist with drafting, or connect safely to local agents. Input from real use cases helps shape the product direction. You can book a short call with our product team to tell us what would better support your needs.

For an organization of this size, pricing is based on the deployment and support model rather than on a simple like-for-like replacement of an existing Confluence license.

The final scope can include the XWiki deployment option, support level, SSO or SAML integration, technical architecture, migration services, and any Pro Applications or additional services needed for the target setup. These elements can vary significantly depending on whether XWiki is self-hosted, deployed in a private environment, or provided as a managed service.

To receive a clear offer, please contact the XWiki team with a short description of your environment and requirements. We can review the expected number of users, hosting preferences, authentication setup, migration scope, and support needs, then provide a tailored proposal.

XWiki is involved in the Euro-Office initiative, which aims to provide a European online office-editing component for collaborative work on formats such as DOCX, XLSX, PPTX, ODT, ODS, and ODP.

The intention is for Euro-Office to work as an editing component inside platforms such as XWiki, while XWiki continues to manage the surrounding knowledge environment: document storage, permissions, navigation, sharing, version history, and access rights.

For XWiki deployments today, the documented office-editing integrations remain OnlyOffice and Collabora. At this moment, Euro-Office integration for XWiki is not yet available as a documented product offer. We cannot confirm a public release date, final feature scope, deployment model, or pricing at this stage.

Both XWiki and OpenProject offer options for academic institutions, including public universities.

From the XWiki side, we offer a 50% discount on support and hosting for academic institutions. This can apply to universities and other eligible education or research organizations looking for help with hosting, support, migration, or a larger knowledge-management rollout.

OpenProject offers special rates for educational institutions and NGOs. The aim is to help support institutions that contribute to education and social impact. Eligibility and the available discount depend on the organization and its requirements, so OpenProject invites interested institutions to contact its sales team for more information and a tailored offer.

Because each environment is different, the final offer depends on factors such as the number of users, hosting model, support level, migration needs, integrations, and whether the institution is considering one tool or the combined XWiki-OpenProject stack.

For a clear joint proposal, universities can contact either the XWiki or the OpenProject teams with a short overview of their requirements. We can then assess the expected scope and provide the most suitable commercial options for the project.

XWiki and OpenProject can both be connected to a central identity system, such as LDAP or Active Directory, or to a shared single sign-on provider.

From the XWiki side, LDAP authentication is available, and XWiki can also authenticate through OpenID Connect providers, including setups based on Keycloak, Microsoft Entra ID, or similar identity platforms. XWiki can synchronize user information and groups, depending on the authentication setup.

From the OpenProject side, LDAP connections are supported. OpenProject also supports OpenID Connect and SAML single sign-on as enterprise add-ons. LDAP group synchronization is available as an enterprise feature, allowing memberships from LDAP or Active Directory to be synchronized with OpenProject groups.

The XWiki–OpenProject integration uses OAuth. When someone accesses OpenProject data from XWiki, they authenticate with their OpenProject account, and the integration applies the permissions of that OpenProject account. This means users only see work packages they are allowed to access in OpenProject.

For most organizations, the recommended approach is to connect both tools to the same LDAP, Active Directory, Keycloak, Entra ID, or other identity provider, then manage access rules in each application according to its own permission model.

XWiki and OpenProject are separate applications, so they are deployed and operated independently, then connected through the integration.

From the OpenProject side, the Community edition can be installed using Docker or Docker Compose. OpenProject also provides a Helm chart for Kubernetes deployments. The Helm chart can bootstrap OpenProject with optional PostgreSQL and Memcached components, while production environments can use their own managed database and infrastructure services.

From the XWiki side, an XWiki Helm chart is available for Kubernetes. It is designed to support both local deployments and highly available setups. For larger environments, XWiki can also use external services such as a standalone Solr instance when search load requires it.

A clustered architecture is not automatically necessary just because both products are used together. The right setup depends on expected concurrent users, storage volume, search and indexing load, attachment usage, availability requirements, backup and recovery objectives, and the identity and network architecture.

For a production environment, especially one replacing a large Jira and Confluence installation, the infrastructure should be reviewed as a joint architecture rather than treated as one shared container or one preconfigured stack.

Both XWiki and OpenProject are open-source products and can be self-hosted.

The OpenProject Community edition is available free of charge and can be self-hosted. Enterprise editions add professional support and additional enterprise features.

Similarly, XWiki Standard is open source and can be self-hosted. This means a small organization can self-host the core XWiki and OpenProject products without license fees, but self-hosting also means taking responsibility for infrastructure, upgrades, backups, monitoring, security, and incident response.

The XWiki store already provides a catalogue of extensions, including applications, integrations, administration tools, macros, and Pro Applications. It is the main place to discover supported XWiki extensions.

OpenProject documents its integrations and community plugins, but it does not currently operate a marketplace comparable to the XWiki Store. Its integrations are generally documented by category, such as file storage, source-code management, identity, APIs, AI, and communication tools.

Nextcloud fits naturally as a shared file and collaboration layer alongside XWiki and OpenProject, and both tools also integrate with Nextcloud Hub.

With OpenProject, teams can use Nextcloud as integrated file storage: link files and folders directly to work packages, open and download them from within OpenProject, create work packages from Nextcloud, search for work packages there, and organize documents through project folders.

With XWiki, the Nextcloud Application allows users to search XWiki content directly from Nextcloud while remaining authenticated. In practice, this creates a complementary setup: XWiki for structured documentation and knowledge, Nextcloud for file collaboration and groupware, and OpenProject for project planning and delivery.

For email workflows, OpenProject supports incoming email via IMAP, so incoming messages can create or update work packages. It can also send notifications through an external SMTP server. Whether this can be connected to Microsoft Exchange depends on the organization's configuration, especially whether IMAP and SMTP are enabled, so this should be validated early with the mail and security teams.

XWiki can send notifications and workflow-related emails once configured. It does not provide the same built-in incoming email-to-ticket workflow as OpenProject, so organizations that need a customer-facing email intake process should discuss the expected workflow with the XWiki team.

For calendars, OpenProject provides meetings, calendar views, and subscription options, while XWiki can display calendar data through the Calendar Application (Pro) and iCalendar feeds. However, there is no standard out-of-the-box synchronization that turns XWiki and OpenProject into one shared Exchange calendar.

The right setup depends on what "shared calendar" means in practice: subscribing to an OpenProject calendar from Exchange, displaying calendars in XWiki pages, synchronizing events in both directions, or managing team availability. Clarifying that requirement early makes it possible to recommend the most suitable integration approach.

XWiki and OpenProject can also be evaluated as an alternative to a Redmine and Redmine Wiki setup.

Our webinar focused on Jira and Confluence because of the current Atlassian situation, but the combination is not limited to Atlassian replacement projects. OpenProject can cover project planning, work packages, agile boards, Gantt charts, meetings, and project collaboration, while XWiki can provide the wider documentation, knowledge base, templates, structured content, and access management around that work.

The main difference is that this would not usually be a like-for-like replacement of Redmine's built-in wiki. The aim would be to keep project delivery in OpenProject and use XWiki for the more complete knowledge-management layer: project documentation, processes, requirements, decisions, technical documentation, and reusable knowledge.

Migration from Redmine should be assessed separately. The available options depend on the Redmine version, installed plugins, custom fields, issue types, attachments, permissions, wiki content, and whether the required data can be exported or accessed through the Redmine API.

Both XWiki and OpenProject are designed to fit into an existing IT environment, but they focus on different parts of the collaboration stack.

On the XWiki side, common integrations include:

• Identity and access management through LDAP, Active Directory, OpenID Connect, and SAML-based setups
• Office editing with OnlyOffice or Collabora
• Nextcloud access
• REST APIs and scripting for custom integrations
• Confluence migration tooling
• OpenProject Integration for bringing project information into XWiki

XWiki is also working on AI-related integrations, including MCP-based connections and controlled knowledge-retrieval use cases.

On the OpenProject side, integrations include:

• LDAP, OpenID Connect, SAML, SCIM, and OAuth applications for identity and provisioning
• GitHub and GitLab for linking pull or merge requests to work packages
• Nextcloud for file storage and collaboration
• OneDrive and SharePoint for selected Enterprise plans
• Incoming email through IMAP and outbound notifications through SMTP
• APIs and webhooks
• Excel synchronization
• An MCP server for AI assistants

Both XWiki and OpenProject provide export, import, and API capabilities, but the available options depend on the type of data, the deployment, and the use case.

For example, XWiki supports XAR import and export, a REST API, structured-data queries, and dedicated migration tooling for Confluence. OpenProject provides exports for work packages and other project data, a REST API, webhooks, Excel synchronization, and migration tooling for selected Jira environments.

Because this covers a wide range of topics, from backups and content portability to reporting, system integration, and full platform migrations, it is difficult to provide a complete and useful answer in the Q&A entry. The right options also depend on whether the goal is to move data between systems, build a custom integration, export reports, create backups, or migrate from Jira and Confluence.

This is a useful topic for a future dedicated webinar. It could cover the main export and import formats, APIs, migration tools, and practical examples of how XWiki and OpenProject can connect to other systems while keeping organizations in control of their data.

The OpenProject Integration (Pro) for XWiki is already publicly available. It allows teams to connect XWiki to OpenProject, display and filter work packages in XWiki pages, and create work packages from XWiki content.

With OpenProject's July 17.6 release, OpenProject plans to make a beta version of the XWiki integration available within OpenProject. This is the next step toward a broader 2-way integration experience.

Both teams are continuing to develop the connection based on real-world use cases and feedback from early adopters.

This needs to be assessed and tested as part of the migration. We cannot guarantee that existing Jira–Confluence links will automatically become OpenProject work-package-XWiki page links in every environment.

The result depends on how the links are stored in Jira and Confluence. They may be standard issue or page links, URLs inside page content, macros, custom fields, comments, Marketplace-app data, dashboards, or custom scripts. It also depends on whether the related Jira issue and Confluence page are both migrated and whether their identifiers can be mapped reliably.

The practical approach is to make link preservation an explicit migration requirement. We would review representative Jira issues and Confluence pages, identify the link types that matter, test them in a pilot migration, and agree on what can be migrated directly, what needs mapping or custom handling, and what should be reviewed manually.

The XWiki OpenProject Integration (Pro) can display OpenProject work packages directly in XWiki pages using the OpenProject macro.

You can choose which work packages to show by filtering on properties such as project, type, status, creator, assignee, or identifier. You can also sort the results, set a display limit, and select which work-package properties should appear in the view. Filters can be configured directly in XWiki or based on a filtered work-package URL copied from OpenProject.

The macro currently supports 3 display modes:

• A table view for a structured list of work packages
• A card view for a more visual overview
• A single-item view for showing one work package in more detail

This makes it possible to include selected OpenProject information in documentation pages, for example requirements, open actions, project risks, milestones, or work packages related to a specific decision or feature. OpenProject remains the place where the work packages themselves are managed, while XWiki provides the surrounding documentation and knowledge context.

There are a few current limitations to keep in mind:

• The single-item view displays only the first work package returned by the selected list.
• Saved OpenProject queries referenced through query_id are not currently supported by the macro.
• Data retrieved from OpenProject is cached for 2 hours, so recent updates may not appear immediately in XWiki.
• When filters are defined both in OpenProject and in XWiki, the XWiki filters are applied in addition to the OpenProject filters.

Self-hosting gives organizations control over where XWiki and OpenProject run, where their data is stored, and how the surrounding infrastructure is configured. Both products can be deployed on your own infrastructure, including with Docker-based setups and Kubernetes options.

The main difference compared with a hosted service is operational responsibility. When you self-host, your organization is responsible for running the environment.

From the XWiki side, the documentation provides several installation approaches, including Docker images, Debian-based packages, and Kubernetes deployment through the XWiki Helm chart. XWiki's backup guidance also makes clear that a proper backup needs to cover the database as well as the permanent data and configuration files.

From the OpenProject side, supported self-hosting methods include Docker Compose, DEB/RPM packages, a single Docker container, and Helm charts for Kubernetes. OpenProject's installation documentation also provides separate guidance for backups, upgrades, and system requirements, including supported PostgreSQL versions.

There is no general feature restriction simply because the tools are self-hosted. However, some OpenProject enterprise add-ons require an enterprise subscription, and optional XWiki Pro Applications or support services are separate from the open-source core product.

For larger or business-critical deployments, the main question is not whether self-hosting is possible, but whether the organization has the operational capacity to maintain 2 production applications and their supporting services. In that case, it is worth planning the architecture, backup model, monitoring, upgrades, and support responsibilities before deployment.

Neither XWiki nor OpenProject publishes security advisories on a fixed monthly or quarterly schedule. Advisories are published when a relevant vulnerability has been identified, investigated, and addressed. For self-hosted deployments, the practical recommendation is to monitor the relevant advisory channels and release notes, then apply security updates promptly according to your organization's change-management process.

XWiki and OpenProject can both connect to the same LDAP or Active Directory directory, or to the same SSO provider, such as Keycloak, Microsoft Entra ID, or another OpenID Connect or SAML-compatible solution. Users can then sign in to both tools with their existing corporate account instead of maintaining separate passwords.

This gives organizations a familiar setup: one place to manage identities and authentication, while each application applies permissions according to its own purpose.

For example, the same employee could authenticate through the company directory in both tools. They can have access to selected project workspaces in OpenProject, and see only the documentation spaces or pages they are allowed to access in XWiki.

The exact setup depends on the identity system already in use and whether you also need group synchronization, automatic user provisioning, external customer accounts, or single logout.