Atlassian's decision to end its self-hosted Server product and raise Data Center pricing has pushed thousands of engineering organisations to look for an open-source alternative to Jira and Confluence. The combination of OpenProject for project and work management and XWiki for knowledge management is one of the strongest replacements available today. Both are AGPL/LGPL-licensed, run on your own infrastructure, and integrate cleanly through REST APIs and OIDC single sign-on.
Why Pair OpenProject with XWiki
OpenProject and XWiki solve complementary problems. OpenProject focuses on work packages, Gantt charts, agile boards, time tracking, and roadmap planning. XWiki focuses on structured documentation, page hierarchies, macros, and a powerful class/object model that lets you build custom applications on top of wiki pages. Together they replicate the Jira-plus-Confluence workflow without vendor lock-in or per-seat pricing that scales into six figures.
Feature parity matrix
| Capability | Atlassian | OpenProject + XWiki |
|---|---|---|
| Issue tracking, agile boards | Jira | OpenProject |
| Structured knowledge base | Confluence | XWiki |
| Full-text search | Lucene | Apache Solr (embedded or SolrCloud) |
| Custom fields and forms | Custom fields | XWiki class/object model and OpenProject custom fields |
| Permissions model | Project + space level | Project roles in OpenProject, programming/admin/edit rights in XWiki |
| API | REST | REST in both, with HAL hypermedia in OpenProject |
| Self-hosting | Data Center only | Yes on any Linux server |
Architecture Overview
A typical deployment keeps the two applications on separate JVMs and separate PostgreSQL databases to isolate failure domains. A shared Keycloak or Authentik server handles OIDC for both, so users sign in once and get seamless links between a work package and its wiki documentation page.
- OpenProject: Ruby on Rails, Puma app server, PostgreSQL, background workers.
- XWiki: Java (OpenJDK 17/21), Jetty or Tomcat, MariaDB or PostgreSQL, embedded Solr.
- Reverse proxy: NGINX or Traefik with HTTP/2, TLS 1.3, and HSTS.
- Identity: Keycloak with SAML/OIDC federation to your corporate IdP.
For organisations expecting more than 200 concurrent users, run each application on its own cloud server, put PostgreSQL on a managed replica pair, and switch XWiki's embedded Solr to a two-node SolrCloud cluster. That architecture matches what we describe in our XWiki scaling guide.
Linking Work Packages to Wiki Pages
The most important integration is bidirectional linking. From an OpenProject work package, you want a clickable "Specification" link that jumps to the relevant XWiki page. From XWiki you want a live list of related work packages. Two patterns work well:
- URL convention: name XWiki pages with the work package ID (for example
PROJ-1234-spec) and render OpenProject custom text fields as hyperlinks. - XWiki macro calling OpenProject's REST API: a Velocity or Groovy macro queries
/api/v3/work_packages?filters=...and lists matching items inside the wiki page.
{{groovy}}
def url = "https://openproject.example.com/api/v3/work_packages?filters=[{\"project\":{\"operator\":\"=\",\"values\":[\"42\"]}}]"
def json = new groovy.json.JsonSlurper().parse(new URL(url).openStream())
json._embedded.elements.each { wp ->
println "* [[${wp.subject}>>${wp._links.self.href}]]"
}
{{/groovy}}Migration from Jira and Confluence
OpenProject ships a Jira importer that maps projects, issues, comments, and attachments. XWiki has a Confluence migration tool that converts storage format XML into XWiki's WYSIWYG syntax, preserving page hierarchies, attachments, and most macros. Plan your migration in waves:
- Freeze new content in Confluence, export spaces, import into XWiki.
- Run Jira and OpenProject in parallel for two sprints while you validate workflows.
- Cut over SSO and update internal bookmarks.
- Archive Atlassian instances read-only for audit.
See our universal wiki migration strategy for detailed mapping tables and a rollback plan.
Operational Considerations
Both applications have predictable resource profiles. Budget roughly 4 GB of JVM heap per 100 concurrent XWiki users, and 2 GB of Ruby memory per 50 concurrent OpenProject users. Back up PostgreSQL nightly, ship WAL segments every five minutes, and store attachments on encrypted block storage. Because XWiki stores many objects in the database (not just page content), database backup is the single most important safeguard.
Run both applications on high-availability infrastructure if they become business critical. Active-passive with automated failover is usually enough for internal collaboration tools, and it keeps the stack simple.
Cost Comparison
Atlassian Cloud Premium costs roughly 11 USD per user per month for Jira plus 11 USD for Confluence at mid-scale. For 500 users that is 132,000 USD per year before add-ons. A self-hosted OpenProject plus XWiki on two managed cloud servers plus PostgreSQL replicas lands well under 20,000 USD per year including support, while giving you full control over data residency and upgrade cadence.
Getting Started
If you want a turnkey environment, our managed XWiki hosting deploys a production-ready instance within hours, and we can provision OpenProject alongside it on the same account. Contact us for a migration assessment.
Published by the MassiveGRID team, experts in self-hosted collaboration stacks and Atlassian migration.