Moving Your Journal to a New App Without Losing Your History

The entries are the point. The app is just the room you keep them in. That sounds obvious until you try to move, and discover that four years of writing comes out as a single PDF with every entry run together and no dates, or as a spreadsheet where the line breaks have been eaten. Migrations go wrong in a small number of predictable ways, and all of them are avoidable if you look before you leap.

Export first, decide second

Do the export before you commit to anything. Not because the new app is untrustworthy, but because the export is the only honest description of what your history actually is once it leaves the interface that has been dressing it up. Ten minutes of looking at the file will tell you more than any migration guide.

Then keep that file. Forever, on your own disk, alongside your other irreplaceable documents. Whatever app you land in, the archive you control is the thing that survives the next move, the next acquisition, and the next pricing change.

The formats, and what each one costs you

JSON or NDJSON. The best case. One record per entry with its text and its metadata as separate labeled fields, so a machine can put it back together correctly. It looks unfriendly and it is the format most likely to survive intact.

Markdown or plain text, one file per entry. Also excellent, and readable by a human in fifty years with no software at all. Check whether the date lives inside the file or only in the filename, because filenames are the first thing a bulk import mangles.

CSV. Fine for metadata, treacherous for prose. A journal entry contains commas, quotation marks and line breaks, which are exactly the three characters CSV struggles with. Open the file and look at your longest entry specifically. If it has burst across several rows, the export is lossy and nothing downstream will fix it.

PDF. This is a printout, not an export. It is a fine keepsake and a terrible migration source, because getting structured entries back out of it is a manual job.

A proprietary archive. Only useful if the destination app happens to read that exact format. Ask what is inside it before you rely on it.

What usually gets lost

Text almost always survives. It is everything around the text that quietly disappears, and you rarely notice until you go looking for something years later.

• Original dates.The classic failure. Every imported entry lands with today’s date and your archive collapses into a single afternoon. Before importing, confirm the destination reads a created date from the file rather than stamping its own.
• Time zones. Entries written on a trip can shift by a day. Harmless for most purposes, disorienting if you are reading back a specific week.
• Formatting. Bold, italics, headings, checklists and nested lists are usually the first casualties, especially between two apps with different editors.
• Photos and attachments. Frequently absent from the export entirely, or present as links back to a server that will stop answering once you close the account.
• Tags, folders and favorites. Organization is app-specific, and the receiving app has nowhere to put it.
• Entry boundaries. The worst one, because it is irreversible by hand at any scale. Look at the file and confirm you can tell where one entry ends and the next begins.

There is an asymmetry worth knowing: most apps export more than they import. Check the destination’s import support before you cancel anything, and if it has none, plan on the archive being an archive rather than a starting library.

A migration that actually works

Export from the old app and save the file somewhere backed up. Open it and read three entries: your oldest, your longest, and one with unusual formatting. Those three catch nearly every defect a large export can have.

Import into the new app, then check the same three entries plus the total count. Counts are the cheapest check available and they catch silent truncation, which is the failure mode nobody looks for.

Then leave the old account alone for a month. Not paying for it is fine. Deleting it the same afternoon you migrate is how people lose things. Use the new app for a few weeks first, since problems surface when you go looking for a specific memory, not on migration day.

An easy exit tells you something

Pay attention to how hard it is to leave, because it is one of the more honest signals a product emits.

A company that makes export a first-class feature, complete and self-serve and in a format a competitor could read, is telling you it expects to keep you by being good rather than by being difficult to escape. A company that hides export behind a support request, or exports a format only it can read, has decided that your history is part of the lock. That decision was made about you and it is unlikely to be the only one.

There is a second reason to care, particular to journal entries. If a service can hand you a complete readable file from a server without your password, the service can read that file too. In a zero-knowledge app the export is either encrypted with your own key or assembled in your browser while you wait, which is slower and is the honest consequence of the design. We laid out the rest of that in how to tell whether your journal app can read your entries.

How this works in KindMind

You can download a complete backup of your account whenever you want. It contains everything, including material outside whatever plan you are currently on, because an archive that quietly omits the parts you are not paying for this month is not an archive. The file is encrypted, and with your recovery key it decrypts into plain text. That is the trade that comes with a database holding only ciphertext we have no key for.

We would rather you had the file and never needed it. You can see how the journal itself works on the journal feature page.

Whatever you use, do the export this week. Read three entries. Then you will know what you actually have, which is a better feeling than assuming.