I Exported My Data From Nine Tools Before I Needed It, and Only Three Gave Me Something Usable

The export button is the thing everyone points to when lock-in comes up. It exists, it is usually free, and its presence is treated as proof that leaving is possible. I spent an afternoon actually pressing it on nine tools we pay for, while having no intention of leaving any of them, and the results reorganised how I think about vendor risk.

The test I applied was simple and I would suggest it to anyone: could a competent person, given only this file and no access to the original tool, reconstruct the work? Not the data — the work. Three of nine passed.

What passed: the accounting tool, which produced a CSV per ledger with every field visible in the interface, plus a separate archive of attached receipts named to match. The email host, which gave standard mbox files that any client can open. And the version control host, because the entire model is that the data is already on my machine, which is a structural property rather than a feature and is exactly why it is the safest thing we use.

What failed, and how they failed, is more instructive. The most common failure is what I would call the shredded export: everything is present but the relationships are gone. One project tool gave me a JSON file containing every task, and every task referenced a parent by an internal ID, and there was no file mapping those IDs to anything human-readable. The data was complete and the structure was unrecoverable without writing a script, which I did, and which took two hours for an archive I did not actually need.

The second failure is the rendered export, where you get a readable artefact and lose everything underneath. A documentation tool exported to PDF beautifully. Every internal link became dead text, every embedded database became a static table, and every comment thread vanished. If what you needed was a record for the archive, that is fine. If what you needed was to move, it is a photograph of your work rather than your work.

The third and worst is the partial export that does not tell you it is partial. One tool exported everything except attachments, with no warning and no mention in the documentation. I only found out because I counted files. Had I discovered that during an actual migration, under time pressure, having already cancelled the subscription, it would have been a genuinely serious problem.

So the practical advice is a single habit: press the export button within your first month with any tool, before it holds much, and open what comes out. It costs twenty minutes. What you learn is not whether an export exists but which of the four categories the vendor is in, and that tells you how much of your process you can safely build on top of them.

The related habit, which I now do quarterly, is to keep the most recent export of anything holding client work. Not as a backup — the vendor’s backups are better than mine — but as a hedge against the account itself becoming unavailable, which is a different failure mode from data loss and one that export buttons do not help with if you cannot log in. Two of the nine tools we use have no way to reach your data if your account is suspended, and I would not have known that either without going and reading.

None of this is an argument against SaaS or a case for self-hosting everything. It is an argument for knowing which of your tools are doors and which are one-way valves, and for finding out on a quiet afternoon rather than on the day you need to leave.