Introducing a Company Wiki: Approach, Tool Choice and Operation

Want to introduce a wiki but not sure which one? WZ-IT's wiki selection compares BookStack, XWiki, Docmost and Wiki.js using your content. During the selection you try all four yourself in demo instances with sample content; the result is a decision paper, from €3,900 excl. VAT. Book a free initial consultation

Whether a company wiki gets used depends less on the software than on structure, responsibilities and maintenance. A wiki without a fixed order and without owners soon turns into a second file share where nobody searches any more. Introducing a wiki is therefore a project with clear steps, not the installation of a tool.

This guide describes the rollout of a self-hosted open-source wiki: from the goal through structure, roles and tool choice to permissions from the directory service, pilot, editorial process, training and operation. Which of the systems generally suits which organization is compared in the post BookStack, Wiki.js, XWiki or Docmost. If you are moving off Confluence Data Center, deadlines and migration paths are covered in the post on Confluence Data Center end of life. As of October 2026.

The six steps at a glance:

1. Clarify the goal, audiences and existing content.
2. Define structure and roles, including a permission matrix.
3. Choose the tool by its licence and operating limits.
4. Connect sign-in and permissions to the directory service.
5. Pilot with a real area and real users.
6. Introduce an editorial process with owners and review intervals.

Table of Contents

1. Why wikis stop being used after three months
2. Step 1: Clarify goal, audiences and existing content
3. Step 2: Define structure and roles
4. Step 3: Choose the tool by licence and operation
5. Step 4: Take permissions from the directory service
6. Step 5: Pilot with a real area
7. Step 6: An editorial process that keeps the wiki current
8. Training by role instead of one briefing for all
9. Operation: updates, backup and restore
10. AI search as an extension, not as the start
11. Common misconceptions about wiki rollouts
12. Our approach at WZ-IT
13. Further guides

Why wikis stop being used after three months

A new wiki usually starts with momentum. A few weeks later pages are no longer updated, documents end up back in the file share, and questions are asked in chat again. The causes are almost always organizational, and each one maps to a step of the rollout:

The software plays a minor role here. It must, however, match structure, permissions and sign-in, otherwise exactly the hurdles in the table appear.

Step 1: Clarify goal, audiences and existing content

The first question is what the wiki is for and for whom. Typical documentation types are:

• Manuals and policies for all staff, such as health and safety, data protection, travel expenses.
• Process descriptions for individual departments, such as order processing or complaints.
• IT operations documentation with systems, access, emergency procedures.
• Knowledge base for support and sales with frequent questions and solutions.
• Onboarding for new staff.

Not every type belongs in the same wiki, and not every type belongs in a wiki at all. The boundary with the intranet, document management and the ticket system is set here.

The inventory answers four questions: Where does knowledge live today (file shares, SharePoint, Confluence, an old wiki, the ticket system, mailboxes)? Which content is still valid? Which areas are confidential? Which directory service exists, such as Active Directory, Entra ID or Keycloak? The result is a picture of the current state with sources, permission areas and the people who actually maintain content today.

Step 2: Define structure and roles

Structure decides whether content is found. A few top-level areas aligned with audiences or organizational units, with limited depth below, work well. Add naming conventions for pages, templates for recurring page types (process description, how-to, decision record, operations manual) and an archiving rule for content that no longer applies.

Roles define who may do what and who is responsible for what:

Roles and areas produce the permission matrix: which group from the directory may read, write or manage in which area. Permissions are granted at area level, not for individual pages. Page-level permissions are the exception for truly confidential content, because they are hard to keep track of.

Step 3: Choose the tool by licence and operation

Only once structure and permissions are settled can the tool be chosen sensibly. For a company that wants to keep content in its own operation, four open-source wikis are the main candidates. The most important difference is not in the features but in what the free edition provides for sign-in and permissions:

Sources: BookStack, BookStack, Roles and Permissions, XWiki Pricing, xwiki-contrib/ldap, xwiki-contrib/oidc, Docmost Pricing, Wiki.js modules, BookStack releases, Docmost releases, Wiki.js 3.0.0-beta.617. As of October 2026.

This gives a first orientation:

• BookStack fits manuals, process and IT documentation where the fixed order of shelf, book, chapter and page helps and no dedicated wiki administration is planned.
• XWiki fits when many areas have fine-grained permissions, structured data or forms are needed, or Confluence is being replaced.
• Docmost fits teams that write pages together at the same time. With company sign-in and page permissions the Business tier is required; for 50 users that is USD 3,600 in licences per year.
• Wiki.js fits technical documentation in Markdown. The stable line is 2.x; version 3.0 is still in beta.

Outline appears in many lists but is released under the Business Source License 1.1. Its additional use grant excludes operation as a service for third parties; the code only changes to Apache 2.0 on 9 September 2030 (GitHub, Outline LICENSE). Outline is therefore only an option if your own IT runs it.

The selection should not end with feature lists. The future area owners try the candidates with their own sample content: How do they create a process description, how do they find a how-to, how do they grant permissions in their own area? The detailed differences between Docmost Community and Business are covered in Docmost Community vs. Enterprise Edition.

Step 4: Take permissions from the directory service

A wiki with its own accounts and passwords is one more hurdle. Sign-in therefore runs through the existing directory service, via single sign-on with OIDC or SAML, or via LDAP. This has three consequences:

• No extra password. Staff sign in with their company login. With single sign-on, the identity provider's multi-factor authentication also applies to the wiki.
• Permissions follow groups. The permission matrix from step 2 is mapped to groups in the directory. BookStack can assign roles automatically from LDAP or SAML2 groups (BookStack, Roles and Permissions).
• Leavers are handled. When an account is disabled in the directory, sign-in to the wiki is no longer possible either.

This is where the licence question from step 3 matters: in Docmost, SSO, LDAP and MFA are part of the Business tier (Docmost Pricing). BookStack, XWiki and Wiki.js include them without an extra licence.

Step 5: Pilot with a real area

The pilot tests structure, tool and sign-in with real content before all areas move. A good candidate is an area with a noticeable need, such as IT instructions, onboarding or one department's processes.

The pilot includes:

• a production-like instance with single sign-on and the groups from the directory,
• the pilot area according to the structure plan, with templates,
• existing, valid content taken over from file shares or the old system,
• a pilot group of authors and readers who give feedback.

A new wiki fills fastest when existing material is taken over and brought into shape with templates instead of writing from scratch. The content people ask about most comes first. Outdated documents are archived, not migrated.

The pilot ends with an acceptance record: Do pilot users find what they are looking for? Where does the structure not fit? Which templates are missing? Only then do the other areas follow, one at a time.

Step 6: An editorial process that keeps the wiki current

The editorial process is the step that decides whether the wiki is still used after three months. It consists of a few binding rules:

Some systems provide features for this; Docmost, for example, has a page review workflow in its Enterprise tier (Docmost Pricing). A field in the template and a regular look at overdue pages serve the same purpose. The editorial guideline itself is a page in the wiki.

Training by role instead of one briefing for all

A general briefing for everyone is not enough, because the roles need different things:

• Authors: use templates, structure cleanly, link instead of copy, store attachments, use search effectively.
• Area owners: permissions in their own area, review intervals, archiving.
• Administrators: groups and sign-in, extensions, updates, backups, export.

For readers a short guide in the wiki itself is usually enough. Short guides for each role are also pages in the wiki, so they are found when they are needed.

Operation: updates, backup and restore

After the rollout, the wiki becomes a system departments rely on. Operation covers:

The wiki runs on your own infrastructure or with an operator in Germany, for example through Managed Open Source. What matters is that responsibility is settled before launch and does not remain with the pilot team.

AI search as an extension, not as the start

AI search answers questions about the knowledge base in sentences and names the source pages. But it reproduces what is in the wiki, including outdated content, and must respect the wiki's permissions: anyone who may not read a page must not get an answer from it either.

AI search therefore comes after the rollout, once the content is maintained and permissions are set through groups. Routes there are the XWiki LLM Application (XWiki AI setup), Docmost's AI features from Business, or a separate search layer across several sources as described in Atlassian Rovo alternative, self-hosted. Whether the answers hold up with your own content is tested in a defined trial such as the RAG Proof of Value.

Common misconceptions about wiki rollouts

Our approach at WZ-IT

WZ-IT supports the rollout from the decision to operation. Every step has a defined result.

1. Orientation if the topic is still open. If it is not yet clear whether a wiki is the right next step, the orientation workshop sorts the topics. It is held remotely as a half-day session and costs from €1,490 excl. VAT.
2. Wiki selection with a defined scope. The wiki selection costs from €3,900 excl. VAT. It covers the inventory of your content, permissions and identities, weighted criteria agreed with business units and IT, and a review of licence and operating limits. For the duration of the selection we provide demo instances of BookStack, XWiki, Docmost and Wiki.js with sample content that you try out yourself, without committing first. We assess Outline in the matrix but do not host it as a demo, because its licence excludes operation as a service. The result is a decision paper with a recommendation, licence costs from vendor information and an operating model. If a different tool fits better, the paper says so. The amount is credited against the rollout if you order it within 6 months on the same topic.
3. Rollout. You receive the proposal for this together with the decision paper. It covers the structure and role concept with permission matrix, sign-in through your directory service, the pilot, the transfer of existing content, the editorial guideline and role-based training. Licences such as Docmost Business are bought directly from the vendor.
4. Operation in Germany. We run the wiki through Managed Open Source in German data centres, from €129.90 excl. VAT per workload and month, with updates, backups and monitoring. Alternatively it runs on your own infrastructure.
5. Extension with AI search. Once the content is maintained, the RAG Proof of Value from €9,900 excl. VAT tests how well answers from your content hold up. The long-term setup is described on the page for the internal AI assistant.

Further guides

• BookStack, Wiki.js, XWiki or Docmost, which wiki suits which organization.
• Confluence Data Center end of life 2029, deadlines and migration paths to open-source wikis.
• Docmost Community vs. Enterprise Edition, which features sit behind the licence boundary.
• Atlassian Rovo alternative, self-hosted, AI search across your own wiki.
• XWiki AI setup, the LLM Application with a local model.
• Knowledge management: wiki selection and rollout, WZ-IT's package.
• Consulting at WZ-IT, all entry points from the initial consultation to the selection.

A wiki that is still used after three months. We clarify goal, structure and permissions with you, let you try the suitable wikis with sample content yourself, and support the pilot, editorial process and operation. Book a free initial consultation

Sources

• BookStack, home page with features and licence
• BookStack, Roles and Permissions
• GitHub, BookStack
• GitHub, BookStack releases
• XWiki Pricing
• GitHub, xwiki-platform
• GitHub, xwiki-contrib/ldap
• GitHub, xwiki-contrib/oidc
• Docmost Pricing
• GitHub, docmost
• GitHub, Docmost releases
• GitHub, requarks/wiki
• GitHub, Wiki.js authentication modules v2.5.315
• GitHub, Wiki.js 3.0.0-beta.617
• GitHub, Outline LICENSE
• Atlassian, Data Center End of Life