Stefan Haller
June 15, 2026
Knowledge management platforms accumulate something that is hard to replace: your organisation's institutional memory. Unlike a project management tool or a chat platform, a wiki that has been in active use for three or five years contains documented processes, onboarding guides, decision records, architectural notes, and policy documents that exist nowhere else. The longer it has been used, the more irreplaceable the content, and the more leverage the vendor has at renewal time.
This is vendor lock-in in its most practical form. It does not require any contractual or technical barrier — simply the accumulated weight of content and the cost of moving it. And it is a dynamic that most procurement processes do not adequately account for, because at the time of initial purchase, the content does not yet exist.
The questions in this article are ones that are worth asking before committing to a platform, not after. Many of them are uncomfortable to raise in a vendor sales process — vendors do not volunteer information about how to leave them — but they are the questions that determine whether you are making a genuinely informed decision.
Every serious wiki vendor offers some form of data export. The practical value of that export varies enormously.
The critical question is not whether export exists, but what format the exported data takes and how usable it is. An export of HTML pages or Markdown files preserves the content but loses structure: the hierarchy of spaces, sections, and pages, the metadata attached to each page (author history, tags, review dates), the permission model, and any embedded content such as tables with formatting or interactive elements. Importing this export into another platform requires significant manual work to reconstruct what was lost in translation.
Proprietary formats are worse. Some platforms export content in a format that is primarily useful for re-importing into the same platform — a deliberate design choice that makes migration expensive. When evaluating a platform, it is worth asking for an actual export sample from a demo environment and asking someone technical to assess what it would take to import that into an alternative platform. The answer is often more sobering than the vendor's "easy export" marketing suggests.
The strongest position for the buyer is a platform that stores and exports content in open, standard formats — formats where the export is genuinely re-importable elsewhere without requiring the vendor's proprietary tooling.
Switching costs in knowledge management are multi-dimensional. Content migration is one part. But the full picture includes retraining staff on a new editor and navigation model, re-implementing integrations with other systems (SSO, Slack, ticketing systems, CI/CD pipelines for documentation), rebuilding templates and permission structures, and re-establishing the governance practices that took time to develop.
A realistic switching cost estimate for a 500-person organisation with several years of accumulated wiki content and a moderate integration footprint is typically measured in person-months, not days. This is not inherently a reason to stay with a bad platform, but it is a reason to choose carefully at the outset — because the switching cost is not zero, and knowing that a vendor knows this too.
Some switching costs can be reduced by platform choices: platforms that support standard authentication protocols, documented APIs, and open export formats have lower switching costs than platforms that require proprietary connectors and export in idiosyncratic formats. This is worth asking about explicitly, because it correlates with the vendor's willingness to let customers leave — which in turn reflects something about how the vendor expects to retain customers. Vendors that are confident in the quality of their product tend to design for portability; vendors that rely on lock-in tend not to.
The per-user price at contract signature is one data point. The more important data point, for a platform that will become core infrastructure, is how that price has moved over time and what structural factors will drive it in the future.
Several wiki platforms have moved through significant pricing changes in the last two years: tier restructurings that bundle previously optional features into higher-priced plans, AI capabilities added to tiers and priced into seats, and annual increases that exceed standard SaaS inflation. Organisations that signed multi-year contracts at earlier pricing and are now at renewal face a different landscape than when they first purchased.
The questions worth asking are: what has this vendor's pricing history looked like for the past three years? What pricing protection can be contractually committed for a multi-year term? What is the mechanism by which new features — particularly AI features, whose infrastructure costs are volatile — are introduced into the pricing? And what happens to your price if you are on a plan that is restructured or deprecated?
Knowledge management platforms are attractive acquisition targets. They have strong retention dynamics, predictable subscription revenue, and data network effects that make them valuable to larger players. In the SaaS market, acquisition is a common outcome for successful independent vendors.
For customers, acquisition creates uncertainty across several dimensions. Pricing and packaging often change post-acquisition. Product development priorities shift toward the acquirer's roadmap rather than the customer's feedback. Data handling practices may change, particularly relevant for organisations with data sovereignty concerns — a vendor that was European and outside US jurisdiction may become a subsidiary of a US company.
This is not a reason to avoid vendors on the grounds that they might be acquired. It is a reason to have a clear answer to what you would do if they were, and to build that contingency planning into your evaluation.
A well-documented, stable public API is one of the strongest signals that a vendor is comfortable with customers building integrations, extracting data, and ultimately having real optionality about their relationship with the platform. It also enables a wider integration ecosystem — connections to ticketing systems, communication platforms, identity providers, and AI tools — that increases the platform's practical value.
A poor or absent public API, by contrast, channels all integrations through the vendor's proprietary connectors — connectors that can be deprecated, repriced, or changed without notice. It also makes it harder to build the custom reporting, automation, or content management workflows that larger organisations typically need.
When evaluating platforms, asking to see the API documentation — not a feature list, but the actual API reference — is a practical test of maturity and openness. The answer tells you something meaningful about how the vendor sees their relationship with customers.
The questions above can be organised into a straightforward framework for any vendor conversation. In your evaluation, it is worth asking directly: show me an export of this demo environment and walk me through how we would import it elsewhere. What has your per-user pricing done over the past three years, and what does the contract commit to? What is your API coverage and versioning policy? And if your company were acquired by a US-headquartered company tomorrow, what would change for our data handling?
Vendors that answer these questions clearly and without defensiveness are vendors that are confident their product will retain customers on merit. Vendors that deflect, over-complicate the answers, or redirect to their feature roadmap are telling you something about how they expect the relationship to work once you are inside the contract. That signal is worth taking seriously before you have several years of institutional memory sitting on their platform.
