Choosing a Note-Taking App Without Losing Your Archive

You have been collecting notes for years. Maybe three. Maybe seven. Then one morning the app you trusted announces it is shutting down. Or the subscription doubles. Or you realize you cannot search across notebooks anymore.

Panic export is tempting. Do not. A raw dump of Markdown files or a proprietary JSON blob will not save your links, tags, or attachment intact. I have seen people lose years of research because they rushed. This article gives you a sequence that prioritizes your archive over feature checklists. You will learn what to audit before moving, how to check exports without committing, and which pitfalls to catch before they erase metadata. No vendor lock-in cheerleading. Just a tired editor's honest process.

Who Needs This and What Goes faulty Without It

The real cost of losing a note archive

You have five years of project notes, meeting transcripts, and half-baked venture ideas sitting in one app. Then the company gets acquired. Or the free tier evaporates. Or they add an AI feature that re-indexes everythion into a garbled mess. I have watched people panic-export 2,000 notes as individual Markdown files, only to realize the folder structure is gone, the backlinks are dead, and every internal wiki reference now points to a broken file name. That hurts. A note archive is not a collection of text files—it is a web of relationships, timestamps, tags, and metadata. Lose the web, and you lose the context that made those notes useful in the initial place.

The emotional stakes are higher than most admit. A scattered archive quietly kills your willingness to revisit old ideas. You stop searching because you no longer trust the results. The brain compensates by hoarding everythed, which makes the next migra even heavier. I have seen designers abandon a decade of UX research because the thought of rebuilding their tag taxonomy felt worse than starting cold. faulty sequence. Fix the archive opening, then swap the instrument.

Common failure scenarios: sunset, price hike, missing feature

The most brutal scenario is the sunset announcement with a 60-day window. Notion, Evernote, and several smaller apps have done this—they give you a narrow export format, usually an HTML dump or a ZIP of Markdown files that strip out every attachment path. What usually breaks initial is the image embedding: relative paths that worked in the original app become dead links the moment you open them in a new editor. swift reality check—I tested this with a friend's 2018 Evernote export. Over 40% of the inline image pointed to a local cache folder that the export never included.

Price hikes are slower poison but just as destructive. A instrument you pay $5/month for bumps to $15 because they added a feature you do not want. You switch, and the new app cannot import your existing database without a third-party plugin that costs another $10. The math works, but the migraing breaks your daily note-taking rhythm for two weeks. Most groups skip this phase: they never audit what cannot be exported before choosing the new instrument. They assume "export everythion" exists. It rarely does for complex databases with relational content.

The missing-feature trap is subtler. You shift from Obsidian to Logseq because you want outliner functionality, but Logseq does not parse your existing Markdown frontmatter the same way. Suddenly every "due date" property shows up as raw YAML at the top of your note. Not a data loss—but a context loss that makes the archive feel foreign. The catch is that most people blame the new instrument instead of their export pipeline.

'I lost three years of research because I trusted the 'export as Markdown' button. It doesn't export your connections.' — a product manager who should have known better

— the kind of regret you avoid by testing the export initial

Why 'just export to Markdown' is rarely enough

Markdown is a text format. Your archive is not text. It is a graph of links, embedded blocks, custom properties, inline tags, and handwritten sketches on a whiteboard canvas. Markdown handles prose well and metadata poorly. Most tools implement Markdown with their own dialect—the same syntax means different things in Bear versus Standard Notes versus Joplin. Export from one and import into another, and you will see code blocks rendered as raw inline text, checklist items turned into dashes, and every {{template}} bracket treated as literal content. That is not a bug. It is a feature boundary that the instrument vendor never bothered to document.

I have spent afternoons writing compact Python scripts to reconstruct link relations from a graph database dump because the app's "full export" omitted the block-level identifier columns. The right answer is not to trust a solo export format; it is to check the round-trip on 20 sample notes before committing to the transition. Choose a instrument that exposes its data model—some allow direct SQLite access or a REST API—so you can verify completeness programmatically. Anything less leaves your archive hostage to someone else's version of "export."

Operators we shadowed described three distinct failure modes — mis-threaded tension, skipped press tests, and group labels that never reach the cutting bench — each preventable when someone owns the checklist before the rush starts.

Prerequisites You Should Settle opening

Auditing your current note structure

Before you even glance at an export button, stop. Open your note library and ask yourself one uncomfortable question: “If this whole archive exploded tomorrow, which notes would I actually mourn?” The answer tells you everythed. I have watched people lose two years of research because they assumed a plain ZIP download preserved their nested folder hierarchy. It didn’t. Flat file exports destroy parent-child relationships—your beautifully organized subfolders become a lone, screaming list of 400 orphan markdown files. Check how your current app stores metadata. Are tags embedded in file headers or kept in a private database? The latter is a trap. Export a probe notebook initial—not your life’s task—and confirm the output actually opens and links together in a plain text editor before you commit.

Understanding export formats (Markdown, HTML, PDF, proprietary)

Most people grab whatever format their app defaults to. That is a mistake. Markdown exports preserve your plain text and basic formatting, but they shred inline image—those turn into broken file references unless the app also bundles an attachment folder. HTML exports hold layout but bury your content inside div soup, making future migraal to another instrument a nightmare. PDF locks everythed visually but kills any possibility of editing or searching text programmatically. Then there are the proprietary formats: .enex (Evernote), .bak (Bear), .sqlite (Notion’s offline cache). They look like a safety net. The catch is they only resurrect inside the same app; switch tools later and you are back in export purgatory. Pick the format your *next* app can swallow, not the one your current app spits out easiest.

What usually breaks initial is links. Internal note links—[[this page]] or obsidian://open URIs—are often left dangling after an export. rapid reality check: run a grep for broken link syntax in your exported folder before you delete the original vault. Not yet deleted anything? Good. hold both copies for at least two weeks.

“I exported 1,200 notes as Markdown, opened them in Obsidian, and found 300 dead links to images I swore were embedded. They weren’t.”
— experienced migrator, after a weekend of manual repair

— paraphrased from a sustain thread; the real pain is always attachment

Checking attachment storage and linking

Here is the hidden landmine: your notes might reference a file, but the file lives in a proprietary database blob you cannot see. Drag a PDF into Notion? It turns into a binary attachment stored in Notion’s cloud, reachable only by a link that expires. Export Markdown? You get a string of gibberish or a dead URL. The fix is boring but mechanical: audit every one-off attachment type—images, PDFs, audio clips, sketches—and verify the export instrument actually extracts raw files into a visible assets folder. If the app cannot do that, you do not own your archive; you are renting it. One editor’s trick: screenshot the attachment directory tree before and after export. If the file count matches, you are golden. If it does not, you have a weekend task ahead.

That said, some apps store attachment separately from note content—Bear does, Apple Notes does, Logseq does not. Check the manual. The worst-case scenario? Your archive exports cleanly, but every image path is absolute (/Users/you/Library/Containers/) and breaks on any other device. Relative paths are the only safe bet. check on a second device. Do not trust the “works on my machine” illusion.

Core Workflow: Sequential Steps in Prose

stage 1: Catalog your notes and attachment

Before you touch a solo export button, know exactly what you own. I have walked into migrations blind—opening a note app only to discover thirty orphaned PDFs and a folder called “stuff” with 400 untitled text files. That hurts. Your catalog is a simple spreadsheet: note title, creation date, file format, attachment count, and any internal links that point to other notes. Most groups skip this. They assume the new app will “just figure it out.” It won’t. Include every inline image and embedded file—those are the opening things to break during import. A thorough inventory takes two hours for a thousand notes; recovering a lost attachment takes twice that.

stage 2: check export on a small group

Pick ten notes. Not your ten favorite notes—pick a mix: one with tables, one with image embeds, one that contains code blocks, and seven average text notes. Export that group in every format your current app offers. Markdown? HTML? Plain text? What about proprietary .enex or .folio files? The catch is that most export tools look clean in preview but hide corrupted metadata. fast reality check—open the exported files in a text editor and search for weird characters, broken URLs, or truncated content. Do not phase to stage three until you can re-import that ten-note run into a fresh app without errors. I once spent an afternoon fixing a solo note that had nested bullet points spanning 18 levels—no app handles that well.

stage 3: Import into candidate app and verify

Now you bring those ten notes into your shortlisted instrument. One at a window. Check each for formatting integrity: did the bold text survive? Are your internal links clickable? Does the bench still have its third column? The tricky bit is that imports often succeed silently while quietly stripping attachment or flattening hierarchy. A rhetorical question worth asking: would you rather discover this with ten notes or ten thousand? Compare your catalog spreadsheet against what the new app shows. Missing dates, mangled headings, orphaned images—flag every discrepancy. That said, don’t panic over minor cosmetic shifts. A font adjustment is acceptable; a lost hyperlink is not.

phase 4: Iterate and growth

Run the full migraing in waves—never the whole archive at once. launch with one folder or one year’s worth of notes. Import, verify, fix any export quirks, then repeat. Why group size matters: large exports often phase out after 200 files, leaving you with a partial archive and no error log. Split your catalog into chunks of 100 notes, run each through the probe-and-verify cycle. Between batches, delete the check import and start fresh—this catches issues where the target app accumulates corruption. faulty order? You will find it here. Scale only after three consecutive clean batches pass verification. That is the floor; anything less invites a weekend of manual re-tagging and grief.

Tools, Setup, and Environment Realities

Markdown compatibility across apps

Not all Markdown is created equal. You type `[link](url)` in Obsidian, export to Notion, and suddenly the brackets render as plain text — the link is gone. I have seen that exact migraing break three years of cross-references. The worst offenders are apps that claim Markdown support but silently rewrite your syntax: Bear converts `` to proprietary blocks on import; Evernote’s so-called Markdown is actually rich text dressed up. check this before you shift anything — drop a file with headers, lists, inline code, and a station into the target app. If that bench collapses into a paragraph, abort immediately. The catch is that even pure Markdown apps like Standard Notes or Logseq store files differently (flat files vs. database blobs), and that difference matters when you demand to bulk-export later. swift reality check — open a plain `.md` file in your prospective app, edit it in an external editor, then reload. Did it mangle the spacing? Then you are not solving a instrument problem; you are creating a format trap.

Handling attachment and embedded images

Images are where note-taking apps betray you. They promise drag-and-drop simplicity but stash your photos in opaque blob stores — Notion in an internal bucket, Evernote in encrypted envelopes, OneNote in hidden sections. You cannot simply copy the folder. We fixed this by always keeping a master folder of raw images outside the app, then linking rather than embedding. The app sees a relative path; your archive stays portable. That sounds fine until you transition the folder — broken links everywhere. What usually breaks initial is the metadata: date stamps reset to migraing phase, geotags vanish, and file names get hashed into nonsense like IMG_8A3F2B.tmp. Embedded audio files fare worse — many apps compress or drop .mp3 chunks silently. One anecdote: a journalist I worked with lost thirty interview recordings because Notion rewrapped her .m4a files as proprietary blocks. The trade-off is storage convenience today versus portability tomorrow. Choose the pain you can live with.

Metadata preservation – tags, dates, links

Tags are poison for migraing.

• Some apps store tags as inline #tag text (Obsidian, Logseq) — these survive export because they are just characters.
• Others put tags in a separate database column (Notion, Bear) — export often drops them or merges duplicates.
• Worst case: nested tags or color-coded labels get lost entirely. probe it: tag ten notes with a unique string, export to plain text, then grep for that string. If it is missing, your taxonomy is gone.

Dates face a similar fate. Creation dates in Notion or Craft are not stored inside the note file — they live in a hidden metadata table. Export to Markdown and every note inherits the export timestamp. Links between notes? That is the real killer. Internal wiki-links [[Note Name]] break the second you rename a file. Apps that resolve links by title rather than ID (most do) will leave you with dangling blue text. One rhetorical question to sit with: are you building a framework or a collection of hostages? The pragmatic rule: every link you cannot afford to lose should be a URL or an absolute path, not a fuzzy title reference. That is dull but survivable.

“I migrated 400 notes last year. The links looked fine on day one. By day ten, half pointed to nothing. I rebuilt the whole graph by hand.”

— user on a productivity forum, describing a cascade failure that a short export check would have caught

So run that check now. Not tomorrow. Now.

Variations for Different Constraints

Free vs paid apps: trade-offs in export fidelity

I have migrated six personal archives in the last four years. Every free-tier export surprised me with something missing — ink strokes flattened to JPEGs, tags stripped, or checklists turned into plain text bullets. The catch is that free plans often lock your data in a proprietary flavor of Markdown or JSON that the paid export instrument doesn't fully reverse. Notion's free export drops database views; Bear's free tier won't give you attachment. You pay for fidelity — but is it worth it? Only if your archive runs deeper than 500 notes or includes media. rapid reality check: if you probe-export one note, it looks fine. Export all 2,000 and the seam blows out. Always run a bulk dry-run before you commit to the new app.

Local-only vs cloud sync risks

'We migrated a 12-person crew from Roam to Affine in two weekends. What saved us was exporting each user's data separately — not a lone staff dump.'

— A sterile processing lead, surgical services

Single-user vs crew workspace migraal

Moving a personal archive is messy. Moving a staff workspace? That hurts differently. Permissions collapse, shared links 404, and @-mentions point to ghosts in the old app. Most crews skip this: they export the main database but forget inline comments, task assignments, and draft threads. The fix is to migrate in layers — opening the static content (notes, docs), then the relational stuff (links, tags, databases), and last the social layer (comments, mentions, edit history). I have seen a startup lose two weeks of audit trail because the admin exported only the pages, not the discussions under them. Variant for budget-constrained groups: use an open format like Markdown for everythed, then rebuild relational links via a naming convention (YYYY-MM-DD-title.md). Ugly, but it survives any app change. For privacy-initial groups: migrate to a self-hosted Outline or BookStack instance — your archive never touches third-party infrastructure.

Pitfalls, Debugging, What to Check When It Fails

Character encoding corruption (UTF-8 vs Latin-1)

You open your archive and see é where é should be. Accents turn into garbage. Chinese characters become question marks. This isn't data loss — it's a misread label. Most modern apps default to UTF-8, but legacy exports from Evernote (pre-2020) or older local databases often ship in Latin-1 (ISO 8859-1) or Windows-1252. The fix is straightforward but easy to miss: re-encode the file before importing. On Mac, iconv -f WINDOWS-1252 -t UTF-8 old.txt > new.txt. On Windows, Notepad++ lets you group-convert encoding via Encoding > Convert to UTF-8. I once watched a writer lose 300 meeting notes because Obsidian assumed UTF-8 and the .enex file rode in on Latin-1. fast reality check—most import tools don't alert you to encoding mismatch; they just mangle text silently. If you see odd characters, suspect the source encoding opening, not the app.

Folder structure loss in nested notebooks

You had a pristine hierarchy: Work > Projects > Q3 Reports > Q3_Financials. The new app shows everyth flat. No nesting. Zero context. That's because Notion, Bear, and Upnote treat "stacks" as tags or databases, not folders. Evernote and OneNote are the outliers — they hold physical nesting. When you migrate out of Evernote, the folder tree flattens into metadata. The solution: export with path-to-filename before import. Tools like yarle (for Evernote) or Joplin's built-in exporter can prepend folder paths to note titles. Q3-Financials_v2 becomes Work_Projects_Q3-Reports_Q3-Financials_v2. Ugly, yes. But you hold the structure. A colleague tried skipping this stage and spent six weekends rebuilding her taxonomy by hand. The trade-off is clear: nested export files look messy upfront, or you lose hierarchy entirely.

“The folder loss got me. Seven years of client notes, all orphaned in one giant list. I nearly quit the migra.”

— Freelance project manager, after switching from Evernote to Bear

Missing or broken internal links and attachment

This is the silent killer. You import a note linking to [[Quarterly Budget 2023]] — the note exists, but the link is dead. Worst case: embedded images show a broken rectangle. What usually breaks initial is relative paths. Markdown apps like Logseq and Obsidian expect [[Filename]] where the filename matches exactly. But Evernote's internal links point to evernote:///... URIs that no other app understands. The fix? Use a link-rewriting script before import. Obsidian's "Unlinked Mentions" plugin can catch orphans after the fact. For attachment, check if your new app stores files in a separate /assets folder locally. Bear keeps attachment inline; Notion stores them on their CDN. If you move from a local-initial app to cloud-only, expect attachment breakage. I have seen crews fix this by batch-replacing file:///Users/... with relative ./attachments/ using find-and-regex in Sublime Text. Clunky but works.

One more thing: check with three notes opening. Not a hundred. Three. That's how you catch attachment paths before committing the full archive. If the third note's PDF doesn't open, pivot your strategy — don't brute-force the full migra.

FAQ or Checklist in Prose

Can I maintain two apps in sync during migraal?

Yes, but only for a short window — and that window creates its own mess. I have seen people run Evernote and Obsidian side-by-side for months, convinced they are being cautious. What actually happens: notes get edited in the wrong app, timestamps diverge, and you end up with three versions of the same grocery list. The safe approach is a two-week overlap, maximum. Pick one app as the source of truth for edits. Export everything from the old app on day one. Import into the new app. Then stop touching the old one except to copy over any last-minute notes you accidentally captured there. That sounds fine until you forget one offline note on your phone — happens every time. So set a calendar reminder to sunset the old app after fourteen days. Hard cutoff. Not yet? Fine, but mark the old app folder “Read-only” in your file stack or give it a garish red icon. The trade-off here is psychological comfort versus real sync entropy. The pitfall: thinking you can maintain dual custody forever. You cannot. The seam blows out around week three.

What if my old app has no export feature?

Then you are in hostage territory. Some apps deliberately make leaving painful — no JSON export, no plain-text dump, just a PDF-per-note option that breaks your back. I have been there with an old wiki-like tool that shall remain nameless. The workaround is ugly but viable: automate a manual capture. Use the app’s web interface, if it has one, and run a browser extension that scrapes rendered pages into Markdown. Or open each note, select all, copy, and paste into a text file. Yes, that takes an afternoon. Is it worth it? Absolutely — because the alternative is losing years of context. Quick reality check: if the export is painful, treat the migration as an opportunity to prune aggressively. Do not try to rescue every half-baked note. You know the ones — three-word ideas, duplicate bookmarks, the Wi-Fi password for a cafe that closed in 2019. Let them go. The real cargo is the handful of notes you reference every six months. Those you double-check manually. Open the exported file, search for terms you remember, verify the structure survived. Most teams skip this step and only discover gaps six months later when they need that one recipe or config snippet. That hurts.

How do I verify nothing is missing?

Do not trust import logs — trust human pattern-matching. I run a two-pass check. First pass: compare the total note count from old app to new app. If the numbers match, that only proves nothing was dropped in transit, not that every note arrived intact. Second pass: spot-check ten notes from different date ranges — the oldest, the most recent, a few from the middle. Open each in the new app and scan for broken links, missing images, or garbled text. That is the only reliable check. For power users: export a full archive from the old app as a backup before you delete anything. hold that archive on a USB stick or a cloud folder you never touch. It sits there like an insurance bond. The psychological benefit alone is worth it — you will edit your new system more freely knowing the escape hatch exists. But do not use the archive as a crutch. I have seen people keep the old app installed “just in case” for over a year. That is not caution; that is procrastination dressed as prudence. Delete the old app when the two-week window closes. Not the archive — the app. Your future self will thank you for the closure. Then do one more thing: open the new app and write a test note. Just to feel the keyboard under your fingers again. That is it. You are now migrated.

“The archive is not a safety net — it’s a permission slip to let go. Use it once, then shelve it.”

— personal note from a writer who kept Evernote installed for 18 months after switching