What transfers when you switch read-later apps, and what doesn't

Every few years a read-later app shuts down, raises its price, or stops being the thing you wanted. Then comes the question that decides whether you actually move: what happens to the library?

The honest answer is that a library is three separate things, and they travel very differently.

The three layers

Links. A list of URLs with titles and dates. This is the layer that moves cleanly — it is small, it is text, and essentially every tool in this category can produce it in some form. If all you want is the set of things I once thought were worth keeping, you can almost always get it out.

Article text. The cleaned-up, reader-mode version of each page, stored so it still works when the original goes down. This layer is where link rot has already been fought and won on your behalf, and it is usually the hardest thing to move: it is large, every tool stores it differently, and few importers accept it. In practice, moving means re-fetching the URLs and hoping the pages are still there. Some will not be — that is the quiet cost nobody mentions.

Highlights and notes. The layer with your actual thinking in it, and the one most tightly bound to the tool that made it. A highlight is an offset into a specific rendering of a specific article. Move the article and the anchor often has nothing left to point at.

The ranking is consistent: the cheapest layer to move is the one you care least about, and the most valuable layer is the one that moves worst.

What that means in practice

Get the links out before you need them. Not when you are leaving — now, while the account is live and the export works. Whatever else you do, a list of URLs is a fallback that costs nothing to keep.

Expect the highlights to stay behind. If highlights are the centre of your workflow, that fact should dominate the decision. Readwise built its whole product on the assumption that highlights should flow outward continuously — into Obsidian, Notion, Logseq or Roam — which is a genuinely different posture from storing them in an app and offering an export at the end. If you have years of them, the tool that syncs them out is worth staying with, and we say so on its comparison page.

Check where the app runs before you check what it does. The most common reason a migration is forced is not features, it is platforms. If you move between a Windows desktop and an Android phone, that constraint eliminates most of this category before you get to the feature list — Cubox is the one that covers both natively, and Matter has no Android app at all.

The case for not moving your library

Here is the part most migration guides will not tell you: for most people, moving the whole backlog is the wrong goal.

The library you are trying to rescue is mostly a record of momentary interest. It accumulated because saving is cheap. Hauling all of it into a new tool reproduces the exact problem you were trying to leave — you arrive with a full backlog on day one and the new app immediately feels like the old one.

A better move is to treat the switch as the filter you never applied. Take the links as an archive, and start the new tool with the ten or twenty things you actually intend to get through. If something from the old list matters, you will remember it; that is a reasonable test of whether it mattered.

Where FeedTalk stands on this

Plainly: there is no bulk importer. Not from Cubox, not from Readwise, not from Matter. You save into FeedTalk from where you already read — the browser extension, the mobile share sheet, or a pasted URL — and the library starts from your next save.

For someone with a deep archive who needs all of it, that is a real reason not to switch, and it should be weighed as one. For someone whose backlog is mostly things they are never going to open, starting empty is closer to a feature than a limitation — but that is a judgement about your own library, not one we can make for you.

If you are weighing the switch on more than migration, we keep an honest comparison of four tools, including the rows where FeedTalk is the one marked "No".