NotesNudge the notes you never go back to

How to Leave a Notes App

Migrations go wrong quietly. The notes arrive, the count roughly matches, everything looks fine — and attachments are missing, links are text, and dates are all today.

You find out months later, when you go looking for something. Here is the order that prevents most of it.

A related workplace concept is productivity vs efficiency, which offers a useful contrast with the personal knowledge-work problem discussed here.

Before you export

Decide whether you should. Most migrations are motivated by the archive not working, which migration does not fix. Format lock-in, a dying tool, or a genuine block are reasons; a better-looking alternative is not.

Write down what you must not lose. Attachments, creation dates, links, tags, folder membership, revision history. Being explicit turns a vague anxiety into a checklist.

And export before you commit to anything. The export is the evidence. If it comes out badly, you have learned something important about your current tool without having moved.

For an independent external reference related to this topic, see Standard Notes.

The export

Ask for everything, in the most open format offered. Markdown or plain text over HTML, HTML over a proprietary bundle, anything over a screenshot.

Then look at what came out, before importing anywhere:

Is one note one file? If it is a single large file, you will be parsing it.

Do attachments exist as files, and do the notes reference them by a path that resolves?

Did dates survive? Creation and modification, in the file or in the note. This is the most commonly lost thing and the most annoying, because it destroys any chronological view.

Are links still links, or are they now plain text saying [[Some Note]]?

And is the text readable in a plain editor?

The import

Import a sample of fifty first. Not everything. Fifty notes covering your oldest, newest, longest, most-linked and most-attachment-heavy.

Check the same five things in the new tool. If the sample survives, the rest probably will; if it does not, you have lost an hour rather than a weekend.

Keep the old archive. Do not delete anything from the previous tool, and keep the raw export separately from the imported copy. The export is your fallback, and it is worth keeping indefinitely — it costs nothing.

And do not clean up during the move. Migrating and reorganising at once means you cannot tell which step lost something. Move first, verify, then tidy.

What you will lose anyway

Accept these rather than fighting them.

Revision history, almost always. If a note's history matters, export those individually first.

Backlinks, unless both tools use the same syntax. Forward links often survive; the reverse index is usually rebuilt or lost.

Application-specific features. Embedded canvases, database views, custom fields. These were never portable and choosing them was a bet.

And some formatting. Tables and nested lists survive badly between formats.

The thing that does not survive and matters most

The habit.

Whatever review practice existed does not carry over. The trigger was attached to a particular application, a particular screen, a particular place in the day. After a migration the practice quietly does not resume, and the archive is now in a nicer tool and read exactly as often as before, which is to say not at all.

So: restart it deliberately in the first week, at the smallest version. Three notes, ten minutes, attached to something that already happens. Not once you have finished setting up, because setting up does not finish.

This is the single most common way a migration ends up costing more than it delivered, and it is entirely preventable by knowing it happens.

Afterwards

Verify a month later. Open ten notes from different years. Check an attachment. Follow a link.

And write down what the export looked like, so that next time — and there will be a next time — you know what this tool gives you on the way out.

The short version