How to run a knowledge base RFP for self-hosted wikis
If you are replacing a Confluence estate or another wiki with a self-hosted platform, the most useful thing you can do before talking to any vendor or partner is to write one question set and send it to every candidate. A shortlist that answers different questions cannot be compared fairly. The answers should decide which platform fits, whether that is XWiki, BookStack or Outline, rather than the team arriving with a platform already chosen. This page is neutral on that choice. Each area below should be answered in writing, and each answer should be scoped to your own content volume, your identity provider and your hosting constraints, not to a generic demo environment.
Assign each area to the person who can answer it accurately. Platform and architecture questions belong to the platform or solution architect. Identity questions, including which protocol your directory supports and how groups map to spaces, belong to the identity team. Migration questions need the owner of the Confluence site, who can state how many spaces, pages, attachments and users exist and which permission schemes are in use. Licensing and support questions belong to procurement and legal. Ask each respondent to state their assumptions, such as the number of users by tier, the number of pages and the hosting location, because a licence or migration estimate that rests on the wrong volume will mislead the comparison. Where a vendor cannot answer with your numbers, record that gap as a finding.
Ask each candidate to name the license that governs the version they would deploy, and to confirm in writing which features sit behind paid tiers. Licenses differ in ways that matter: BookStack is MIT licensed, Outline is licensed under the Business Source License 1.1 with an additional use grant that restricts certain commercial document services, and XWiki is LGPL 2.1 with paid Pro applications and support sold separately. Ask each candidate to show the SSO and permission features they rely on, and to point to the edition or extension that provides them, so that you can confirm the price of the working configuration rather than only the free core. Request a written statement of which components will be hosted by you, which by the vendor, and which by a third party.
Which platform answers should justify XWiki, BookStack or Outline
XWiki is licensed under the LGPL 2.1 (the platform's license file states LGPL-2.1-or-later), which makes it the candidate to test first when content needs structured applications, custom data types and fine-grained rights. A strong answer ties the choice to a specific requirement, such as typed content, forms or app extensions, rather than to the wiki's general popularity. The official Docker images come in MySQL, PostgreSQL and MariaDB variants, each running on Tomcat, for amd64 and arm64v8.
- Named reason: the partner should cite structured applications, scripted extensions or a need for a common page model across departments, not general wiki features.
- Database choice: the answer should state which database variant it recommends and why, given your existing database standards and support contracts.
- Version line: the partner should say whether it proposes the stable line or an LTS line, and how upgrades between them will be scheduled.
- Trade-off to admit: a structured platform carries more configuration, more Java and Tomcat operations and a steeper editor learning curve than a simple wiki.
- Support model: the answer should separate the free Standard edition from paid Pro applications and SaaS support, and say which features it depends on.
Ask the partner to list every extension it expects to install and whether each one is open source, free or paid.
BookStack is licensed under MIT and organizes content into books, chapters and pages grouped on shelves. A credible answer proposes it when the content is mainly procedural or reference text, the team wants a simple editor and the structure fits a shelf and book model. It supports OIDC, SAML2 and LDAP sign-in, built-in multi-factor authentication that can be enforced per role and a full role and permission system.
- Named reason: the partner should tie the choice to a book and shelf structure that matches how your teams already find information, and to identity options your directory supports.
- Runtime requirements: the answer should state PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 or later, and confirm your servers and patching cycle can meet them.
- Deployment method: BookStack publishes official installation scripts for Ubuntu 26.04, 24.04 and 22.04 but does not publish official Docker images, so a container plan should name the community image it uses and who maintains it.
- Trade-off to admit: it offers less structure for typed content and fewer built-in applications than XWiki, so large cross-department data models may outgrow it.
- Permission depth: the partner should show how page-level restrictions behave for sensitive spaces, since a simple model can be harder to audit at scale.
Check the version the partner names against the releases page before accepting it, and ask how it will track security updates.
Outline is licensed under the Business Source License 1.1, and its additional use grant forbids using it to offer a commercial Document Service. A partner proposing Outline must first show that your use does not fall into that restriction, because the license terms, not the feature list, decide whether it can be deployed for your purpose. Outline 1.11.0 was published on October 12, 2026, and the answer should name the version it would deploy.
- Named reason: the partner should explain why a modern, Markdown-friendly editing experience matters for your teams and how it fits your existing content workflows.
- License review: the answer should include a written reading of the grant against your intended use, and recommend that your legal team confirm it.
- Dependencies: the partner should list the services Outline requires, such as its database, cache and file storage, and who operates each one.
- Trade-off to admit: the license is not an OSI-approved open source license, so procurement policies that accept only open source may reject it, and some terms may change over time.
- Scope limits: the answer should state whether the proposed use involves customers, partners or any service offered to third parties, since that is where the grant applies.
Ask the partner to confirm the license position in writing before design work starts, and to identify who in your organization must approve it.
Questions to ask about migration, SSO, search, licensing and upgrades
Which wiki platform fits our team, and why should we pick it over the others?
The right platform depends on how structured your content must be, not on feature counts. BookStack, licensed under MIT and currently at v26.09.1, suits teams that want a simple books, chapters and pages model with built-in diagrams and SAML2, OIDC or LDAP sign-in. XWiki, licensed under LGPL 2.1, suits teams that need structured data, applications and fine-grained permissions across departments. Outline is licensed under the Business Source License 1.1, which forbids offering it as a commercial Document Service, so have legal review it before you choose it. Ask your partner to document the requirement that drove each recommendation, the sizing assumptions (users, page count, attachment volume) and the hosting model they expect. Confirm the exact versions they will deploy at proposal time.
How are Confluence spaces, permissions and page history migrated?
Ask the partner to list every object type they will move and every object they will not. For XWiki, the commercial Confluence Migrator Pro from XWiki SAS is the tool to confirm; it covers spaces, pages, users, groups, permissions, attachments and metadata, and keeps page history but not attachment history. Its trial is limited to 30 pages per migration, so a full migration requires the paid license, which is priced from 2000 EUR according to XWiki's store. Ask who maps Confluence groups to directory groups, how restricted pages are re-created, how macros that have no equivalent are handled, and who signs off the test results. A good answer names a sample of spaces used for a trial run and a written reconciliation of page counts, users and permissions before cutover.
Does the SSO setup support our directory and our protocols?
Ask which protocols are configured for your platform and which directory it will authenticate against. BookStack supports OIDC, SAML2 and LDAP sign-in and can enforce multi-factor authentication per role. XWiki Pro lists Active Directory and Azure Active Directory SSO applications, so confirm whether your directory requires those specific applications or a generic OIDC or LDAP route with the open-source extension, such as the xwiki-contrib OIDC project. Ask how directory groups map to wiki roles, how deprovisioned users lose access, what happens to sessions and API tokens, and which fallback admin account exists if the identity provider is down. Request a test matrix that covers login, group mapping, logout and revocation for each protocol.
How do we tune search and indexing for a large wiki?
Search quality is set by indexing behavior, permissions and content hygiene, so ask the partner to describe each. Confirm which search engine or built-in index the chosen platform uses, how often it reindexes after bulk migration, and whether attachments such as PDFs are extracted and searchable. Ask how search results respect page permissions, because a result that reveals a restricted page title is a security issue. Request a plan for measuring search quality with a set of real queries from your staff, and a rule for archiving stale pages so they do not dominate results. Confirm the cost of any external search component and who operates it.
Which license terms and support options apply to our deployment?
Separate the software license from the support contract. BookStack is MIT licensed and XWiki Standard is free open source under LGPL 2.1, while XWiki SAS sells support, hosting and paid Pro applications. XWiki lists Starter, Basic, Business and Enterprise support tiers by user count, and states that cloud and on-premises pricing is the same. Its consulting rate is 1200 EUR per day and requires a Business or Enterprise support plan, according to XWiki's pricing page. Ask the partner to list every license that applies to the platform, extensions and connectors, the user count they assumed, and who holds the support contract. Confirm that the license terms have been reviewed by your legal team.
How are upgrades and rollbacks handled for a self-hosted wiki?
Ask for a written upgrade procedure that covers the platform, database, extensions and the container or package layer. For XWiki, confirm which line you will run: the stable line (18.8.0 for Docker at time of research), the long term support line (17.10.14) or the intermediate LTS line (18.4.7), because each implies a different upgrade cadence. For BookStack, confirm the PHP 8.2 and MySQL 8.0 or MariaDB 10.6 requirements for each release. Ask how a full backup of the database and attachments is taken before each change, how rollback is tested, how long a rollback window lasts, and who performs and signs off each upgrade. Request a recurring upgrade schedule and the support terms that cover it.
What does a partner's engagement cover, and what can our team run itself?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with written deliverables. Ask any partner to split the work into one-time items (design, migration, SSO setup, hardening, documentation, training) and recurring items (patching, backups, upgrades, support). Ask which tasks your own administrators will perform after handover and what skills they need. Request a quote that follows from the written scope, not a list price, and ask what would change the price if the migration volume, user count or integrations grew.
What evidence will we get that the migrated content and access are correct?
Ask for a reconciliation report produced at the end of each migration wave. It should list page counts, attachment counts, users, groups and permission rules compared with the source, along with the exceptions and how each one was resolved. Confirm who tests the results (your content owners, your security team or the partner) and who approves the cutover. For regulated content, ask how the test evidence is retained so that it can be shown to an auditor. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue the actual reports, so confirm that expectation with any partner.
What a Confluence migration must prove before go-live
A Confluence migration is accepted on evidence, not on the vendor's word that the import finished. Before go-live, ask the partner to run the migration on a representative sample that includes every space type you run: large spaces with deep page trees, spaces with restricted permissions, pages with embedded attachments, and pages with macros or diagrams that do not map cleanly to the target wiki. Agree the sample in writing, record what the source looks like before the run (page counts per space, attachment counts, group memberships, and who can view each restricted space), and require the partner to produce the same counts from the target after import. Any gap should be explained page by page, not averaged away.
Reconciliation needs three separate checks. Page counts and tree structure must match per space, including archived or draft content if you decided to keep it. Permissions must be compared by sampling real users against real pages, because a migrated group that looks correct in an export can still grant the wrong read access; a user who should not see an HR or legal space is the finding that matters most. Attachments must match by file name, size and checksum where the tooling exposes them. Page history is the item most likely to fall short. The XWiki Confluence Migrator Pro documentation, as supplied to us, states that it keeps page history but not attachment history, so you must confirm in writing whether history is preserved in full, how far back it goes, and how it appears in the target. Decide now whether you will archive the Confluence export for records retention, since history that does not carry over may still be needed for audit. The commercial terms belong in the same acceptance file. The supplied fact for this tool is a starting price from 2000 EUR and a trial limited to 30 pages per migration. Treat both as facts to confirm with XWiki SAS in writing, including whether the price covers one migration or per-space work, what support is included, and whether the trial result can be reproduced on the full estate. Finally, require a retained rollback path: the Confluence instance stays read-only or intact until users have signed off, the target keeps a timestamped copy of the import, and the partner documents how to revert DNS, SSO and permissions if acceptance fails. Ask who owns that rollback decision and how long it is kept available.
Vendor answers that should worry a buyer
Most knowledge base proposals sound alike until the details are checked. The answers below look reasonable in a slide deck but fail under scrutiny of licenses, migration evidence, identity design, search testing and operations. Use them to press vendors for specifics in writing.
Outline is free for any commercial use
Outline is published under the Business Source License 1.1, and its additional use grant forbids using it to offer a commercial Document Service. A vendor who calls it free without reading that grant may be proposing a deployment your legal team would reject. Ask the vendor to state, in writing, how their proposed use maps to the grant and to get your counsel to confirm it.
Full attachment history migration without evidence
Migration tools differ in what they carry over. Confluence Migrator Pro from XWiki SAS keeps page history but not attachment history, so a promise of complete history is a claim to test, not accept. Ask for a migration of a sample space containing versions, attachments and restricted pages, then compare the results against the source. Ask which items are dropped and how they will be documented for auditors.
SSO quoted without protocol or directory
"We support SSO" does not describe a design. Ask which protocol will be used, whether that is SAML2, OIDC or LDAP, which directory will be the source of truth, and how groups map to wiki roles and spaces. BookStack supports OIDC, SAML2 and LDAP, while XWiki Pro lists Active Directory and Azure Active Directory SSO applications. Require the vendor to name the exact product, version and configuration keys they will use.
Wiki.js 3.0 beta for production
The main requarks/wiki repository holds a 3.0 beta marked not for production use, while the stable 2.x line lives in a separate repository. A proposal that builds production content on the beta puts you on an unsupported path with an uncertain upgrade route. Ask the vendor which line they will deploy, where the release is published, and how they will move to a stable version later.
Search quality promised without a test corpus
Search relevance depends on your content, languages, attachments and permissions, so a general promise tells you little. Ask the partner to build a test set of realistic queries drawn from your own pages, with expected results for each. Measure how the proposed setup ranks those results before go-live, and confirm that search respects page permissions so restricted content does not appear in results.
Upgrades and rollback left undescribed
A wiki that runs for years must be upgraded, and an upgrade that fails without a tested way back causes downtime and lost edits. Ask for the upgrade calendar, the backup and restore steps, the staging test process and the rollback procedure with its expected time. For XWiki, confirm which line (stable, intermediate LTS or LTS) is chosen and how long it is supported. Vendors who skip these steps have not planned operations.
How to score knowledge base RFP responses
This table lists the areas a buyer should score when comparing partner responses for XWiki, BookStack or Outline, with a weight and a rule for full marks in each. Full marks depend on evidence the buyer can check, such as a demo, a test migration, a written license reading or a named release policy, rather than on confident wording. Use the weights as a starting point and adjust them to your own content, identity and hosting constraints.
| Area | Weight | Full marks require | Where responses usually fall short |
|---|---|---|---|
| Platform fit | 15% | A written reason for the chosen platform tied to your content structure, editors and readers, with a named alternative that was rejected and why | Generic praise for one product with no comparison to the others in scope |
| Confluence migration evidence | 20% | A test migration of a representative sample of spaces, showing pages, users, groups, permissions, attachments and history, with a written list of what does not carry over | Claims that everything migrates, with no sample run and no statement on attachment history |
| SSO and permissions | 15% | A configuration plan for your identity provider (SAML, OIDC or LDAP), group mapping to spaces, and a method to audit who can read each restricted space | A single line saying SSO is supported, with no group mapping, no test plan and no note on which features sit behind a paid tier |
| Search | 10% | A stated search approach, a list of content types and attachments indexed, and a test plan using queries your users actually run | Search described only as fast or accurate, with no tuning steps or indexing scope |
| License clarity | 15% | A written reading of the license for the exact product and edition proposed, including any use restrictions, extensions or enterprise directories, checked by your legal team | Answers such as open source with no mention of the license name, the version, or where paid code begins |
| Upgrade process and release policy | 15% | A named release line (stable, LTS or intermediate LTS where offered), a documented upgrade runbook, a rollback step and a test environment for each upgrade | Upgrades described as easy, with no release line named and no rollback plan |
| Support model and vendor independence | 10% | Named support options with their scope, a statement of who fixes what, and a plan that still works if the vendor changes its offering | Support described only as available, with no tiers, response scope or exit plan |
How to shortlist and test partners in four steps
This sequence turns a long list of knowledge base partners into a short list backed by written scope, a tested migration sample and checked evidence, so the final choice rests on proof rather than presentation quality.
Send the written question set to every candidate
Send the same written question set to each shortlisted partner, covering platform choice (XWiki, BookStack or Outline), how Confluence spaces, permissions and page history are migrated, how SSO is configured, how search is tuned, which license terms apply and how upgrades are handled. Ask each partner to answer in writing and to name the people who will do the work. This step is done when every answer is on file, gaps are listed, and any answer that depends on a product feature is marked for confirmation with the vendor. Ask partners to state which licence applies to the exact edition they propose, since Outline's Business Source License 1.1 limits some commercial uses.
Require a scoped proposal with named deliverables
Ask each remaining partner for a proposal that lists the scope in writing, the named deliverables, the acceptance criteria, the responsibilities split between the partner and your own team, and the terms for ongoing support. A fixed-scope proposal should state what is excluded, such as content cleanup, custom macros or third-party connectors. Compare proposals line by line, not by total. The step is complete when each proposal can be checked against the question set and every deliverable has a named owner and an acceptance test.
Run a pilot migration on real sample spaces
Select a sample of real spaces that cover your hardest cases, such as restricted spaces, deep page hierarchies, large attachments and pages that use vendor-specific macros. Have each shortlisted partner migrate the sample into a non-production instance. Agree acceptance checks in advance: page counts, page history, attachment links, user and group mapping, permission parity for sample users, and search results for known terms. Document what the tooling could not carry over. The step is done when results are recorded against the agreed checks and the team can explain every gap. If you evaluate the Confluence Migrator Pro route, confirm that its page history coverage matches your retention needs, since attachment history is not kept.
Check references or a reference architecture before choosing
Before selecting a partner, ask for references from comparable engagements and for a reference architecture that shows hosting, identity integration, backup, search and upgrade paths. Ask references about the timeline they actually achieved, how the partner handled issues after go-live, and how upgrades were scheduled. Verify that the proposed architecture fits your own infrastructure and security controls. The step is complete when references have been contacted, the architecture has been reviewed by your security and platform teams, and the chosen partner has confirmed the scope, acceptance checks and support terms in writing.
What drives cost and effort in a knowledge base implementation
Buyers asking about cost should first separate the software from the services. The wiki itself may be free to download: BookStack is MIT licensed and XWiki Standard is the free open source version, so the license line is often zero. The money goes to the parts around it: the hosting and administration your team or a partner runs, the migration tool if you move from Confluence, consulting days for configuration and custom SSO, and any paid Pro applications or support subscription you choose. Ask each bidder to show these as separate line items, with a note on which are one-time and which recur every year.
Published rates give a useful reference point, though they are not a DeployOpen price. XWiki SAS lists consulting at 1200 EUR per day, which requires a Business or Enterprise support plan, and training at 1500 EUR per day. Its Confluence Migrator Pro is priced from 2000 EUR, with a trial limited to 30 pages per migration. DeployOpen does not publish a price list. A quote follows from written scope, and most engagements are fixed-scope, so the scope document is where cost is actually decided.
Four factors push effort up most often: content volume, the number of spaces or directories to restructure, custom SSO (for example, mapping directory groups to roles in OIDC, SAML2 or LDAP), and permission complexity such as restricted HR or legal spaces. Each one should be stated in the RFP with numbers you can verify: page and attachment counts from an export, the count of top-level spaces, the identity provider and its group model, and the list of pages with special access. Ask each bidder to price these inputs separately, so you can see which assumption drives the total and what changes if your content grows.
How DeployOpen scopes and delivers knowledge base evaluations and implementation
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure. For knowledge base RFP questions, we turn your answers on platform choice, Confluence migration, SSO, search and license terms into a written scope before any build work starts.
How we scope
- We confirm which wiki fits your content model, editors, readers and hosting constraints before comparing platforms.
- We document the Confluence migration scope, including which spaces, users, permissions and page history move and which do not.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- We install the chosen platform in your cloud account, data center or isolated network, with your identity provider connected.
- We configure SSO, group mapping, role-based permissions and search, then test access for each sensitive space you define.
- We customize templates and integrations, and run security testing on the deployed wiki before users receive access.
How we hand over
- We deliver architecture notes, configuration records, permission matrices and migration reconciliation reports in writing.
- We document the upgrade path for your chosen release line, including license terms that apply to your use case.
- We train administrators and content owners, and prepare evidence that your team can give to auditors or assessors.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- We back up the wiki and its database and test restores on a schedule agreed in the written scope.
- We review new platform releases and security updates, and plan upgrades with your change process in mind.
