Webinar overview: Stay in control after Atlassian Data Center

Yes. OpenProject offers a REST API (API v3) that supports full CRUD operations on work packages (the OpenProject term for issues/tasks), similar to Jira’s API. This means you can create, read, update, and delete tickets, and also manage related entities like comments, attachments, relations, etc.

Essentially, any action you can perform in the OpenProject UI, you can also do via the API. The API is documented publicly with endpoints for work packages, projects, users, and more.

Yes, OpenProject has built-in webhooks configuration which you can access directly through the OpenProject UI via Administration → API and webhooks. Webhooks can be configured for all projects or limited to specific projects. They support events such as project creation or updates, work package creation or updates, as well as time tracking events.

Please refer to the documentation in our user guide for instructions on how to configure and use webhooks in OpenProject.

OpenProject supports the use of so-called “Custom Actions” which are buttons used for frequently performed actions. Learn more about custom actions in the user guide.

It is also possible to automatically update the progress of a work package based on the selected status (e.g. Status “In Progress” automatically sets the progress to 50%). Learn more about setting and managing work package statuses in OpenProject in our system administration guide.

You can also use the OpenProject API (e.g. in combination with OpenProject’s webhooks) to perform updates. Additional support for automations is planned for the future.

OpenProject supports custom work package types, custom fields, configurable workflows per role or type, and custom actions, so you can model many business processes similarly to Jira, such as procurement or HR requests. More advanced conditional automation can be handled via APIs and webhooks.

To learn more about workflows in OpenProject, please refer to this page.

For example, create or link issues, close them via commits, comment from GitLab, or start a feature branch from an OpenProject issue.

OpenProject offers a GitLab integration that links GitLab merge requests to OpenProject work packages. By using the integration, merge requests and issues in GitLab can be directly displayed on Epics, Features and Bugs. You are also getting notified about any updates to the referenced merge request – directly from the work package activity view.

OpenProject already offers an integration with GitLab (see answer above). While there is no integration with Forgejo planned, OpenProject also offers a web view to directly display a Git repository. Refer to the guide.

Especially, how are sprints handled? Is Scrum supported like in Jira? (which has sprint boards, backlogs, etc.)

OpenProject supports Scrum (and also Kanban). For Scrum support, the Backlogs module is offered which supports product backlogs and sprints, as well as story points, a task board and burndown charts.

For Kanban, an agile board is included which can be freely configured based on the configured workflow. For the future, there are also several improvements planned, such as swimlanes for agile boards and support for SAFE (Scaled Agile Framework).

For example, does it support PostgreSQL, MySQL, or Oracle? What about IBM Db2 for i?

OpenProject supports PostgreSQL (version 16 and newer). Please refer to the system requirements for more information.

Db2 is currently not supported. Please feel free to raise a feature request if this is important to you. Read how to request a feature in OpenProject.

Could OpenProject be used as a service desk for handling service requests, incidents, incoming emails, similar to Jira Service Management?

OpenProject currently provides lightweight IT Service Management functionality. You can manage service requests, incidents, and internal support tasks using customizable workflows, priorities, and roles, all within the same secure, open-source platform used for project management.

While OpenProject is not yet a full ITSM solution, it is a key area of ongoing development. We’re continuously expanding these capabilities to better support service-oriented teams and organizations. As an open-source product, customers and community actively influence the roadmap, helping shape the future of ITSM features and other enhancements.

For example, can OpenProject create or update tickets from incoming emails? Can we use multiple mailboxes or custom “from” addresses per project?

OpenProject provides an inbound mail feature that lets OpenProject receive IMAP/POP3 emails and create/update work packages. Meta information (such as in which project a task is created) can be submitted via the email body.

For documentation on how to setup and use incoming emails, please refer to the user guide.

In the near future, an extension of this functionality will be available which will allow defining multiple email addresses with different parameters (e.g. creation of incidents in a specified project and setting specific attributes such as priority, assignee and custom fields). Please feel free to cast your vote for this feature request.

How is licensing handled in such cases?

OpenProject currently does not provide full multi-tenancy support. A single installation of OpenProject equals a single instance. However, within each OpenProject instance, you can control on a project-by-project basis which users can access which projects (in combination with project hierarchies this can be used to separate access for e.g. different departments).

However, the global administration of the OpenProject environment (including workflow configuration) would be shared in this case.

Does it support single sign-on (SSO) like SAML or OAuth2? Can we integrate with corporate directories (LDAP/AD)?

OpenProject supports authentication via SSO (e.g. SAML, OIDC), connection to an LDAP/Active Directory (including LDAP group sync) as well as authentication via email/password (e.g. for external users). For corporate users, SCIM provisioning is available.

For increased security, two-factor authentication is supported as well.

It is also possible to add your own OAuth application. Please find more information in the OpenProject documentation.

The integration between OpenProject and Nextcloud leverages the strengths of both applications and allows users to connect files in Nextcloud to tasks and work packages in OpenProject (and vice versa). One or more Nextcloud environments can be connected to an OpenProject instance. You can then decide on a project-by-project level which Nextcloud environment should be connected to a specific project.

Using the integration, you can easily upload documents to Nextcloud from OpenProject – e.g. directly from a work package. You can also link or create work packages in OpenProject from your Nextcloud environment.

It’s also possible to automatically manage permissions between both systems by using automatically-managed Nextcloud folders within OpenProject. You can also link or create tasks in OpenProject directly from your Nextcloud environment.

For more information on the integration, please refer to the user guide.

XWiki does not yet provide a comparable, out-of-the-box integration, but both XWiki and OpenProject can coexist with Nextcloud through common SSO and are often used together in open-source stacks.

Both XWiki and OpenProject can run in clustered, high-availability setups when self-hosted.

XWiki supports multi-node deployments with shared storage, a shared database, and cache/event replication between nodes. It’s commonly used behind a load balancer for failover and scalability.

OpenProject also supports clustered deployments. You can run multiple application nodes connected to the same database and file storage, with background workers and web servers scaled horizontally.

In both cases, high-availability is fully possible on premises, as long as the underlying infrastructure (database, storage, load balancer, reverse proxy) is set up accordingly.

XWiki has a rich ecosystem of extensions. There is an Extension Repository accessible directly from your XWiki instance (Extension Manager UI) where you can search and install hundreds of open-source apps and macros contributed by XWiki SAS and the community.

Additionally, XWiki SAS provides Pro Extensions via the XWiki Store for customers. These include advanced apps like the OpenProject Integration (Pro) , Confluence Migration Toolkit (Pro) , Diagramming tool, Forum, Calendar, etc. It’s not a marketplace in the sense of third-party vendors selling apps (because extensions are developed mainly by XWiki SAS), but it functions similarly for discovering and adding features.

You can also develop your own extensions since XWiki is an open platform.

OpenProject automatically comes with several plugins and modules which can be activated for individual projects based on the project’s requirements. Beyond this, plugins developed by the open-source community are available. You can install them if you are using the on-premises version of OpenProject. Please keep in mind that we do not guarantee error-free and seamless use of the Community plugins. Installation and use is at your own risk.

You can also develop your own plugins.

Yes, you can host each application on whichever domain or subdomain you choose. XWiki and OpenProject are completely separate web applications, so there’s no requirement for them to share a domain. Many deployments use distinct domains or subdomains.

OpenProject can be used with the domain of your own choosing. For on premises, you can define the domain via your reverse proxy, load balancer, and configuration. For the OpenProject Cloud edition, you can select your own subdomain at the time of creation of your trial instance. Custom domains are available as an add-on through their support team, and require a DNS entry for your domain. Every OpenProject instance expects a single canonical host name.

For XWiki, you can also deploy it on any domain. Additionally, XWiki supports a virtual wiki feature where different subwikis can be mapped to different domain aliases (e.g. team1.wiki.company.com → Team1’s subwiki). This is optional; you can also simply use paths such as company.com/wiki/team1.

If XWiki and OpenProject need to integrate (e.g. via the integration extension or SSO), it’s fine if they are on separate domains. With SSO (SAML/OIDC), as long as both trust the same Identity Provider, users will have a seamless login experience even across domains.

For example, if we have an SSO proxy that passes a user header.

XWiki is very flexible in terms of authentication. XWiki’s platform allows custom AuthService implementations.

XWiki has built-in support or extensions for LDAP/AD, SAML, OAuth2/OpenID Connect, CAS, etc. For Microsoft Entra ID (Azure AD), there is a Pro connector: Microsoft Entra ID OpenID Connect (OIDC).

If you have a unique scenario, you can develop a custom Java component that implements XWiki’s Authenticator interface, or integrate via REST/API and scripting.

There is a partner ecosystem for both XWiki and OpenProject, and it’s growing. If you need local expertise for implementation or migration, you can reach out and you’ll be connected with a certified partner in your region (if available), or XWiki and OpenProject’s own professional services can assist remotely.

XWiki can be installed in offline environments using the XIP offline package. For each XWiki version, an XIP file is available containing all extensions that make up the standard flavor. You download it on a connected machine and transfer it to the offline server.

The Distribution Wizard can then use this offline repository instead of reaching extensions.xwiki.org.

For additional extensions, you can download XAR or JAR packages from the XWiki Extensions website and upload/install them manually, or mirror the repository internally. For Pro Apps, XWiki SAS can provide offline XIPs via contact@xwiki.com.

See the offline installation documentation: Installing without internet connection.

The first version of the OpenProject integration in XWiki is already available as a Pro app: XWiki Store → OpenProject Integration (Pro). Currently, it allows you to display OpenProject work packages within XWiki pages.

The specific feature of selecting wiki text and creating a new OpenProject issue from it is on the roadmap. The current integration is a first step; future iterations will deepen the integration in that direction.

The integration is designed with security in mind and uses each user’s credentials via OAuth2. If you create an issue from XWiki, the issue is created under your OpenProject account, respecting your permissions. Admins can control which instances and spaces use the integration.

Yes, XWiki supports real-time collaborative editing in the WYSIWYG editor starting with recent versions (13+ and improved in 14–16). Users see each other’s cursors and edits in real time, similar to Google Docs.

Most stock Confluence macros are supported in XWiki, either natively or via bridge macros. Currently, there is an equivalent or bridge for around 84 macros. Some niche third-party macros may need custom handling, but XWiki can show raw content and parameters or you can build custom macros.

If you would like to receive a free macro support analysis, you can share your list of Confluence macros with: sales@xwiki.com.

XWiki can be fully configured as an internal knowledge hub or intranet, either with XWiki Standard and built-in apps (Blog, File Manager, Calendar, etc.) or with Pro bundles that add ready-made intranet features.

You can learn more in this full guide: full guide on creating an internal network using XWiki.

For standalone XWiki, official Docker images are maintained and updated. For regulated environments (e.g. openDesk context), SBOMs are generated internally (e.g. with Syft) and can be provided as part of a project.

Signed images and formal SBOM delivery are usually handled via consulting/subscription contracts based on required compliance level.

Migration consulting is priced per project, based mainly on Confluence instance size (pages, spaces, attachments), number of users, and number of third-party plugins/macros. There is typically a free initial assessment (with a few exports and discovery sessions).

For a detailed quote, contact: sales@xwiki.com.

Standard hyperlinks to Jira issues inside Confluence pages are migrated as normal links and remain clickable in XWiki. Links created through Jira macros are not preserved as live macros, but they can be converted into text references or re-embedded using XWiki’s Jira integration so that issue lists/status views appear again on XWiki pages.

XWiki’s local authentication supports configurable password policies (length, character classes, etc.) via standard user management and extensions.

For 2FA, the usual approach is to integrate XWiki with an identity provider (e.g. Entra ID, SAML IdP, LDAP/IdM with 2FA) and delegate authentication via SSO, so MFA policies stay centralized.

You can read more in the documentation: Authentication documentation.

Yes, the Pro Microsoft Entra ID application supports SSO. XWiki integrates with Entra ID (formerly Azure AD) using SAML or OpenID Connect, with a dedicated connector that simplifies configuration and group mapping.

For more generic OIDC docs, see: OpenID Connect Authenticator.

XWiki supports multiple user-related macros such as UserLister, UserList, and UserProfile. When pages containing these macros are migrated, they are recognized and displayed similarly.

For Confluence user macros, XWiki can recreate them via custom macros as part of migration. See the macro scripting documentation: Wiki Macro tutorial.

As mentioned in Q14, XWiki supports clustered, high-availability setups. In practice this means running multiple XWiki nodes against a shared database and attachment storage, with cache and event synchronization between nodes, typically behind a load balancer for failover and scalability.

See more: Clustering documentation.

Most commonly, organizations plan migration per team/department: set Confluence spaces read-only, export them, migrate to XWiki, then cut over.

The Confluence Migration Toolkit (Pro) uses Confluence’s native export (space XML or site backup), imports content, attachments, comments, users/groups, permissions and more. After import, it provides a report of imported elements and issues detected (e.g. unsupported macros or broken links) so you can correct them.

XWiki can handle very large imports (including TB-scale sites) with the right environment sizing and parameters.

Toolkit: Confluence Migration Toolkit (Pro).

In openDesk, XWiki is the knowledge management application in a larger sovereign workplace stack that also includes OpenProject, Nextcloud, OpenLDAP and others. Identity and SSO are handled centrally, and XWiki participates as one of the applications connected to that shared IAM and portal.

See more: XWiki joins openDesk.

Yes. XWiki supports LDAP/AD integration for user and group synchronization via the LDAP Authenticator and supports SAML-based SSO and other IdPs via extensions.

Yes, you can use sub-wikis (wiki farm) or strict page-level rights to provide client-specific private spaces. Sub-wikis allow nearly full isolation per client; a single wiki with nested pages and groups lets you manage access per client area.

XWiki is well-suited for extranet scenarios: Extranet and communities.

The Confluence Migration Toolkit migrates user accounts and group references stored in Confluence, including AD-synced accounts. Once XWiki is connected to the same LDAP/AD, these accounts align again and permissions continue to work.

Alternatively, you can use the Pro Active Directory Application to import users and groups directly from AD, independently of the Confluence migrator.

On the Confluence side you can use built-in macro usage tools (Settings → Data management → Macro usage) or custom reporting queries.

As part of a free evaluation, XWiki analyzes your Confluence export and produces a macro-usage report showing which macros are supported and how to handle each one.

There is also a comparison page: comparison of commonly used Confluence macros and their equivalents or solutions in XWiki.

XWiki is open source under the LGPL 2.1 license. XWiki SAS offers professional support and Pro extensions under subscription (typically yearly per instance).

XWiki follows a monthly release cycle with one Long-Term Support (LTS) line per year and an intermediate LTS. The core team officially supports a small set of current versions (LTS, intermediate LTS, latest stable).

XWiki has:

– A Pro Forum Application for Q&A-type interactions (upvotes, best answer, moderation, etc.).
– A simpler FAQ Application for static Q&A pages.

XWiki doesn’t impose artificial limits on users or groups. Scaling depends on infrastructure and tuning (caching, indexing, clustering). It runs in environments with large user bases and complex group structures.

Yes. XWiki’s Solr-based search supports AND, OR, NOT, field-based queries, wildcards, parentheses and fuzzy queries. Default behavior is OR, but you can explicitly use boolean operators in uppercase.

XWiki SAS has a Partner Program and a network of solution providers in various regions (Germany, Switzerland, Finland, etc.), listed on its website: Partners page.

OpenProject has a Reseller/Partner program as well.

Confluence spaces usually map to top-level page hierarchies in XWiki. You can use:

– Sub-wikis for strong separation and distinct admin configs.
– Nested pages with rights to mimic spaces within a single wiki.

XWiki has a REST API that lets you create and update documents and objects; users and groups are represented as such objects. See: REST API documentation.

Yes, the initial Pro version of the OpenProject integration is available in the XWiki Store. It focuses on displaying filtered lists of work packages in XWiki pages.

Oracle is one of the officially supported databases for XWiki. In practice, MySQL/MariaDB and PostgreSQL are more commonly used and generally recommended due to simpler operations, but Oracle remains an option if it is a standard in your infrastructure.

XWiki is a structured knowledge platform rather than just a page store. It lets you model data, add forms and metadata, build apps and workflows directly in the wiki, while staying fully open source and ecosystem-neutral.

You can look at the Alternatives overview and the knowledge management tools datasheet for more detailed comparisons.

XWiki does not have built-in AI search or summarization yet; search is based on Solr. However, the Beta LLM Application allows connecting XWiki to LLMs for question answering over wiki content.

On the OpenProject side, AI is on the roadmap via an integration layer (MCP server) for smarter insights, automation and decision support within a self-hosted/EU-based setup.

XWiki provides:

– The Administration Application for rights at wiki/space/page level and page/attachment indexes.
– The Pro Admin Tools Application for advanced rights overviews.
– The community Page Rights Viewer to quickly see effective rights on a page.

BlueSpice is focused on MediaWiki-style documentation and quality management, while XWiki is a knowledge platform with structured data, custom apps, and more granular rights.

See: BlueSpice vs XWiki comparison.

XWiki is highly customizable visually via the Flamingo skin, themes, and CSS/LESS. You can adapt colors, fonts, logos, layout and UX with custom templates, navigation and dashboards.

A good example is the Historical Dictionary of Switzerland, which uses XWiki with a fully custom design.

XWiki already models roles through groups and rights (admin, editor, reader, etc.) at wiki/space/page level. The roadmap focuses on making rights easier to manage rather than introducing a separate roles layer mirroring Atlassian’s UI.

The integration is designed so you can configure where pages created from OpenProject land, typically within a chosen space or subtree representing the project or customer. Teams usually pick patterns like “one space per project” or “one subtree per customer.”

There is no flat public price because it depends on instance size and complexity. You can reach out to sales@xwiki.com for a free assessment and quote.

If you want to migrate on your own, see the pricing of the Confluence Migration Toolkit (Pro).

XWiki runs on Red Hat today via the standard WAR distribution deployed on supported servlet containers (e.g. Tomcat), and also via Docker or Snap in RHEL environments. There is no officially maintained Red Hat-specific RPM package from XWiki SAS at this time.

See installation docs: Installation guide.