Privacy & Security
How to avoid vendor lock-in with your notes — a practical guide for individuals and teams who want to keep their personal knowledge base portable, format-independent, and recoverable regardless of which application or service they use.
Vendor lock-in in note-taking means that the user's notes exist in a format, in a system, or under conditions that make migrating away from the current application difficult, expensive, or likely to result in data loss or degradation.
This is more common than most note-takers realize. They choose an application because it's convenient, build years of organized notes in it, and eventually discover:
The degree of lock-in varies significantly by application. Some tools are designed for portability — notes in open formats, complete export functions, well-documented data structures. Others accumulate content in proprietary databases where export is an afterthought.
Format lock-in: Notes stored in a proprietary format (a binary database, a custom markup language, a format only one application can read) create format dependency. If the application stops working, the format becomes inaccessible.
Feature lock-in: Notes that rely heavily on application-specific features (Notion's databases and relational properties, Evernote's tasks with cross-note relationships, Bear's cross-link preview system) may be structurally incompatible with other applications. The feature functionality is lost on migration even when the text content transfers.
Cloud lock-in: Notes stored exclusively in a cloud service (no local copy) are contingent on the service remaining available and accessible. Account termination, service shutdown, or loss of internet access removes access to notes.
Ecosystem lock-in: Notes integrated deeply with a platform ecosystem (Apple Notes with Siri integration, Google Keep with Google Assistant, Microsoft OneNote with Microsoft 365) work better in that ecosystem and lose functionality when moved.
The most durable note-taking practice is to keep notes in open, human-readable formats — primarily Markdown and plain text.
Why open formats resist lock-in:
Obsidian is currently the leading application for Markdown-based note-taking. Notes are standard .md files stored in a local folder. Obsidian adds features (backlinks, graph view, plugins) but the underlying files are plain Markdown — accessible without Obsidian. Switching away from Obsidian is as simple as opening the vault folder's .md files in another application.
Zettlr, Bear, iA Writer, Typora are other applications that store notes as Markdown files, with varying levels of proprietary extension.
Joplin stores notes internally as Markdown within a SQLite database, but provides complete export to JEX (Joplin-specific but complete) and to Markdown files. The Markdown export produces portable files, though internal links (note-to-note references) use Joplin-specific IDs that don't transfer to other applications.
The tradeoff:
Plain Markdown files don't have: cross-note relational databases, complex table structures, task management integrated with calendar, AI features, or deep search with semantic capabilities. Applications that provide these features often store notes in more complex formats that are harder to export cleanly. Users who need these features must accept some degree of lock-in in exchange.
For each note-taking application in use, assess:
Export capability:
Format dependency:
Account dependency:
| Application | Primary format | Export quality | Local copy | Lock-in risk |
|---|---|---|---|---|
| Obsidian | Markdown files | Excellent (files are the format) | Yes | Low |
| Joplin | SQLite + Markdown | Good (full Markdown export) | Yes | Low-medium |
| Bear | Proprietary SQLite | Markdown export available | Yes (local) | Medium |
| Standard Notes | Encrypted cloud + local | Good (JSON/text export) | Yes | Low-medium |
| Evernote | Proprietary | ENEX format (importable by others) | No | Medium-high |
| Notion | Proprietary | Markdown/HTML export (lossy for databases) | No | High |
| Apple Notes | Proprietary | No export function | No | Very high |
| Google Keep | Proprietary | Google Takeout (JSON) | No | High |
From Evernote:
Evernote's export format (.enex) is an XML-based format that many other applications can import. Supported importers: Joplin (excellent import), Obsidian (via plugins), Bear, Notesnook, Standard Notes.
The ENEX format preserves: note title, creation date, modification date, tags, content, and attached files. It does not perfectly preserve: complex formatting, internal note links, shared notebooks.
Migration process: File → Export Notes → .enex format (select all notebooks). Import the .enex file in the target application.
From Notion:
Notion's export produces markdown and HTML files with a folder structure. The limitation: Notion's database features (tables with relational properties, database views, rollups) export as simple tables or lists — the relational functionality is lost. Notion pages that are primarily text export well; Notion databases export with significant information loss.
For users heavily invested in Notion's database features, the migration cost is high regardless of technical tools. The content can be moved; the structured data relationships must be rebuilt in the new application.
Migration process: Settings → Content → Export All Workspace Content (Markdown & CSV). The resulting ZIP contains markdown files with a folder hierarchy.
From Apple Notes:
Apple Notes has no export function. The notes are stored in a proprietary database on macOS (in ~/Library/Group Containers/group.com.apple.notes/). Third-party tools can extract Apple Notes content:
After extraction, the markdown files can be imported into any markdown-based application.
From Google Keep:
Google Takeout (takeout.google.com) exports Google Keep notes as JSON files and attachments. The JSON format is not directly importable by most note applications, but third-party conversion tools (keep-to-markdown, for example) convert Google Keep JSON to markdown files.
Choose Markdown as the storage format where possible:
Start with an application that stores notes as Markdown files (Obsidian is the strongest option). This eliminates format lock-in entirely — the files are the notes, and any text editor can read them.
Maintain local copies:
Never rely exclusively on cloud storage. A local copy of notes provides access independent of the cloud service's availability. For cloud-synced notes, verify that a local database or local files exist.
Export regularly:
Even with applications that have good portability, schedule regular exports (monthly or quarterly). An export file provides a snapshot that can be used for migration or recovery independent of the application account.
Use application-agnostic organization:
Avoid note organization schemes that rely on application-specific features. Organize notes primarily with folders (which transfer as directory structures in most exports) and simple tags (which most applications support). Avoid application-specific database relationships, special views, or templates unless you're prepared to accept that they won't transfer.
Document your note system:
Keep a brief document describing how your notes are organized — the folder structure, the tagging system, the link conventions. When migrating, this document tells you what to recreate in the new application.
Open-source note-taking applications have a specific advantage for avoiding lock-in: the format is documented (or the source code is readable), and community-maintained export and import tools exist.
Joplin, Obsidian, Standard Notes, and Notesnook are all open-source. Their file formats are documented; migration tools exist in multiple directions. Even if the application stops being maintained, the format documentation allows the development of migration tools.
Closed-source, proprietary applications with undocumented formats are the highest lock-in risk. Apple Notes is the clearest example: no export function, proprietary format, and the extraction tools that exist rely on reverse engineering.
Some note-taking capabilities are so tightly coupled to a specific application's architecture that they don't survive migration:
Bidirectional links with previews: Obsidian's bidirectional linking (backlinks, link previews, graph view) relies on Obsidian-specific link parsing. The links themselves ([[Note Title]] syntax) are standard and transfer to some applications, but the dynamic graph and preview features are Obsidian-specific.
Notion databases: A Notion database with relational properties, rollups, and multiple views represents a relational data structure that doesn't have an equivalent in Markdown or most other note applications. The content migrates; the structure must be rebuilt.
Roam Research's block-level linking: Roam's block reference system (linking to specific paragraphs within notes) is Roam-specific and doesn't transfer to most other applications.
Application-specific AI features: AI-powered features (Notion AI, Obsidian Copilot plugin, Evernote's AI search) are application-integrated and don't transfer. The notes that were processed or organized using AI features transfer; the AI capability is application-specific.
Knowing these limitations before building a note system in a specific application allows the user to make an informed choice: if certain features are critical, accept the associated lock-in; if portability is the priority, avoid deep dependence on application-specific features.
Setup: A researcher has 4,200 notes in Evernote accumulated over 8 years. Evernote has changed its pricing model; the free tier is now very limited. She wants to move to Obsidian.
The migration:
Step 1 — Export from Evernote: She exports all notebooks from Evernote as ENEX files (one per notebook). The export includes all notes with their attachments.
Step 2 — Convert to Markdown:
She uses the evernote2md command-line tool to convert the ENEX files to Markdown:
evernote2md my-notebook.enex ./output/
This produces a folder of markdown files with corresponding attachment folders. She runs this for each exported notebook.
Step 3 — Review and clean up: She reviews a sample of 20-30 converted notes. Most convert cleanly. Notes that used Evernote's table features need manual review — tables convert to markdown tables, which works, but some complex tables need reformatting.
Step 4 — Import into Obsidian: She creates a new Obsidian vault and copies the converted Markdown files into it. Obsidian recognizes the files immediately. Tags from Evernote (exported in the ENEX format) are converted to Obsidian-compatible tags.
Step 5 — Rebuild Evernote-specific features: Internal note links (links between Evernote notes) don't transfer as working links; they appear as text. She updates the most important cross-links manually over the following weeks as she uses those notes.
Result: 4,200 notes successfully migrated. She estimates losing approximately 5% of formatting fidelity (mostly complex tables and some rich text). The migration took a weekend; the cleanup of cross-links is ongoing but not blocking.
Avoiding vendor lock-in in note-taking is primarily about format choices and backup discipline. Notes in open formats (Markdown, plain text) stored on a local filesystem give the user maximum portability with no trade-off in accessibility. For applications that use proprietary formats, understanding the export options and testing them before investing heavily in the application reduces the migration cost when the time comes to change tools. The migration cost from even heavily locked-in applications (Evernote, Google Keep, Apple Notes) is real but manageable with the right tools. The cost of discovering lock-in when a service shuts down with 90 days notice is much higher. Evaluating portability as a first-class criterion when choosing note-taking tools is the simplest way to avoid the problem entirely.
More WebSnips articles that pair well with this topic.
How to Audit a browser extension's permissions — a practical, example-driven guide with honest tool comparisons and a clear place for WebSnips. Written for Lawyers.
How to back up your notes safely — a practical guide for individuals and professionals who want reliable, secure backups of their personal knowledge base, covering backup strategies, encrypted backup tools, and recovery testing for note-taking applications.
How to capture sensitive research securely — a practical guide for researchers, journalists, legal professionals, and privacy-conscious individuals who need to gather and store sensitive information without creating avoidable exposure through insecure capture tools or storage practices.
How to choose a private web clipper — a practical guide for privacy-conscious researchers, journalists, and professionals who want to clip and save web content without exposing their browsing patterns, source materials, or clipped content to third-party services.
How to comply with GDPR in your knowledge base — a practical guide for teams and organizations who store personal data in their internal wikis, documentation systems, and knowledge management tools, covering data minimization, retention policies, access controls, and subject rights.
How to do research without being tracked — a practical guide for journalists, researchers, lawyers, and privacy-conscious individuals who need to gather information on sensitive topics without creating a digital trail that links them to their research subjects.