When people discuss portability in personal knowledge management, or PKM, they usually begin with data. Can the notes be exported as Markdown? Can attachments be transferred without corruption? Will internal links survive the migration? Can metadata, tags, and folder structures be preserved? These questions are important because they determine whether users technically retain ownership of the information they have accumulated over time. Yet they may also encourage us to define the problem of migration too narrowly. Even when every note, image, link, and attachment can be transferred perfectly, many users still find it surprisingly difficult to leave a knowledge tool they have used for years.
The reason is that long-term use produces something that is rarely visible in an export file: procedural knowledge.
After several years inside a particular PKM environment, users do not merely know what information they have stored. They have also learned how to behave inside the system. They know where to place a temporary thought before it becomes a permanent note. They know what kind of title will make an idea recognizable six months later. They develop an intuitive sense of which concepts should be tagged, which should be linked, and which should simply remain close together in a folder or document. More subtly, they often learn which screen, view, shortcut, or interaction serves as the starting point for thinking itself.
None of these habits necessarily appears in the database.
A folder can be exported, but the user’s intuition about when to create that folder cannot. A tag can be preserved, but the judgment that determines when tagging is useful cannot be packaged into a Markdown file. A network of backlinks may survive technically, while the user’s habitual method of moving from one idea to another disappears the moment the interface changes. What is transferred, in other words, is the explicit structure of the knowledge system, while much of the tacit structure that made the system usable remains embodied in the user’s behavior.
This distinction suggests that PKM systems may create at least two different forms of lock-in: data lock-in and workflow lock-in.
Data lock-in occurs when information cannot easily leave a platform because it is stored in proprietary formats, dependent on inaccessible metadata, or structured in ways that are difficult to reproduce elsewhere. In principle, this problem can be reduced through open formats, reliable export functions, APIs, and standardized representations such as Markdown. If a user can retrieve the underlying content in a durable form, much of the technical dependency on the original application can be removed.
Workflow lock-in is more difficult because it exists partly outside the software itself. It emerges through repeated interaction between a person and a system. Over time, the interface becomes embedded in the user’s routines: capture, retrieval, review, linking, categorization, and even the initiation of thought become associated with particular gestures and representations. The tool is no longer simply a container for knowledge. It becomes part of the cognitive procedure through which knowledge is produced and revisited.
For this reason, switching costs in PKM should not be understood only as the cost of reconstructing a database. They also include the cost of reconstructing fluency.
This is especially important when we consider the onboarding problem faced by new knowledge tools. A conventional onboarding strategy asks: How can we import the user’s existing notes? A more consequential question is: How much of the user’s existing way of thinking can be preserved while those notes are translated into a new representation?
These are fundamentally different design problems.
The first is primarily an engineering problem. It concerns file formats, parsers, metadata mappings, attachments, and links. The second is a problem of cognitive continuity. It asks whether users can enter a new environment without immediately abandoning the practices through which they previously made sense of their information. A migration experience that preserves every file but destroys every familiar interaction may be technically successful while remaining behaviorally unsuccessful.
This perspective also changes how we evaluate innovation in knowledge tools. New PKM systems often attempt to introduce better representations: graphs instead of folders, spatial structures instead of documents, relational models instead of hierarchical organization, or dynamic views instead of static pages. The difficulty is that every new representation imposes a translation cost. The more unfamiliar the model, the more users must reconstruct the procedural knowledge they developed elsewhere.
Consequently, the most effective migration strategy may not be to demand an immediate conceptual reset. It may instead involve progressive transformation.
Imagine, for example, importing an existing collection of conventional notes into a system such as Infinite Graph. The least disruptive experience would not require users to understand the entire graph model on the first day. Their existing notes could initially remain recognizable in structure and behavior. Connections could then emerge gradually: repeated references might become edges, related notes might become visible as clusters, and familiar navigation patterns could slowly be supplemented by graph-based exploration. The new representation would not replace the old mental model in a single step. It would allow the user’s established practices to become a bridge toward a different way of organizing knowledge.
This principle matters because adoption is not merely a process of learning features. It is a process of renegotiating habits.
From this perspective, the central challenge for a new PKM product is not simply to prove that its information architecture is more powerful. It must reduce the behavioral distance between the user’s current practices and the practices demanded by the new system. A theoretically superior knowledge model may still fail if adopting it requires users to discard years of accumulated procedural knowledge all at once. Conversely, a system that provides a gradual path from familiar behaviors to new representations may overcome switching costs even when competing products already offer strong export capabilities.
This leads to a broader principle for the design of knowledge tools:
Migration is not moving data. It is moving behavior.
Portability, therefore, should be evaluated not only by asking whether information can leave one system and enter another. We should also ask whether the user’s established methods of capturing, naming, connecting, retrieving, and developing ideas can survive that transition. The deeper challenge of PKM migration is preserving enough cognitive continuity that users can begin thinking in the new environment before they are forced to relearn how to think with it.
And that raises a more revealing question than whether a PKM tool supports Markdown export:
If every note transferred perfectly, what would still stop you from switching PKM tools?