Notes are the most personal data most people own — years of thinking, captured in fragments — and the most annoying to migrate. The text usually transfers fine; it is everything around the text that breaks: the folder hierarchy, the tags, the links between notes, the embedded images, the attachments. A note-taking migration done carelessly preserves your words and destroys your system.
This guide is the careful version: how to export without loss, clean your archive before importing, choose the right import path, and verify that the new system actually holds everything the old one did. For the business context of why note apps shut down so often, see Why Apps Get Shut Down: The Business Reasons, Explained; for the billing side of the switch, our Annual vs. Monthly Plans: The Real Trade-Offs guide covers the tradeoffs.
Step 1: export and audit what you have
Run the full export from your old app and take inventory before you touch any new software. Count the notes. Note the folder or notebook structure. List the tags you actually use. Identify the notes with attachments, embedded images, or internal links — these are the fragile items that need special attention.
Choose your export format deliberately. Markdown with frontmatter (a small metadata header on each file) is the gold standard: it preserves text, basic formatting, and metadata in files any future app can read. One-file-per-note beats one-giant-file by a wide margin — individual files are addressable, searchable, and importable piecemeal. If your app offers both, take the per-note Markdown export as your master copy and any other format as a supplement.
Attachments need their own audit. Confirm every embedded image and file actually exported — open the attachments folder and spot-check the largest and most important ones. Some exporters silently skip files over a size limit or referenced-from-elsewhere items; discovering this after you have closed the old account is a special kind of pain.
Step 2: clean the archive before importing
Resist the urge to import immediately. Your old notes contain years of accumulation: duplicates, dead drafts, outdated reference material, notes whose purpose you no longer remember. Migration is a rare opportunity to declutter — and a clean import performs better, searches better, and is simply more pleasant to live in.
Work through the archive with three buckets: keep, archive, delete. Keep is the active working set. Archive is the reference material you rarely touch but want searchable — old project notes, saved articles, records. Delete is the cruft: duplicate exports, test notes, the forty variations of a grocery list. Be honest and be quick; perfectionism here is procrastination wearing a productive costume.
While cleaning, normalize the basics: consistent file naming, a folder structure that reflects how you actually think (not how you thought five years ago), and tags trimmed to the dozen or so you genuinely use. Tag sprawl — two hundred tags, most used once — is the silent killer of note systems; migration day is the day to kill it back.
Step 3: choose the import path
Most modern notes apps offer an importer for Markdown, and many offer dedicated importers for popular competitors. Use the dedicated importer if one exists for your old app — it handles the edge cases (internal links, metadata mapping) that generic Markdown import misses. Otherwise, Markdown import is your path, possibly folder by folder for large libraries.
Import in batches, not all at once. Start with a representative sample — a hundred notes spanning your typical content — and inspect the result carefully: formatting fidelity, attachment linking, tag mapping, internal link resolution. Fix whatever the sample reveals, adjust your approach, then import the rest. A batch strategy turns import problems into small correctable issues instead of one giant mess.
Internal links between notes deserve special care. Different apps use different link syntax, and cross-note links are the feature most likely to break in transit. After importing, run through your most-linked hub notes and repair broken links manually. It is tedious and it is worth it — those links are the connective tissue of your thinking.
Step 4: verify like an auditor
Verification is not optional; it is the step that separates migrations from data loss. Compare counts: notes, attachments, tags — old system versus new. The numbers should match, and every discrepancy should be investigated, not shrugged at. Open your ten most important notes in the new app and confirm they are complete and correctly formatted.
Test the workflows, not just the data. Create a note, link it, tag it, attach a file, search for it — the five operations you perform daily. If any of them feel broken or awkward, you have found either a configuration issue to fix or a genuine mismatch to weigh before you commit. Better to discover it now than after you have cancelled the old subscription.
The search test
Search is where migrations silently fail. Indexing a large imported library takes time — sometimes hours — and search results during that window are incomplete. Wait for indexing to finish, then run your ten most common searches and compare against the old app. If results differ, investigate before you declare the migration done; a notes app you cannot search is a write-only archive.
Step 5: run in parallel, then cut over
Do not cancel the old app on migration day. Run both for two to four weeks: do your daily note-taking in the new app while the old one remains as a reference and safety net. This parallel period catches the slow-burn problems — the workflow you forgot you needed, the integration you took for granted, the export you should have run differently.
Keep a running list of friction during the parallel run. Small annoyances compound; a list lets you distinguish “I need to learn the new way” from “this app genuinely cannot do what I need.” At the end of the period, the list tells you whether to commit or to try your second-choice candidate — with your cleaned, verified export ready to go.
Only after the parallel run: cancel the old subscription, export one final time (capturing anything added during the transition), and then — only then — delete the old account if you want it gone. The order matters: export, verify, parallel-run, cancel, delete. Never delete before the final export.
After the migration: settling into the new system
The migration is done when the data is verified — but the transition is not over until the new system feels like home. Spend the first month deliberately learning the new app’s strengths rather than mourning the old app’s features. Every notes app has a philosophy: some are built around folders, others around tags, others around links or daily notes. Fighting the new philosophy to recreate the old system produces a worse version of what you had; adapting to it usually produces something better.
Rebuild your templates and recurring structures early. If you kept daily logs, project templates, or meeting-note formats in the old app, recreate them in the new one during week one — these small structures are the scaffolding of your workflow, and their absence is felt daily. Likewise, reconnect the integrations: the read-later service that fed your notes, the calendar that linked to meeting notes, the task manager that referenced project pages. Integrations are the invisible half of a notes system, and they are easy to forget until something breaks.
Finally, schedule a one-month retrospective. Open the new app and ask honestly: is capture as fast as it was? Is retrieval as reliable? Did the features you compromised on actually matter? A month of real use is enough to judge, and if the verdict is negative, your cleaned export and your shortlist are still warm — switching again now is cheap compared to switching in a year. Most of the time, though, the verdict is positive, and the retrospective becomes the moment the new app stops being “the replacement” and starts being your notes.
Frequently asked questions
What about handwritten or scanned notes?
Images of handwriting migrate as images — the text is not searchable unless the new app does handwriting recognition. If searchable handwriting matters to you, verify the new app’s OCR capabilities with your actual scans before committing, and keep the original image files regardless.
What if I share notes with other people?
Shared notes are the hardest part of any migration because both sides must move or the sharing breaks. Coordinate the transition: agree on the new app, migrate shared notebooks together, and re-establish sharing permissions before anyone deletes the old copies. Solo notes can migrate on your schedule; shared notes need a plan.
Should I switch to an encrypted notes app?
If your notes contain sensitive material — finances, health, work confidences — encryption is worth the tradeoffs, which are usually slower search and fewer integrations. For general personal notes, standard apps with good security practices are fine. Match the protection to the content, not to the anxiety.
My library has 10,000+ notes. Any special advice?
Import in small batches with verification between each, and expect the process to take days, not hours. Large libraries also stress search indexing and sync — give the new app time to settle before judging performance. And clean aggressively first: at that scale, even a 20% declutter removes thousands of items from the migration.
Can I migrate to a free app safely?
Free apps can be excellent homes for notes, but apply the shutdown lens: how does the free app sustain itself, and what is its export story? A free app with open formats and a clear business model (or community backing) is safer than a free app with no visible revenue and a proprietary format. Price is not the risk factor — sustainability is.
Note migrations reward the methodical and punish the hasty. Export carefully, clean ruthlessly, import in batches, verify like an auditor, and run in parallel before you cut over. Your notes represent years of thinking; they deserve a move conducted with the care of a museum relocation, not a dorm-room scramble.