On August 25, I asked Codex to search my notes for earlier work on digital ownership. It read the Markdown files directly from the vault. Obsidian wasn't part of the access path.
That showed something narrower than ownership: the notes were accessible outside the application that organizes them.
I used to judge software at the point of entry. I compared the price, the features, and whether it could replace two other tools. Those checks helped me decide whether to start paying. They told me almost nothing about what would happen when I stopped.
An export button isn't an exit plan
An export can preserve the content and still leave a long distance between having the files and having a working system.
Notion makes the distinction clear in its own documentation. Pages can be exported as Markdown, databases as CSV, and workspaces as a collection of files. But Notion also says an exported workspace can't be instantly recreated by uploading it again. Only the current or default database view can be exported, not every view at once. Callout blocks become HTML because Markdown has no equivalent.
The content comes out. The application doesn't.
That isn't an accusation against Notion. A database view, an automation, or a permission model has to live somewhere. No neutral file format can preserve every behavior from every application.
But “you can export your data” answers only the first question. The harder one is what the export is worth after the original tool is gone.
The test I wasn't running
I'd still start with usage and price: whether I opened the tool last month, whether the annual plan is worth paying, and whether a cheaper substitute could do enough. The exit test adds five more checks.
Can I get the data out myself? An export that needs an administrator, a support ticket, or a working paid account is conditional access.
Can another tool open it? “Standard format” is not enough. I want to open one exported item somewhere else and see what survived.
What disappears? Links, formulas, comments, history, views, permissions, and automations may be more valuable than the text inside them. I want that lost layer named before migration day.
Can I do the work elsewhere? Opening an exported item checks readability. I also want to try one task I rely on and see what needs rebuilding.
What work would become mine? I want to know what I'd need to maintain in the replacement setup.
Local files don't settle every exit question
Ink & Switch's local-first model puts the user's copy of the data first while keeping the benefits people expect from cloud software, including sync and collaboration. The part I care about is longevity. The data should outlive the application that created it.
My notes are close to that model. They are Markdown files in an ordinary folder. Obsidian makes them more useful through links, search, plugins, and a graph, but it isn't what makes them readable. If Obsidian disappeared, the files would remain.
Alongside the files, I use iCloud for sync, Git for history, and Forgejo for a remote copy on a server I maintain. Reading the notes outside Obsidian doesn't test whether I could replace those services.
Running that server is my choice, not a requirement of local-first software. Recovery needs a separate check too: Obsidian's backup guidance distinguishes synchronization from keeping a recoverable backup.
That setup still works for my notes. I'm less convinced it should become a rule for every tool I use. I don't need local files for a weather app. I don't want to operate my own version of every collaborative service. Sometimes the vendor is being paid to carry work I have no reason to reclaim.
Exit cost belongs in the buying decision
The useful comparison isn't subscription against open source or cloud against local. It's the cost of staying against the cost of leaving.
For a small utility, leaving may mean exporting one CSV and spending an hour cleaning it. For a working system, the data may be the easy part. The real migration can include rebuilding views, reconnecting automations, learning a new system, and accepting that part of the history won't transfer.
Exit cost can grow as I build more of my work around a tool's relations, templates, and integrations. Features that help now may take time to recreate elsewhere.
I wouldn't migrate a useful system just to pass an ideological purity test. I'd want to know the exit cost while I still have the choice to keep it low.
I'd start with one important tool each quarter. Export the data, open one real item elsewhere, and try one task I depend on. Note what needs rebuilding and what remains untested. That sample wouldn't establish the full migration cost, but it would give me something concrete to judge. If the gaps are acceptable for the work I do, I'd keep using the tool.
