The hidden cost of switching note-taking apps (and how to minimize it)

*May 13, 2026 · 11 min read*

Switching note-taking apps is the single most expensive decision in personal knowledge management. The migration looks like a weekend of work. It's actually a six-week trust-rebuilding exercise. Every time you switch, you lose part of the implicit context — which notes were "active," which were drafts, which tags meant what — and you spend weeks before the new tool feels as useful as the old one did the day before you switched.

That's the real cost. And it's why people get stuck in tools they've outgrown.

This article is for anyone who's eyed MindWiki, Obsidian, Roam Research, Logseq, Tana, Capacities, or Notion as a destination, looked at their current vault, and stalled. It's an honest accounting of what migration costs, what's recoverable, what's not, and the playbook that minimizes the damage.

TL;DR

The literal export is usually fine. Markdown-out is well-supported.
What gets lost is trust, structure, and habits — not files.
Cost recovery comes from picking a destination with portable storage (so you never pay this cost again) and a graph that's friendly to incomplete data (so you can be productive before the migration is "done").
MindWiki is engineered specifically for the "I'm tired of switching" case: plain markdown, wikilinks, an AI bridge, scheduled automations, and a one-click full vault export so the next migration — if there ever is one — is free.

What the migration cost actually is

Five categories, in roughly the order they hurt:

1. Format loss

The pure data conversion. Notion's block model has rich blocks (toggles, callouts, columns) that don't translate to plain markdown cleanly. Roam Research's block references have no equivalent in non-outliner tools. Heptabase's whiteboards are essentially un-portable. Capacities's typed-object schemas come over as YAML frontmatter that you have to interpret.

Cost: small for markdown-out exports (a weekend of cleanup). Large for proprietary-block tools (Notion databases, Roam queries, Capacities objects) — measured in days of manual rebuilding.

2. Link integrity

Inside a vault, every wikilink resolves to a real page. After export, half of them may resolve to nothing — either because the link syntax differs, or because the target page got renamed during export, or because the target page lived in a database that didn't export cleanly.

Cost: hours to days, depending on link density. The higher your link density (= the more knowledge value you have), the higher the link-repair cost.

3. Implicit structure loss

The hardest cost to talk about. Your old vault encoded structure in a hundred small ways: tag conventions, folder naming patterns, the implicit meaning of certain titles, the way you used emoji prefixes, the way you tagged something [[draft]] vs [[wip]]. All of that is now ambiguous in the new tool until you decide what it should mean.

Cost: weeks of "wait, did I use #draft to mean rough or to mean finished-but-private?" until the conventions settle.

4. Habit reset

Your typing speed in the new editor is half of what it was. Your slash-command muscle memory is gone. Your favorite hotkeys don't exist. Your weekly review ritual has nowhere to live until you re-build it.

Cost: 4–6 weeks of slower output. Real, and not optional.

5. Trust rebuild

The compound cost. Until the new tool has the *full* corpus AND you've started to retrieve from it successfully a few times, you don't trust it as your second brain. You keep falling back to the old tool. You write some notes in both. Both feel half-broken. The productivity hit is real and lasts about two months.

What's actually recoverable

The good news: most of the migration cost is one-time. After the new tool earns trust, you don't pay this cost again — *if* you picked a destination with portable storage.

Recoverable cleanly:

Plain prose.
Headings and lists.
Code blocks.
Most inline formatting.
Wikilinks (in tools that support them).
Frontmatter / properties (with some mapping).

Recoverable with work:

Citation metadata.
Image embeds.
File attachments.
Backlinks (rebuilt automatically when wikilinks resolve).

Lost or expensive:

Block-level references in outliner tools.
Database views with custom rollups (Notion-style).
Hand-positioned whiteboard layouts (Heptabase, Miro).
Plugin-specific features (Dataview queries, Templater outputs, Excalidraw drawings).
Versions/history (you start fresh).

Migration playbook by source tool

The procedure for the most common sources. Destination is MindWiki because the format (plain markdown + frontmatter + wikilinks) is the most portable target — but most of this generalizes to any markdown-vault tool.

From Notion

Workspace → Settings → Export → Markdown & CSV. Wait for the email.
Unzip into a `notion-export/` folder. Keep the structure for now.
Database CSVs: skim and decide which are worth keeping as YAML frontmatter on individual pages versus discarding. Notion task databases usually don't survive the move — they were never really notes.
Run a clean-up script. Common fixes:

- Strip \_ escapes to _.

- Remove the H1 duplicate of the filename Notion adds.

- Convert <aside> blocks into > [!note] callouts.

- Fix image paths (Notion exports images alongside the markdown; MindWiki convention is _assets/).

Drop the cleaned folder into your MindWiki vault path. Wikilinks will be ghost links until you process them.
Triage weekly. Not a one-shot migration — give yourself six weeks to actually decide which Notion pages were worth keeping.

Realistic expectation: ~70% of your Notion pages get migrated, ~30% get discarded once you see them outside the Notion UI and realize they weren't doing real work.

From Obsidian

Copy the vault folder. That's the migration. The files are already markdown with wikilinks and frontmatter.
Point MindWiki at the folder (macOS app → choose vault path).
Plugin-specific features (Dataview queries, Templater outputs) don't migrate. Either accept the loss or implement them differently in MindWiki — properties + table views cover the most common Dataview patterns.
Backlinks rebuild automatically because wikilinks are first-class.

Realistic expectation: this is the cheapest migration. The only loss is plugin-specific dependencies.

From Roam Research

Settings → Export All → Markdown. You get a flat folder of .md files.
Daily notes (named like 04-12-2026.md) move into a daily/ folder if you want to keep the daily-notes habit. Otherwise rename to ISO format (2026-04-12.md) for sorting.
Block references (((blockid))) don't translate. The choices:

- Flatten — let the block reference become plain text. Lossy but cheap.

- Footnote — rewrite them as [^block-id] footnotes. Hand-work.

- Skip — only worth doing if the references are load-bearing.

Roam queries don't migrate. Rewrite as MindWiki property filters where possible.

Realistic expectation: outliner-shaped notes feel weird in a pages-first tool for the first month. Many of them are better as paragraphs anyway.

From Logseq

Logseq stores markdown already in pages/ and journals/. Copy.
Properties at the top of pages map cleanly to YAML frontmatter; you may want to rewrite them.
Block references — same trade-offs as Roam.

Realistic expectation: cheap if you treat Logseq output as plain markdown and don't try to preserve the outliner semantics.

From Apple Notes

Don't bulk-migrate. Most of it isn't worth keeping.
Hand-pick the actually-important notes. Copy/paste each into a new MindWiki page.
Use a third-party export tool only if you have a hundred notes that genuinely matter.

Realistic expectation: 1–2 hours, ~10% of your Apple Notes archive.

From Word documents / Google Docs

Pandoc: pandoc input.docx -o output.md.
Clean up tables (Pandoc is lossy there) and embedded images (you'll need to extract separately).
Drop into the vault.

Realistic expectation: ~30 minutes per significant document. Don't try to migrate a thesis.

From Capacities / Tana

Both export to markdown. The typed-object schemas (Capacities) and supertag fields (Tana) come over as YAML frontmatter. You won't get the same in-app filtering experience, but properties + table views in MindWiki provide a close equivalent.

Realistic expectation: medium-effort. Best done page-by-page rather than as a bulk import.

How MindWiki minimizes the cost the next time

The whole point of doing migration carefully is so you only have to do it once. The two properties that prevent the next migration from being painful:

1. Plain markdown, always

MindWiki stores your vault as a folder of .md files plus _assets/. Page format: YAML frontmatter + body. Links: [[wikilinks]]. Attachments: regular files referenced via markdown image syntax.

If you ever leave MindWiki, your data is already in the most portable format that exists. The cost of the next migration is "copy a folder."

2. One-click export

Account → Settings → Export → Download zip. Includes every page, every attachment, the frontmatter, all of it. No "premium tier" requirement. No "delete account first" gating. This is intentional — the willingness of a note-taking product to let you leave is the strongest signal of whether you should trust it with your knowledge.

The "should I switch at all" check

A four-question test before you commit:

Is the new tool's format more portable than the current one's? If yes, the switch pays for itself eventually. If no, you're trading one lock-in for another.
Will the new tool open my old data without an import step? Markdown vaults score well here. Block-database tools score poorly.
Will I still be able to leave easily later? Test the export *before* committing. If the export feels grudging, the data ownership story is a lie.
Does the new tool have a habit-friendly editor? A switch that wrecks your editing speed for two months may not be worth the structural upgrade.

MindWiki is built to pass all four. The vault is plain markdown. Existing Obsidian/Roam/Logseq markdown folders work out of the box. Export is one click. The editor ships interactive tables, slash commands, live preview, and full keyboard navigation — the same shape you're used to.

A six-week migration plan that actually works

Realistic timeline for a meaningful corpus (~500–2,000 pages):

Week 1: install MindWiki, export from current tool, get the markdown into the vault. Stop using the old tool for *new* notes — they go in MindWiki immediately.

Week 2: triage capture/ for the 20% of pages that were doing real work. Promote them. Archive the rest into a migration-archive/ folder you can search but won't actively work in.

Week 3: link-repair pass. Find ghost links, decide whether to create their targets or drop the reference. Add wikilinks between the surviving pages.

Week 4: connect Claude or ChatGPT via MCP. Ask questions about the corpus. Discover which pages aren't actually pulling weight.

Week 5: settle conventions. Decide what your frontmatter properties mean, what folders are for, which tags survive. Rename pages, fix areas, normalize.

Week 6: stop calling it a migration. The new vault is the vault.

After week 6, the cost is paid. The vault compounds. You don't pay this cost again.

Why the destination matters more than the source

Most people focus on the source — "how do I get my notes out of Notion?" — and underweight the destination. The destination determines whether the next ten years of writing compound or whether you're back here in three years switching again.

A good destination has:

Plain text format.
Wikilinks as first-class.
Per-page properties (frontmatter).
A graph view of the link network.
A search that handles fuzzy phrases.
An export that doesn't fight you.
An AI bridge so future tools (and yours) can read the corpus.

That set of properties is what MindWiki optimizes for. If you've been migrating every two years, the right move isn't to pick a different proprietary tool — it's to pick a tool whose underlying format you'd be willing to leave behind a markdown vault for.