Most migrations fail in the same way. Not with data loss, with abandonment. Everything gets exported, imported, and then never opened again, because what arrived in the new app was a heap rather than a system.
Plan for that failure mode rather than the dramatic one.
First, decide what you are actually moving
Open your current app and estimate three numbers.
How many notes you have. Usually far more than you think.
How many you have opened in the last year. Usually under five percent.
How many you would rebuild if they vanished tonight. Usually a couple of dozen.
The third number is the migration. The rest is archive, and archive does not need to arrive in usable shape, it needs to arrive somewhere searchable and be left alone. Treating a decade of accumulated notes as though all of it must be cleanly converted is what turns a two hour job into a project you abandon in week three.
What survives an export, and what does not
Reliably survives: note text, titles, creation dates, folder structure.
Reliably breaks or degrades:
- Attachments. Often extracted into a sibling folder with rewritten links, and often silently dropped in web-based exports.
- Internal links between notes. These are the most valuable thing in a mature system and the most likely to break. Nothing translates one app's link format to another's cleanly. See backlinks.
- Tags. May land as frontmatter, as inline
#tags, or nowhere. - Nested or complex tables. Notion databases in particular do not survive as databases, they become CSVs and static tables.
- Handwriting and ink. Usually exports as a flattened image, losing searchability and editability. This alone can decide the question for a handwriting-heavy system.
- Reminders, dates, checkbox state. Frequently lost.
- Encrypted notes. Almost always excluded from exports entirely. Decrypt first, or lose them.
The formats, ranked
| Format | What it is | Verdict |
|---|---|---|
| Markdown (.md) | Plain text with light formatting | The best destination. Readable forever, imports everywhere |
| HTML | Web pages, one per note | Good fidelity, poor editability. Fine for archive |
| ENEX | Evernote's XML format | Well supported as a source. Obsidian, Notion, Bear, Joplin and Notesnook all read it |
| Fixed page images | An archive format, not a notes format. One-way | |
| Proprietary backup | App-specific | Only useful for restoring into the same app |
The direction to aim for is Markdown, for the reason set out in plain text notes: it is the only format where the files remain useful if every app in this article disappears. That is the actual insurance policy, more than any licence or company.
The process
1. Export everything first, and keep it. Before touching the new app. Put the export on a drive you control and do not delete it for a year, whatever happens next. Almost every migration horror story is someone who cancelled the old subscription in week one.
2. Verify the export before trusting it. Open it. Count the files. Check that a note with an attachment still has the attachment, and that a note with an internal link still points somewhere. Exports fail quietly. See how to back up your notes.
3. Import the archive into a single folder. Call it Archive-<oldapp>-2026 and do not organise it. Its only job is to be searchable. Resist the urge to tidy it now; tidying ten years of notes is a separate project and it is the one that kills migrations.
4. Rebuild the active layer by hand. The twenty or so notes you actually use. Retype or reshape them into the new app's idiom. This is slow and it is the step that decides whether the move sticks, because it is where the system gets designed rather than transplanted. See how to organize your notes.
5. Run both for two weeks. New notes in the new app only. Old app read-only. If you find yourself reaching back for something, that tells you what else needs to migrate.
6. Then cancel. Not before. And export one more time on the way out.
What to fix and what to leave
After importing, the temptation is a global cleanup. Do not.
Fix links only where they are used. Broken internal links in the archive can stay broken. Fixing 4,000 of them by hand is a waste; fixing the twelve in your active notes takes ten minutes.
Do not recreate an organisational scheme you did not like. The most common mistake is faithfully rebuilding the folder structure you were escaping. A migration is the only moment when restructuring is cheap. See tags vs folders.
Rename files if the new app cares. Some systems make titles load-bearing. Worth a pass over the active notes only. See how to name notes.
Before you go, check it is the app
Worth asking honestly, because switching is expensive and often solves nothing.
If the complaint is "I cannot find anything", the problem may be how to search your notes plus a naming habit, not the software. If it is "my notes are a mess", a new app inherits the mess in a week. If it is "capture is slow", that one is real and worth moving for, because capture friction is the property that determines whether notes exist at all.
The good reasons to switch are structural: the app is discontinued, the pricing changed, sync is unreliable, your data is trapped, or the way it stores notes conflicts with how you think. The bad reason is the hope that a new interface will produce a new habit. See PKM mistakes.
The short version
Export first and keep it. Dump the old notes into one searchable archive folder. Rebuild only the notes you use. Run both systems for two weeks. Then cancel.
Aim at Markdown so the next migration is not a migration at all.
More in export your notes, syncing notes across devices, and the best open source notes app.