Open-source alternative to Jira Service Management knowledge base

Open-source alternative to the Jira Service Management knowledge base: the short answer

If your Jira Service Management help center sits on Confluence spaces, replacing the knowledge base is the first piece to rebuild, because it is the part that carries customer portal deflection. The driver is usually a licensing change or a data residency requirement, and the question is which self-hosted tool can hold the articles, serve them to customers and keep them searchable. Three options fit different situations. Zammad's built-in knowledge base suits customer-facing support: it supports draft, staff-only (internal) and public answers, publishing in several languages chosen at setup, and categories with per-category permissions. GLPI's knowledge base suits internal IT, where articles mostly support employees and agents working through incidents and requests. XWiki fits teams that need a full wiki beside the service desk, with its own page structure, editing model and access rules.

Start by inventorying the Confluence spaces that feed the portal. Sort articles into public, internal and restricted groups, since those groups decide which tool and which access model fits. Check which articles customers actually open, because deflection depends on a small set of high-traffic answers that must work on day one. Confirm with each vendor whether their knowledge base can be linked from ticket and portal workflows and whether a custom domain for the help center is available on the deployment you plan to run. For Zammad, a custom knowledge base domain is available only on self-hosted instances, which matters for teams weighing a hosted plan. Document the decision before any article is moved, so the article migration has a clear target.

Which knowledge base capabilities map to which open-source option

This table maps the help center and Confluence capabilities that Jira Service Management customers rely on to Zammad, GLPI and XWiki. Read each row as a starting point for your own inventory, since cells marked to confirm need a test in your environment. The main takeaway is that Zammad covers customer-facing articles most directly, GLPI's knowledge base suits internal IT content, and XWiki is the closest match for Confluence-style wiki pages.

Capability	Zammad knowledge base	GLPI knowledge base	XWiki next to the service desk
Public and internal articles	Draft, staff-only and public answers; confirm portal visibility per category	Knowledge base entries with profile-based visibility; confirm which entries reach the requester portal	Page-level view rights; a customer-facing portal needs confirmation of anonymous read access
Categories and permissions	Categories with per-category permissions	Categories exist; confirm permission granularity against your profiles	Spaces and page rights; map Confluence space permissions to groups during the move
Page history and revisions	Confirm whether article revisions survive a migration; no Confluence migrator	Confirm revision history after import, since GLPI 12.0.0 rewrote the knowledge base	Page history kept by Confluence Migrator Pro; attachment history is not
Attachments	Confirm attachment support and size limits on answers in your version	Confirm how documents attach to knowledge base entries and whether they carry over	Attachments migrate with pages, but attachment history does not
Search	Built-in search; Elasticsearch is optional but recommended for speed and attachment content	Confirm search covers knowledge base entries alongside tickets and assets	Built-in search; confirm indexing of migrated pages and attachments
Confluence macros and embedded content	No macro equivalent; wiki-style links between answers and tickets replace some embeds	Confirm which embedded content types can be recreated	Macros need rewriting or an extension; confirm each one before migration
Links to Jira issues	Links point to Zammad tickets; Jira issue keys need remapping	Links point to GLPI tickets; Jira issue keys need remapping	Jira macros need replacement; XWiki Pro's listed connectors do not include Jira
Sign-in for authors	SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab among others	Internal database, LDAP, IMAP and REMOTE_USER tried in order; confirm SAML or OIDC	Pro lists Active Directory and Azure AD SSO; OIDC via the xwiki-contrib extension

Which option fits which knowledge base need

Each option answers a different question: who reads the articles and where the content should live. The choice depends on whether the knowledge base must deflect customer tickets, document internal IT services, or hold general company documentation. All three run on your own servers, so the decision is about fit and maintenance effort, not hosting.

Zammad knowledge base for customers

Zammad's knowledge base is built into the ticketing system, so answers sit next to the queues they reduce. Draft, staff-only (internal) and public answers let agents write before publishing, and you choose the publishing languages at setup, which is hard to change later. Wiki-style links connect answers to tickets, which helps measure deflection. Check whether a custom knowledge base domain is needed, since that option exists only on self-hosted instances, and confirm how your portal search will index multilingual content.

GLPI knowledge base for IT

GLPI's knowledge base sits beside its ITIL incident, change, asset and configuration modules, so an article can reference the server, software or contract it explains. This suits internal IT articles such as build procedures and service runbooks. GLPI 12.0.0 rewrote the knowledge base, so existing articles and categories need a test import and a review of visibility rules before you commit. Confirm how it handles the customer-facing portal you need for deflection, since its strength is internal use.

XWiki Standard for general content

XWiki Standard is free under the LGPL 2.1 and suits company-wide documentation that is wider than IT, such as policies, onboarding guides and project spaces. It is a separate system from the service desk, so articles need a link or sync process to appear in the portal, and ownership of that link must be assigned. XWiki Pro adds business applications, connectors and SAS support as an optional paid layer. Compare its editing model with the Confluence spaces your team uses today before choosing.

How the knowledge base sits beside the service desk

This option keeps Jira Service Management as the ticketing front door and moves help center articles out of Confluence into XWiki, which runs as a separate self-hosted wiki beside the service desk. XWiki is licensed under the LGPL 2.1, and its official Docker images come in MySQL, PostgreSQL and MariaDB variants on Tomcat, so the wiki can run on the same platform team's infrastructure. The hardest part is usually the links. Every article link in the portal, in agent macros and in email templates points at a Confluence address, so those references need a URL map or redirects once pages move.

Portal links: List every place JSM references a Confluence page, then decide between rewriting links and redirecting old addresses to XWiki.
Single sign-on: XWiki Pro lists Active Directory and Azure Active Directory applications, and the community xwiki-contrib/oidc extension covers OpenID Connect. Confirm SAML support in your XWiki version before you rely on it.
Search indexing: JSM search does not index XWiki pages by default, so customers searching the portal will not find articles unless you build that connection.
Migration tooling: Confluence Migrator Pro from XWiki SAS moves spaces, pages, users, groups, permissions and attachments, keeps page history but not attachment history, and is priced from 2000 EUR with a trial limited to 30 pages per migration.
Two editing systems: Editors work in XWiki while agents work in JSM, so set a rule for where new articles start.

Confirm with Atlassian documentation and your own portal configuration how articles are embedded or linked today, and whether your JSM plan allows external article sources.

How to move Confluence help center articles and keep their history

This sequence moves help center articles from Confluence into a self-hosted knowledge base with their categories, permissions and customer portal links intact. Each step ends with a check that shows the content is ready for the next one.

Inventory spaces, articles and owners
Someone who knows the help center lists every Confluence space that feeds customer-facing articles, then records each page's status, owner, language, attachments and the places where it is linked from the portal, tickets or emails. Mark which pages are public answers, which are internal procedures and which are drafts or stale. Ask the Confluence administrator which space permissions apply to each group. The output is an inventory sheet that the team signs off, and it becomes the baseline for every later check.
Export articles and attachments from Confluence
The Confluence administrator exports the spaces in scope using the export options available in your Confluence edition. Confirm in your own environment which formats the export produces, whether attachments are included and whether page history comes with it, because these differ by edition and configuration. Store the export archive in a controlled location with an access log. The output is a complete export that the team can open and count against the inventory, with any missing pages or attachments flagged for a second export.
Choose the import path for each target
Zammad's built-in migrators cover Freshdesk, Kayako, OTRS and Zendesk, so Confluence content needs the Zammad API or custom development from Zammad. If XWiki is the target, its Confluence Migrator Pro from XWiki SAS moves spaces, pages, users, groups, permissions, attachments and metadata, and keeps page history while attachment history is lost. Its trial is limited to 30 pages per migration, so run a pilot on a sample set. Ask XWiki SAS for the current licensing terms in writing. The output is a documented decision per target, with the chosen path and its known gaps.
Map categories and permissions to the target
Translate each Confluence space and label into a Zammad knowledge base category, or into the equivalent structure in the target you chose. Zammad supports per-category permissions, so decide which groups can see public answers, which can see staff-only (internal) answers and which can publish. Keep drafts out of the import unless someone owns them and approves them. Confirm the languages you need, because Zammad publishes in the languages selected at setup. The output is a mapping table that lists source space, target category, permission group and publication state for each article.
Build a new instance and load a test set
Zammad migrations work only on a new instance, so the platform team installs a fresh Zammad instance using the package, Docker Compose or Kubernetes option that matches its operations standard, and keeps the test instance separate from production. Load a representative subset of articles through the API using the mapping table, so the team can review formatting, images and internal links. Each migration takes one source system, so keep the Confluence content in its own run. The output is a test instance with a load log and a list of articles that need manual correction.
Test portal links and deflection
Check that every article the customer portal links to resolves in the new knowledge base, and that wiki-style links between answers and tickets still point to the right content. On a self-hosted instance, a custom knowledge base domain is available, so test the domain and any redirects from old Confluence URLs that customers may have bookmarked. Confirm that staff-only answers do not appear to customers and that public answers show in the expected languages. Ask a small group of agents to search for the top questions from the ticket queue. The output is a signed test report that lists broken links, permission errors and search gaps.
Cut over and retire Confluence content
Announce a freeze date for Confluence edits to help center spaces, then run the final export and load it into the production instance. Repeat the link and permission checks against production, and update the portal and any published links that still point to Confluence. Keep the Confluence spaces in read-only form for a period the business agrees on in advance, so teams can confirm nothing is missing. The output is a signed cut-over record and a set of retired spaces, with the retention decision written down by the content owner.

How to keep deflection rates in the customer portal

Deflection depends on whether a customer finds the right answer before they open a ticket, and that depends on three things: how well articles are discoverable, how good the search is, and whether the ticket form points people to suggested answers. In Zammad, the knowledge base only helps the portal if answers are published, filed into categories that the customer's role can read, and written in the languages your customers use. Draft and staff-only (internal) answers never appear to customers, so a common cause of weak deflection is a large library of articles that are still in draft or were written only for agents. Before the migration is final, check which answers are public, which categories are visible to the portal audience, and whether each high-volume question from your Jira Service Management help center has a published answer in the matching language.

Search quality is the second lever. Zammad documents Elasticsearch as optional but strongly recommended, because it is used for faster search, reporting and searching the content of email attachments. Plan to run it from the start rather than adding it after go-live, and confirm with Zammad's software requirements which Elasticsearch version your release expects. Articles that customers can only find by an exact title match will not deflect much, so test common phrasings against the portal, including misspellings and the wording used in old Confluence titles. Measure deflection before and after the cutover instead of assuming a result: record the share of portal sessions that end without a ticket, the search terms with no results, and the ticket volume for your top ten topics over the same period on both platforms. Treat the first post-migration month as a baseline, since your Jira figures include different traffic and channels.

What the knowledge base move costs in components

The knowledge base move costs less in software than in hosting, migration labor and content cleanup. The cards below separate one-time work from charges that recur each year, so you can check each line against a written quote.

Software licensing

Self-hosted Zammad carries no license fee, and its knowledge base is included in the application. GLPI is distributed under GPL-3.0 and XWiki Standard under LGPL 2.1, so the core software is free in both cases. The cost that remains is the optional vendor support you choose to buy. Confirm with each vendor which extensions, plugins or connectors you need, because some paid add-ons, such as XWiki Pro connectors, sit outside the free core.

Hosting and infrastructure

Zammad stores content in PostgreSQL 15 or newer and uses Redis 7 or newer for realtime updates. Elasticsearch is optional but strongly recommended for search, and Memcached is needed for multi-instance deployments such as containers or cluster nodes. Hosting recurs every month for compute, storage, backups and monitoring, and it scales with the number of agents and articles. Ask your platform team to size these tiers before you commit to a design.

Migration labor and content cleanup

This is usually the largest one-time cost. Zammad's Zendesk and Freshdesk migrators are all or nothing, run only on a new instance and accept one source per migration, so articles often need manual sorting before import. Budget time for mapping categories, removing stale Confluence pages, rewriting links and testing public and internal answers. Ask any integrator to price the cleanup separately from the technical import, and to state which content will be left behind.

Optional vendor support subscriptions

Zammad GmbH publishes annual self-hosted support prices for Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year. These fees recur annually and are optional, since self-hosted Zammad runs without them. XWiki SAS offers on-premises support and consulting separately, and its consulting rate is set by a support plan. Ask each vendor what response times and coverage each tier includes before comparing.

Recurring operations and upgrades

After go-live, someone must patch Zammad and XWiki, apply security releases, test upgrades, rotate credentials and review backups. These tasks recur throughout the platform's life and are often underestimated because they are not visible in a license line. Confirm whether your team or a retained partner will own patch windows, and agree in writing who responds to a security release within your change process.

What buyers ask before moving the Jira Service Management knowledge base

How long does it take to move a Jira Service Management knowledge base?

The duration depends on how many articles and spaces you move, how much of the content is still current, and how many languages and audiences the help center serves. No supplied figure sets a general timeline, so ask any implementer for a duration based on a written inventory of your Confluence spaces. Start by counting published articles, drafts, internal-only pages and restricted spaces, because each category needs a different target in Zammad or GLPI. Pages that are stale or duplicated usually take more time to review than to move, so a content audit early in the project shortens the later steps. Ask for the timeline as a line item in the fixed-scope proposal, with the assumptions that drive it stated in writing.

What does the work need from our team?

Your team supplies decisions and access, and the implementer does the mechanical work. You need a content owner who can approve which articles stay, an administrator who can create the target instance and API credentials, and someone from support who knows which articles drive tickets. Confluence administrators must confirm which spaces, permissions and groups map to Zammad categories or GLPI knowledge base entries. Expect review time from subject matter experts for articles with technical accuracy at stake. Plan these roles before the engagement starts so approvals do not hold the migration up.

Can our own team move the knowledge base in-house?

Yes, if you have people with administration and scripting skills and enough time to validate the results. Zammad's knowledge base supports draft, staff-only and public answers, categories with per-category permissions, and several languages chosen at setup, so the target design is worth settling before any content moves. Confluence exports can be converted and loaded through an API, but that work includes checking links, images, macros and permissions. Confirm with Zammad and your Confluence administrators which export formats and API calls fit your version. A fixed-scope engagement with DeployOpen covers planning, implementation, testing and documentation, and the choice between in-house and external work comes down to available skills and deadlines.

What happens to Confluence page history and attachments during the move?

Page history and attachments need explicit handling because most migration paths carry over the current version of content first. If you use XWiki as the knowledge base next to the service desk, the Confluence Migrator Pro extension from XWiki SAS migrates spaces, pages, users, groups, permissions, attachments and metadata. It keeps page history but not attachment history, so decide early whether older attachment versions must be archived separately. The extension is priced from 2000 EUR according to XWiki Store, and its trial is limited to 30 pages per migration, which matters for a test run. Confirm with the vendor how each option treats history, attachments and links before you commit to a target.

Which knowledge base should we pick, Zammad, GLPI or XWiki?

The choice depends on whether the knowledge base serves customers, internal staff or both, and on how much general wiki functionality you need. Zammad's knowledge base is built into the ticketing product and connects answers to tickets with wiki-style links, which suits customer help centers. GLPI 12.0.0, published on October 7, 2026, includes a rewritten knowledge base within an ITIL service desk and asset platform. XWiki is a general wiki that sits next to a service desk and suits teams that need a Confluence-like space for documentation beyond help articles. Compare the three against your article types, permissions model and integration needs before you decide.

How do we keep ticket deflection working in the customer portal?

Deflection depends on articles that customers can find and read from the portal before they open a ticket. Publish only the answers meant for customers as public, keep drafts and internal notes away from the portal, and check that search finds the same articles after the move. In Zammad, public answers and category permissions control what the portal shows, and links between answers and tickets help agents reuse them. Search quality also depends on the search backend. Zammad documents Elasticsearch as optional but strongly recommended for faster search, so decide whether it belongs in your target design. Measure deflection before and after the cutover using your own ticket data, because no supplied figure sets an expected rate.

What should we ask for in a quote for this move?

Ask for a written scope that lists the spaces and article counts in scope, the target platform and version, the migration method, and the testing approach. Confirm who runs the hosting, backups and upgrades after handover, since those costs recur. Ask whether the quote includes a test migration, cutover support and a rollback plan. For XWiki-based moves, ask whether Confluence Migrator Pro licensing is included or billed separately. Ask what is one-time and what is ongoing, and which assumptions would change the price or duration. Finally, ask for documentation of the new knowledge base structure so your team can maintain it.

What to confirm with the vendor and in your environment before you commit

Start by inventorying the Confluence content you plan to move, because the macros and page features that have no equivalent in your target platform decide how much manual rework the knowledge base needs. Export a representative set of spaces and list every macro, page template, embedded app and attachment type in use. Then check each one against the target you are evaluating, whether Zammad's knowledge base, the rewritten GLPI knowledge base in its current release line, or XWiki. Where a feature is not documented for your target, treat it as an open question for the vendor or a proof of concept, not as a capability. Ask the Zammad, GLPI or XWiki maintainers, or a support partner, to confirm in writing how each macro you rely on will be represented after migration.

Confirm the language requirements before you design the knowledge base structure. Zammad's knowledge base publishes in the languages you choose at setup, so verify that every language your customers and agents need is among them, and that translated answers can be maintained by your team without a separate workflow. Also confirm how draft, staff-only and public answers map to your current Confluence space permissions, and whether per-category permissions cover your audience boundaries. Next, document how your identity provider connects. Zammad lists SAML, OpenID Connect and several social providers, so confirm your provider and protocol are supported, who manages the client registration, and how group membership will control access to internal articles. For XWiki, confirm the authentication extension you need is available under your licence tier.

Finally, confirm where the knowledge base will be hosted and whether that meets your data residency rules. Self-hosting keeps content in your infrastructure, but the data location still depends on the cloud region, backup copies and any managed service you use, so map each location against your policy. Ask any vendor or hosting provider to state in writing where backups, logs and search indexes are stored. Confirm that a custom knowledge base domain, if you need one, is available on your deployment model. Record these answers in your architecture decision record before procurement, because they determine the scope of any implementation quote.

How DeployOpen scopes and delivers a knowledge base move

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a knowledge base move, that means agreeing in writing which articles, categories, languages and portal settings move, then building and testing the replacement in your environment before anything goes live.

How we scope

Inventory the Confluence help center spaces, articles, attachments, permissions and the portal pages that link to them.
Decide whether the target is Zammad's built-in knowledge base, GLPI's knowledge base, or XWiki beside the service desk.
Agree in writing which content is in scope, which is retired, and how deflection in the customer portal will be measured.

How we build

Deploy the chosen platform in your cloud account, data center or air-gapped network, with its database and cache tiers configured.
Map Confluence page history, attachments and access rules to the target model, and record what cannot be carried across.
Test article publishing, draft and internal answers, public visibility and search in a staging environment before cutover.

How we hand over

Document the architecture, configuration, migration scripts and the content mapping decisions made during the move.
Provide a runbook for updates, backups of the database, files and configuration, and the steps for publishing new articles.
Train the content owners and service desk leads who will maintain articles after the engagement closes.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Ask for a quote based on your written scope, since DeployOpen does not publish a price list.

Open-source alternative to the Jira Service Management knowledge base